1. 20 Apr, 2017 11 commits
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/media/ · 5a8fc6a3
      David Howells authored
      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 drivers/media/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      cc: mjpeg-users@lists.sourceforge.net
      cc: linux-media@vger.kernel.org
      5a8fc6a3
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/isdn/ · b9351f7e
      David Howells authored
      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 drivers/isdn/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Karsten Keil <isdn@linux-pingi.de>
      cc: netdev@vger.kernel.org
      b9351f7e
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/input/ · f6b12d04
      David Howells authored
      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 drivers/input/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      cc: linux-input@vger.kernel.org
      f6b12d04
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/iio/ · 8863b3e7
      David Howells authored
      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 drivers/iio/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarWilliam Breathitt Gray <vilhelm.gray@gmail.com>
      Acked-by: default avatarJonathan Cameron <jic23@kernel.org>
      cc: linux-iio@vger.kernel.org
      8863b3e7
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/i2c/ · c78babcc
      David Howells authored
      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 drivers/i2c/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Acked-by: default avatarJean Delvare <jdelvare@suse.de>
      cc: linux-i2c@vger.kernel.org
      c78babcc
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/gpio/ · d759f906
      David Howells authored
      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 drivers/gpio/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarWilliam Breathitt Gray <vilhelm.gray@gmail.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      cc: Alexandre Courbot <gnurou@gmail.com>
      cc: linux-gpio@vger.kernel.org
      d759f906
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/cpufreq/ · 40059ec6
      David Howells authored
      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 drivers/cpufreq/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatar"Rafael J. Wysocki" <rjw@rjwysocki.net>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      cc: linux-pm@vger.kernel.org
      40059ec6
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/clocksource/ · cc9c6175
      David Howells authored
      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 drivers/clocksource/.
      
      [Note: With regard to cs5535-clockevt.c, Thomas Gleixner asked whether the
       timer_irq parameter is required for the driver to work on anything other than
       arbitrary hardware which has it mapped to 0.  Jens Rottmann replied that the
       parameter defaults to 0, which means:
      
      	1. autodetect (=keep IRQ BIOS has set up)
      	2. if that fails use CONFIG_CS5535_MFGPT_DEFAULT_IRQ
      	   (see drivers/misc/cs5535-mfgpt.c: cs5535_mfgpt_set_irq())
      
       Jens further noted that there may not be any systems that have CS5535/36
       devices that support EFI and secure boot.]
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      cc: Thomas Gleixner <tglx@linutronix.de>
      cc: Jens Rottmann <Jens.Rottmann@ADLINKtech.com>
      cc: linux-kernel@vger.kernel.org
      cc9c6175
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/char/ · 1c37ab5e
      David Howells authored
      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 drivers/char/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc: Arnd Bergmann <arnd@arndb.de>
      1c37ab5e
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/char/mwave/ · 94b599bc
      David Howells authored
      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 drivers/char/mwave/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      94b599bc
    • David Howells's avatar
      Annotate hardware config module parameters in drivers/char/ipmi/ · 684497bf
      David Howells authored
      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 drivers/char/ipmi/.
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarCorey Minyard <cminyard@mvista.com>
      cc: openipmi-developer@lists.sourceforge.net
      684497bf
  2. 04 Apr, 2017 2 commits
    • David Howells's avatar
      Annotate hardware config module parameters in arch/x86/mm/ · 3c2e2e68
      David Howells authored
      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 arch/x86/mm/.
      
      [Note: With respect to testmmiotrace, an additional patch will be added
       separately that makes the module refuse to load if the kernel is locked
       down.]
      Suggested-by: default avatarAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      cc: Ingo Molnar <mingo@kernel.org>
      cc: Thomas Gleixner <tglx@linutronix.de>
      cc: "H. Peter Anvin" <hpa@zytor.com>
      cc: x86@kernel.org
      cc: linux-kernel@vger.kernel.org
      cc: nouveau@lists.freedesktop.org
      3c2e2e68
    • David Howells's avatar
      Annotate module params that specify hardware parameters (eg. ioport) · bf616d21
      David Howells authored
      Provided an annotation for module parameters that specify hardware
      parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
      dma buffers and other types).
      
      This will enable such parameters to be locked down in the core parameter
      parser for secure boot support.
      
      I've also included annotations as to what sort of hardware configuration
      each module is dealing with for future use.  Some of these are
      straightforward (ioport, iomem, irq, dma), but there are also:
      
       (1) drivers that switch the semantics of a parameter between ioport and
           iomem depending on a second parameter,
      
       (2) drivers that appear to reserve a CPU memory buffer at a fixed address,
      
       (3) other parameters, such as bus types and irq selection bitmasks.
      
      For the moment, the hardware configuration type isn't actually stored,
      though its validity is checked.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      bf616d21
  3. 03 Apr, 2017 2 commits
  4. 30 Mar, 2017 1 commit
  5. 28 Mar, 2017 2 commits
    • Tetsuo Handa's avatar
      LSM: Revive security_task_alloc() hook and per "struct task_struct" security blob. · e4e55b47
      Tetsuo Handa authored
      We switched from "struct task_struct"->security to "struct cred"->security
      in Linux 2.6.29. But not all LSM modules were happy with that change.
      TOMOYO LSM module is an example which want to use per "struct task_struct"
      security blob, for TOMOYO's security context is defined based on "struct
      task_struct" rather than "struct cred". AppArmor LSM module is another
      example which want to use it, for AppArmor is currently abusing the cred
      a little bit to store the change_hat and setexeccon info. Although
      security_task_free() hook was revived in Linux 3.4 because Yama LSM module
      wanted to release per "struct task_struct" security blob,
      security_task_alloc() hook and "struct task_struct"->security field were
      not revived. Nowadays, we are getting proposals of lightweight LSM modules
      which want to use per "struct task_struct" security blob.
      
      We are already allowing multiple concurrent LSM modules (up to one fully
      armored module which uses "struct cred"->security field or exclusive hooks
      like security_xfrm_state_pol_flow_match(), plus unlimited number of
      lightweight modules which do not use "struct cred"->security nor exclusive
      hooks) as long as they are built into the kernel. But this patch does not
      implement variable length "struct task_struct"->security field which will
      become needed when multiple LSM modules want to use "struct task_struct"->
      security field. Although it won't be difficult to implement variable length
      "struct task_struct"->security field, let's think about it after we merged
      this patch.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Tested-by: default avatarDjalal Harouni <tixxdz@gmail.com>
      Acked-by: default avatarJosé Bollo <jobol@nonadev.net>
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: José Bollo <jobol@nonadev.net>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      e4e55b47
    • James Morris's avatar
      840c91dc
  6. 26 Mar, 2017 8 commits
    • Linus Torvalds's avatar
      Linux 4.11-rc4 · c02ed2e7
      Linus Torvalds authored
      c02ed2e7
    • Linus Torvalds's avatar
      Merge tag 'char-misc-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · 0dc82fa5
      Linus Torvalds authored
      Pull char/misc driver fixes from Greg KH:
       "A smattering of different small fixes for some random driver
        subsystems. Nothing all that major, just resolutions for reported
        issues and bugs.
      
        All have been in linux-next with no reported issues"
      
      * tag 'char-misc-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (21 commits)
        extcon: int3496: Set the id pin to direction-input if necessary
        extcon: int3496: Use gpiod_get instead of gpiod_get_index
        extcon: int3496: Add dependency on X86 as it's Intel specific
        extcon: int3496: Add GPIO ACPI mapping table
        extcon: int3496: Rename GPIO pins in accordance with binding
        vmw_vmci: handle the return value from pci_alloc_irq_vectors correctly
        ppdev: fix registering same device name
        parport: fix attempt to write duplicate procfiles
        auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches
        Drivers: hv: vmbus: Don't leak memory when a channel is rescinded
        Drivers: hv: vmbus: Don't leak channel ids
        Drivers: hv: util: don't forget to init host_ts.lock
        Drivers: hv: util: move waiting for release to hv_utils_transport itself
        vmbus: remove hv_event_tasklet_disable/enable
        vmbus: use rcu for per-cpu channel list
        mei: don't wait for os version message reply
        mei: fix deadlock on mei reset
        intel_th: pci: Add Gemini Lake support
        intel_th: pci: Add Denverton SOC support
        intel_th: Don't leak module refcount on failure to activate
        ...
      0dc82fa5
    • Linus Torvalds's avatar
      Merge tag 'driver-core-4.11-rc4' of... · 9e54ef9d
      Linus Torvalds authored
      Merge tag 'driver-core-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
      
      Pull driver core fix from Greg KH:
       "Here is a single kernfs fix for 4.11-rc4 that resolves a reported
        issue.
      
        It has been in linux-next with no reported issues"
      
      * tag 'driver-core-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
        kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()
      9e54ef9d
    • Linus Torvalds's avatar
      Merge tag 'tty-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · f1638fc6
      Linus Torvalds authored
      Pull tty/serial driver fixes from Greg KH:
       "Here are some tty and serial driver fixes for 4.11-rc4.
      
        One of these fix a long-standing issue in the ldisc code that was
        found by Dmitry Vyukov with his great fuzzing work. The other fixes
        resolve other reported issues, and there is one revert of a patch in
        4.11-rc1 that wasn't correct.
      
        All of these have been in linux-next for a while with no reported
        issues"
      
      * tag 'tty-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        tty: fix data race in tty_ldisc_ref_wait()
        tty: don't panic on OOM in tty_set_ldisc()
        Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"
        tty: acpi/spcr: QDF2400 E44 checks for wrong OEM revision
        serial: 8250_dw: Fix breakage when HAVE_CLK=n
        serial: 8250_dw: Honor clk_round_rate errors in dw8250_set_termios
      f1638fc6
    • Linus Torvalds's avatar
      Merge tag 'staging-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · 53b4d591
      Linus Torvalds authored
      Pull IIO driver fixes from Greg KH:
       "Here are some small IIO driver fixes for 4.11-rc4 that resolve a
        number of tiny reported issues. All of these have been in linux-next
        for a while with no reported issues"
      
      * tag 'staging-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        iio: imu: st_lsm6dsx: fix FIFO_CTRL2 overwrite during watermark configuration
        iio: adc: ti_am335x_adc: fix fifo overrun recovery
        iio: sw-device: Fix config group initialization
        iio: magnetometer: ak8974: remove incorrect __exit markups
        iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3
      53b4d591
    • Linus Torvalds's avatar
      Merge tag 'usb-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · e431e0e4
      Linus Torvalds authored
      Pull USB/PHY fixes from Greg KH:
       "Here are a number of small USB and PHY driver fixes for 4.11-rc4.
      
        Nothing major here, just an bunch of small fixes, and a handfull of
        good fixes from Johan for devices with crazy descriptors. There are a
        few new device ids in here as well.
      
        All of these have been in linux-next with no reported issues"
      
      * tag 'usb-4.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (26 commits)
        usb: gadget: f_hid: fix: Don't access hidg->req without spinlock held
        usb: gadget: udc: remove pointer dereference after free
        usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed
        usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's wBytesPerInterval
        usb: gadget: acm: fix endianness in notifications
        usb: dwc3: gadget: delay unmap of bounced requests
        USB: serial: qcserial: add Dell DW5811e
        usb: hub: Fix crash after failure to read BOS descriptor
        ACM gadget: fix endianness in notifications
        USB: usbtmc: fix probe error path
        USB: usbtmc: add missing endpoint sanity check
        USB: serial: option: add Quectel UC15, UC20, EC21, and EC25 modems
        usb: musb: fix possible spinlock deadlock
        usb: musb: dsps: fix iounmap in error and exit paths
        usb: musb: cppi41: don't check early-TX-interrupt for Isoch transfer
        usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk
        uwb: i1480-dfu: fix NULL-deref at probe
        uwb: hwa-rc: fix NULL-deref at probe
        USB: wusbcore: fix NULL-deref at probe
        USB: uss720: fix NULL-deref at probe
        ...
      e431e0e4
    • Linus Torvalds's avatar
      Merge tag 'powerpc-4.11-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 42234bf8
      Linus Torvalds authored
      Pull more powerpc fixes from Michael Ellerman:
       "These are all pretty minor. The fix for idle wakeup would be a bad bug
        but has not been observed in practice.
      
        The update to the gcc-plugins docs was Cc'ed to Kees and Jon, Kees
        OK'ed it going via powerpc and I didn't hear from Jon.
      
         - cxl: Route eeh events to all slices for pci_channel_io_perm_failure state
      
         - powerpc/64s: Fix idle wakeup potential to clobber registers
      
         - Revert "powerpc/64: Disable use of radix under a hypervisor"
      
         - gcc-plugins: update architecture list in documentation
      
        Thanks to: Andrew Donnellan, Nicholas Piggin, Paul Mackerras, Vaibhav
        Jain"
      
      * tag 'powerpc-4.11-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        gcc-plugins: update architecture list in documentation
        Revert "powerpc/64: Disable use of radix under a hypervisor"
        powerpc/64s: Fix idle wakeup potential to clobber registers
        cxl: Route eeh events to all slices for pci_channel_io_perm_failure state
      42234bf8
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 1c23de63
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Fix a memory leak on an error path, and two races when modifying
        inodes relating to the inline_data and metadata checksum features"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: fix two spelling nits
        ext4: lock the xattr block before checksuming it
        jbd2: don't leak memory if setting up journal fails
        ext4: mark inode dirty after converting inline directory
      1c23de63
  7. 25 Mar, 2017 14 commits