13 Aug, 2017

1 commit


09 Jun, 2017

1 commit


11 May, 2017

1 commit

  • Pull hw lockdown support from David Howells:
    "Annotation of module parameters that configure hardware resources
    including ioports, iomem addresses, irq lines and dma channels.

    This allows a future patch to prohibit the use of such module
    parameters to prevent that hardware from being abused to gain access
    to the running kernel image as part of locking the kernel down under
    UEFI secure boot conditions.

    Annotations are made by changing:

    module_param(n, t, p)
    module_param_named(n, v, t, p)
    module_param_array(n, t, m, p)

    to:

    module_param_hw(n, t, hwtype, p)
    module_param_hw_named(n, v, t, hwtype, p)
    module_param_hw_array(n, t, hwtype, m, p)

    where the module parameter refers to a hardware setting

    hwtype specifies the type of the resource being configured. This can
    be one of:

    ioport Module parameter configures an I/O port
    iomem Module parameter configures an I/O mem address
    ioport_or_iomem Module parameter could be either (runtime set)
    irq Module parameter configures an I/O port
    dma Module parameter configures a DMA channel
    dma_addr Module parameter configures a DMA buffer address
    other Module parameter configures some other value

    Note that the hwtype is compile checked, but not currently stored (the
    lockdown code probably won't require it). It is, however, there for
    future use.

    A bonus is that the hwtype can also be used for grepping.

    The intention is for the kernel to ignore or reject attempts to set
    annotated module parameters if lockdown is enabled. This applies to
    options passed on the boot command line, passed to insmod/modprobe or
    direct twiddling in /sys/module/ parameter files.

    The module initialisation then needs to handle the parameter not being
    set, by (1) giving an error, (2) probing for a value or (3) using a
    reasonable default.

    What I can't do is just reject a module out of hand because it may
    take a hardware setting in the module parameters. Some important
    modules, some ipmi stuff for instance, both probe for hardware and
    allow hardware to be manually specified; if the driver is aborts with
    any error, you don't get any ipmi hardware.

    Further, trying to do this entirely in the module initialisation code
    doesn't protect against sysfs twiddling.

    [!] Note that in and of itself, this series of patches should have no
    effect on the the size of the kernel or code execution - that is
    left to a patch in the next series to effect. It does mark
    annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
    an already existing field"

    * tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
    Annotate hardware config module parameters in sound/pci/
    Annotate hardware config module parameters in sound/oss/
    Annotate hardware config module parameters in sound/isa/
    Annotate hardware config module parameters in sound/drivers/
    Annotate hardware config module parameters in fs/pstore/
    Annotate hardware config module parameters in drivers/watchdog/
    Annotate hardware config module parameters in drivers/video/
    Annotate hardware config module parameters in drivers/tty/
    Annotate hardware config module parameters in drivers/staging/vme/
    Annotate hardware config module parameters in drivers/staging/speakup/
    Annotate hardware config module parameters in drivers/staging/media/
    Annotate hardware config module parameters in drivers/scsi/
    Annotate hardware config module parameters in drivers/pcmcia/
    Annotate hardware config module parameters in drivers/pci/hotplug/
    Annotate hardware config module parameters in drivers/parport/
    Annotate hardware config module parameters in drivers/net/wireless/
    Annotate hardware config module parameters in drivers/net/wan/
    Annotate hardware config module parameters in drivers/net/irda/
    Annotate hardware config module parameters in drivers/net/hamradio/
    Annotate hardware config module parameters in drivers/net/ethernet/
    ...

    Linus Torvalds
     

20 Apr, 2017

1 commit

  • When the kernel is running in secure boot mode, we lock down the kernel to
    prevent userspace from modifying the running kernel image. Whilst this
    includes prohibiting access to things like /dev/mem, it must also prevent
    access by means of configuring driver modules in such a way as to cause a
    device to access or modify the kernel image.

    To this end, annotate module_param* statements that refer to hardware
    configuration and indicate for future reference what type of parameter they
    specify. The parameter parser in the core sees this information and can
    skip such parameters with an error message if the kernel is locked down.
    The module initialisation then runs as normal, but just sees whatever the
    default values for those parameters is.

    Note that we do still need to do the module initialisation because some
    drivers have viable defaults set in case parameters aren't specified and
    some drivers support automatic configuration (e.g. PNP or PCI) in addition
    to manually coded parameters.

    This patch annotates drivers in sound/pci/.

    Suggested-by: Alan Cox
    Signed-off-by: David Howells
    cc: Jaroslav Kysela
    cc: Takashi Iwai
    cc: alsa-devel@alsa-project.org

    David Howells
     

22 Feb, 2017

1 commit

  • Declare snd_kcontrol_new structures as const as they are only passed as
    an argument to the function snd_ctl_new1. This argument is of type
    const, so snd_kcontrol_new structures having the same property can be
    made const too.
    Done using Coccinelle:

    @r1 disable optional_qualifier @
    identifier i;
    position p;
    @@
    static struct snd_kcontrol_new i@p = {...};

    @ok1@
    identifier r1.i;
    position p;
    expression e1;
    @@
    snd_ctl_new1(&i@p,e1)

    @bad@
    position p!={r1.p,ok1.p};
    identifier r1.i;
    @@
    i@p

    @depends on !bad disable optional_qualifier@
    identifier r1.i;
    @@
    +const
    struct snd_kcontrol_new i;

    Signed-off-by: Bhumika Goyal
    Signed-off-by: Takashi Iwai

    Bhumika Goyal
     

14 Nov, 2016

1 commit


02 Sep, 2016

1 commit

  • Check for snd_pcm_ops structures that are only stored in the ops field of a
    snd_soc_platform_driver structure or passed as the third argument to
    snd_pcm_set_ops. The corresponding field or parameter is declared const,
    so snd_pcm_ops structures that have this property can be declared as const
    also.

    The semantic patch that makes this change is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @r disable optional_qualifier@
    identifier i;
    position p;
    @@
    static struct snd_pcm_ops i@p = { ... };

    @ok1@
    identifier r.i;
    struct snd_soc_platform_driver e;
    position p;
    @@
    e.ops = &i@p;

    @ok2@
    identifier r.i;
    expression e1, e2;
    position p;
    @@
    snd_pcm_set_ops(e1, e2, &i@p)

    @bad@
    position p != {r.p,ok1.p,ok2.p};
    identifier r.i;
    struct snd_pcm_ops e;
    @@
    e@i@p

    @depends on !bad disable optional_qualifier@
    identifier r.i;
    @@
    static
    +const
    struct snd_pcm_ops i = { ... };
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Takashi Iwai

    Julia Lawall
     

05 Apr, 2015

1 commit


28 Jan, 2015

1 commit


10 Jan, 2015

1 commit

  • This is a similar cleanup like the commit [3db084fd0af5: ALSA: fm801:
    PCI core handles power state for us].

    Since pci_set_power_state(), pci_save_state() and pci_restore_state()
    are already done in the PCI core side, so we don't need to it doubly.

    Also, pci_enable_device(), pci_disable_device() and pci_set_master()
    calls in PM callbacks are superfluous nowadays, too, so get rid of
    them as well.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

21 Oct, 2014

1 commit


13 Aug, 2014

1 commit

  • We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to
    meet kernel coding style guidelines. This issue was reported by checkpatch.

    A simplified version of the semantic patch that makes this change is as
    follows (http://coccinelle.lip6.fr/):

    //

    @@
    identifier i;
    declarer name DEFINE_PCI_DEVICE_TABLE;
    initializer z;
    @@

    - DEFINE_PCI_DEVICE_TABLE(i)
    + const struct pci_device_id i[]
    = z;

    //

    [bhelgaas: add semantic patch]
    Signed-off-by: Benoit Taine
    Signed-off-by: Bjorn Helgaas

    Benoit Taine
     

26 Feb, 2014

1 commit


12 Feb, 2014

1 commit


27 Aug, 2013

1 commit


29 May, 2013

1 commit

  • As drvdata is cleared to NULL at probe failure or at removal by the
    driver core, we don't have to call pci_set_drvdata(pci, NULL) any
    longer in each driver.

    The only remaining pci_set_drvdata(NULL) is in azx_firmware_cb() in
    hda_intel.c. Since this function itself releases the card instance,
    we need to clear drvdata here as well, so that it won't be released
    doubly in the remove callback.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

26 Jan, 2013

1 commit

  • Because currently snd_printd() and snd_printdd() macros are expanded
    to empty when CONFIG_SND_DEBUG=n, a compile warning like below
    appears sometimes, and we had to covert it by ugly ifdefs:
    sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd71bxx_fixup_hp’:
    sound/pci/hda/patch_sigmatel.c:2434:24: warning: unused variable ‘spec’ [-Wunused-variable]

    For "fixing" these issues better, this patch replaces snd_printd() and
    snd_printdd() definitions with empty inline functions instead of
    macros. This should have the same effect but shut up warnings like
    above.

    But since we had already put ifdefs, changing to inline functions
    would trigger compile errors. So, such ifdefs is removed in this
    patch.

    In addition, snd_pci_quirk name field is defined only when
    CONFIG_SND_DEBUG_VERBOSE is set, and the reference to it in
    snd_printdd() argument triggers the build errors, too. For avoiding
    these errors, introduce a new macro snd_pci_quirk_name() that is
    defined no matter how the debug option is set.

    Reported-by: Stratos Karafotis
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

07 Dec, 2012

1 commit

  • CONFIG_HOTPLUG is going away as an option. As result the __dev*
    markings will be going away.

    Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
    and __devexit.

    Signed-off-by: Bill Pemberton
    Signed-off-by: Takashi Iwai

    Bill Pemberton
     

07 Sep, 2012

1 commit


15 Aug, 2012

1 commit


03 Jul, 2012

1 commit


24 Apr, 2012

1 commit


19 Dec, 2011

1 commit

  • module_param(bool) used to counter-intuitively take an int. In
    fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
    trick.

    It's time to remove the int/unsigned int option. For this version
    it'll simply give a warning, but it'll break next kernel version.

    Signed-off-by: Rusty Russell
    Signed-off-by: Takashi Iwai

    Rusty Russell
     

01 Nov, 2011

1 commit


20 Sep, 2011

1 commit


14 Sep, 2011

1 commit

  • The semantics of snd_mpu401_uart_new()'s interrupt parameters are
    somewhat counterintuitive: To prevent the function from allocating its
    own interrupt, either the irq number must be invalid, or the irq_flags
    parameter must be zero. At the same time, the irq parameter being
    invalid specifies that the mpu401 code has to work without an interrupt
    allocated by the caller. This implies that, if there is an interrupt
    and it is allocated by the caller, the irq parameter must be set to
    a valid-looking number which then isn't actually used.

    With the removal of IRQF_DISABLED, zero becomes a valid irq_flags value,
    which forces us to handle the parameters differently.

    This patch introduces a new flag MPU401_INFO_IRQ_HOOK for when the
    device interrupt is handled by the caller, and makes the allocation of
    the interrupt to depend only on the irq parameter. As suggested by
    Takashi, the irq_flags parameter was dropped because, when used, it had
    the constant value IRQF_DISABLED.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai

    Clemens Ladisch
     

10 Jun, 2011

2 commits

  • The name argument of request_irq() appears in /proc/interrupts, and
    it's quite ugly when the name entry contains a space or special letters.
    In general, it's simpler and more readable when the module name appears
    there, so let's replace all entries with KBUILD_MODNAME.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • The convention for pci_driver.name entry in kernel drivers seem to be
    the module name or equivalent ones. But, so far, almost all PCI sound
    drivers use more verbose name like "ABC Xyz (12)", and these are fairly
    confusing when appearing as a file name.

    This patch converts the all pci_driver.name entries in sound/pci/* to
    use KBUILD_MODNAME for more unified appearance.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

12 Jul, 2010

1 commit

  • As per-stream volume controls, the DXS controls are not intended to
    adjust the overall sound level and so are initialized every time
    a stream is opened. However, there are special situations where one
    wants to reduce the overall volume in the digital domain, i.e., before
    the AC'97 codec's PCM volume control. To allow this, add a module
    parameter that sets the initial DXS volume.

    Signed-off-by: Clemens Ladisch
    Tested-by: Soeren D. Schulze
    Signed-off-by: Takashi Iwai

    Clemens Ladisch
     

01 Mar, 2010

1 commit


22 Feb, 2010

1 commit


09 Feb, 2010

1 commit


30 Oct, 2009

1 commit


06 Oct, 2009

1 commit

  • The "VIA DXS" controls are actually volume controls that apply to the
    four PCM substreams, so we better indicate this connection by moving the
    controls to the PCM interface.

    Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the
    restoring of these volumes by "alsactl restore" that most distributions
    use; the renaming in this patch cures that regression by preventing
    alsactl from applying the old, wrong volume levels to the new controls.
    http://bugzilla.kernel.org/show_bug.cgi?id=14151
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613

    Signed-off-by: Clemens Ladisch
    Cc:
    Signed-off-by: Takashi Iwai

    Clemens Ladisch
     

25 Jun, 2009

1 commit


22 Jun, 2009

1 commit

  • There's a large 500ms delay in snd_via82xx_codec_wait() that, at least
    on my hardware, appears to be unnecessary. The rest of the init of
    the card works without logging any warnings or errors and both audio
    and mixer settings work.

    This adds an "nodelay" parameter to disable this (undocumented in the
    code) large delay improving bootup time by 489-500ms.

    [ 1.034217] initcall alsa_card_via82xx_init+0x0/0x16 returned 0 after 505757 usecs
    vs.
    [ 0.533136] initcall alsa_card_via82xx_init+0x0/0x16 returned 0 after 15915 usecs

    Signed-off-by: Simon Arlott
    Signed-off-by: Takashi Iwai

    Simon Arlott
     

05 May, 2009

1 commit


24 Mar, 2009

1 commit


10 Feb, 2009

1 commit


05 Feb, 2009

1 commit