1. 03 Jun, 2016 40 commits
    • Konstantin Shkolnyy's avatar
      USB: serial: cp210x: fix hardware flow-control disable · e4e59834
      Konstantin Shkolnyy authored
      [ Upstream commit a377f9e9 ]
      
      A bug in the CRTSCTS handling caused RTS to alternate between
      
      CRTSCTS=0 => "RTS is transmit active signal" and
      CRTSCTS=1 => "RTS is used for receive flow control"
      
      instead of
      
      CRTSCTS=0 => "RTS is statically active" and
      CRTSCTS=1 => "RTS is used for receive flow control"
      
      This only happened after first having enabled CRTSCTS.
      Signed-off-by: default avatarKonstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
      Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control")
      Cc: stable <stable@vger.kernel.org>
      [johan: reword commit message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e4e59834
    • Konstantin Shkolnyy's avatar
      USB: cp210x: relocate private data from USB interface to port · f26c00e6
      Konstantin Shkolnyy authored
      [ Upstream commit e2ae67a3 ]
      
      This change is preparation for implementing a cp2108 bug workaround.
      The workaround requires storing some private data. Right now the data is
      attached to the USB interface and allocated in the attach() callback.
      The bug detection requires USB I/O which is done easier from port_probe()
      callback rather than attach(). Since the USB access functions take port
      as a parameter, and since the private data is used exclusively by these
      functions, it can be allocated in port_probe(). Also, all cp210x devices
      have exactly 1 port per USB iterface, so moving private data from the USB
      interface to port is trivial.
      Signed-off-by: default avatarKonstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f26c00e6
    • Lv Zheng's avatar
      ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings · 18a64704
      Lv Zheng authored
      [ Upstream commit 30c9bb0d ]
      
      The order of the _OSI related functionalities is as follows:
      
        acpi_blacklisted()
          acpi_dmi_osi_linux()
            acpi_osi_setup()
          acpi_osi_setup()
            acpi_update_interfaces() if "!*"
            <<<<<<<<<<<<<<<<<<<<<<<<
        parse_args()
          __setup("acpi_osi=")
            acpi_osi_setup_linux()
              acpi_update_interfaces() if "!*"
              <<<<<<<<<<<<<<<<<<<<<<<<
        acpi_early_init()
          acpi_initialize_subsystem()
            acpi_ut_initialize_interfaces()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        acpi_bus_init()
          acpi_os_initialize1()
            acpi_install_interface_handler(acpi_osi_handler)
            acpi_osi_setup_late()
              acpi_update_interfaces() for "!"
              >>>>>>>>>>>>>>>>>>>>>>>>
        acpi_osi_handler()
      
      Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
      line setting can override the DMI detection. That's why acpi_blacklisted()
      is put before __setup("acpi_osi=").
      
      Then we can notice the following wrong invocation order. There are
      acpi_update_interfaces() (marked by <<<<) calls invoked before
      acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible
      to use acpi_osi=!* correctly from OSI DMI table or from the command line.
      The use of acpi_osi=!* is meant to disable both ACPICA
      (acpi_gbl_supported_interfaces) and Linux specific strings
      (osi_setup_entries) while the ACPICA part should have stopped working
      because of the order issue.
      
      This patch fixes this issue by moving acpi_update_interfaces() to where
      it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be
      invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux
      specific strings are still handled in the original place in order to make
      the following command line working: acpi_osi=!* acpi_osi="Module Device".
      
      Note that since acpi_osi=!* is meant to further disable linux specific
      string comparing to the acpi_osi=!, there is no such use case in our bug
      fixing work and hence there is no one using acpi_osi=!* either from the
      command line or from the DMI quirks, this issue is just a theoretical
      issue.
      
      Fixes: 741d8128 (ACPI: Add facility to remove all _OSI strings)
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      Tested-by: default avatarLukas Wunner <lukas@wunner.de>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      18a64704
    • Lei Liu's avatar
      USB: serial: option: add even more ZTE device ids · 4d5aaca6
      Lei Liu authored
      [ Upstream commit 74d2a91a ]
      
      Add even more ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      Cc: stable <stable@vger.kernel.org>
      [johan: rebase and replace commit message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4d5aaca6
    • lei liu's avatar
      USB: serial: option: add more ZTE device ids · feb49862
      lei liu authored
      [ Upstream commit f0d09463 ]
      
      More ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      Cc: stable <stable@vger.kernel.org>
      [properly sort them - gregkh]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      feb49862
    • Andreas Werner's avatar
      mcb: Fixed bar number assignment for the gdd · 39a8fc74
      Andreas Werner authored
      [ Upstream commit f75564d3 ]
      
      The bar number is found in reg2 within the gdd. Therefore
      we need to change the assigment from reg1 to reg2 which
      is the correct location.
      Signed-off-by: default avatarAndreas Werner <andreas.werner@men.de>
      Fixes: '3764e82e' drivers: Introduce MEN Chameleon Bus
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      39a8fc74
    • Mathias Nyman's avatar
      usb: misc: usbtest: fix pattern tests for scatterlists. · 27094468
      Mathias Nyman authored
      [ Upstream commit cdc77c82 ]
      
      The current implemenentation restart the sent pattern for each entry in
      the sg list. The receiving end expects a continuous pattern, and test
      will fail unless scatterilst entries happen to be aligned with the
      pattern
      
      Fix this by calculating the pattern byte based on total sent size
      instead of just the current sg entry.
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Fixes: 8b524901 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing")
      Cc: <stable@vger.kernel.org> # v2.6.18+
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      27094468
    • Alan Stern's avatar
      usb: misc: usbtest: format the data pattern according to max packet size · cf2f44dd
      Alan Stern authored
      [ Upstream commit b9a6e8e1 ]
      
      With this change, the host and gadget doesn't need to agree with transfer
      length for comparing the data, since they doesn't know each other's
      transfer size, but know max packet size.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      (Fixed the 'line over 80 characters warning' by Peter Chen)
      Tested-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      cf2f44dd
    • Alan Stern's avatar
      USB: leave LPM alone if possible when binding/unbinding interface drivers · d0270cd8
      Alan Stern authored
      [ Upstream commit 6fb650d4 ]
      
      When a USB driver is bound to an interface (either through probing or
      by claiming it) or is unbound from an interface, the USB core always
      disables Link Power Management during the transition and then
      re-enables it afterward.  The reason is because the driver might want
      to prevent hub-initiated link power transitions, in which case the HCD
      would have to recalculate the various LPM parameters.  This
      recalculation takes place when LPM is re-enabled and the new
      parameters are sent to the device and its parent hub.
      
      However, if the driver does not want to prevent hub-initiated link
      power transitions then none of this work is necessary.  The parameters
      don't need to be recalculated, and LPM doesn't need to be disabled and
      re-enabled.
      
      It turns out that disabling and enabling LPM can be time-consuming,
      enough so that it interferes with user programs that want to claim and
      release interfaces rapidly via usbfs.  Since the usbfs kernel driver
      doesn't set the disable_hub_initiated_lpm flag, we can speed things up
      and get the user programs to work by leaving LPM alone whenever the
      flag isn't set.
      
      And while we're improving the way disable_hub_initiated_lpm gets used,
      let's also fix its kerneldoc.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarMatthew Giassa <matthew@giassa.net>
      CC: Mathias Nyman <mathias.nyman@intel.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d0270cd8
    • Schemmel Hans-Christoph's avatar
      USB: serial: option: add support for Cinterion PH8 and AHxx · 38f005d9
      Schemmel Hans-Christoph authored
      [ Upstream commit 444f94e9 ]
      
      Added support for Gemalto's Cinterion PH8 and AHxx products
      with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface.
      
      In addition some minor renaming and formatting.
      Signed-off-by: default avatarHans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
      [johan: sort current entries and trim trailing whitespace ]
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      38f005d9
    • Andreas Noever's avatar
      thunderbolt: Fix double free of drom buffer · 1dab35a8
      Andreas Noever authored
      [ Upstream commit 2ffa9a5d ]
      
      If tb_drom_read() fails, sw->drom is freed but not set to NULL.  sw->drom
      is then freed again in the error path of tb_switch_alloc().
      
      The bug can be triggered by unplugging a thunderbolt device shortly after
      it is detected by the thunderbolt driver.
      
      Clear sw->drom if tb_drom_read() fails.
      
      [bhelgaas: add Fixes:, stable versions of interest]
      Fixes: 343fcb8c ("thunderbolt: Fix nontrivial endpoint devices.")
      Signed-off-by: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.17+
      CC: Lukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1dab35a8
    • Zhao Qiang's avatar
      QE-UART: add "fsl,t1040-ucc-uart" to of_device_id · 4efcad52
      Zhao Qiang authored
      [ Upstream commit 11ca2b7a ]
      
      New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart.
      So add it.
      Signed-off-by: default avatarZhao Qiang <qiang.zhao@nxp.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4efcad52
    • Brian Bloniarz's avatar
      Fix OpenSSH pty regression on close · 29a7543e
      Brian Bloniarz authored
      [ Upstream commit 0f40fbbc ]
      
      OpenSSH expects the (non-blocking) read() of pty master to return
      EAGAIN only if it has received all of the slave-side output after
      it has received SIGCHLD. This used to work on pre-3.12 kernels.
      
      This fix effectively forces non-blocking read() and poll() to
      block for parallel i/o to complete for all ttys. It also unwinds
      these changes:
      
      1) f8747d4a
         tty: Fix pty master read() after slave closes
      
      2) 52bce7f8
         pty, n_tty: Simplify input processing on final close
      
      3) 1a48632f
         pty: Fix input race when closing
      
      Inspired by analysis and patch from Marc Aurele La France <tsi@tuyoix.net>
      Reported-by: default avatarVolth <openssh@volth.com>
      Reported-by: default avatarMarc Aurele La France <tsi@tuyoix.net>
      BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52
      BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492Signed-off-by: default avatarBrian Bloniarz <brian.bloniarz@gmail.com>
      Reviewed-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      29a7543e
    • Matthias Schiffer's avatar
      MIPS: ath79: make bootconsole wait for both THRE and TEMT · d46be343
      Matthias Schiffer authored
      [ Upstream commit f5b556c9 ]
      
      This makes the ath79 bootconsole behave the same way as the generic 8250
      bootconsole.
      
      Also waiting for TEMT (transmit buffer is empty) instead of just THRE
      (transmit buffer is not full) ensures that all characters have been
      transmitted before the real serial driver starts reconfiguring the serial
      controller (which would sometimes result in garbage being transmitted.)
      This change does not cause a visible performance loss.
      
      In addition, this seems to fix a hang observed in certain configurations on
      many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.
      
      A more complete follow-up patch will disable 8250 autoconfig for ath79
      altogether (the serial controller is detected as a 16550A, which is not
      fully compatible with the ath79 serial, and the autoconfig may lead to
      undefined behavior on ath79.)
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatthias Schiffer <mschiffer@universe-factory.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d46be343
    • Theodore Ts'o's avatar
      ext4: clean up error handling when orphan list is corrupted · e0934da7
      Theodore Ts'o authored
      [ Upstream commit 7827a7f6 ]
      
      Instead of just printing warning messages, if the orphan list is
      corrupted, declare the file system is corrupted.  If there are any
      reserved inodes in the orphaned inode list, declare the file system
      corrupted and stop right away to avoid doing more potential damage to
      the file system.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e0934da7
    • Theodore Ts'o's avatar
      ext4: fix hang when processing corrupted orphaned inode list · 06c6dcb8
      Theodore Ts'o authored
      [ Upstream commit c9eb13a9 ]
      
      If the orphaned inode list contains inode #5, ext4_iget() returns a
      bad inode (since the bootloader inode should never be referenced
      directly).  Because of the bad inode, we end up processing the inode
      repeatedly and this hangs the machine.
      
      This can be reproduced via:
      
         mke2fs -t ext4 /tmp/foo.img 100
         debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
         mount -o loop /tmp/foo.img /mnt
      
      (But don't do this if you are using an unpatched kernel if you care
      about the system staying functional.  :-)
      
      This bug was found by the port of American Fuzzy Lop into the kernel
      to find file system problems[1].  (Since it *only* happens if inode #5
      shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
      surprising that AFL needed two hours before it found it.)
      
      [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf
      
      Cc: stable@vger.kernel.org
      Reported by: Vegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      06c6dcb8
    • Raghava Aditya Renukunta's avatar
      aacraid: Fix for KDUMP driver hang · bb3412ec
      Raghava Aditya Renukunta authored
      [ Upstream commit 78cbccd3 ]
      
      When KDUMP is triggered the driver first talks to the firmware in INTX
      mode, but the adapter firmware is still in MSIX mode. Therefore the first
      driver command hangs since the driver is waiting for an INTX response and
      firmware gives a MSIX response. If when the OS is installed on a RAID
      drive created by the adapter KDUMP will hang since the driver does not
      receive a response in sync mode.
      
      Fixed by: Change the firmware to INTX mode if it is in MSIX mode before
      sending the first sync command.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      bb3412ec
    • Raghava Aditya Renukunta's avatar
      aacraid: Fix for aac_command_thread hang · ca7bb254
      Raghava Aditya Renukunta authored
      [ Upstream commit fc4bf75e ]
      
      Typically under error conditions, it is possible for aac_command_thread()
      to miss the wakeup from kthread_stop() and go back to sleep, causing it
      to hang aac_shutdown.
      
      In the observed scenario, the adapter is not functioning correctly and so
      aac_fib_send() never completes (or time-outs depending on how it was
      called). Shortly after aac_command_thread() starts it performs
      aac_fib_send(SendHostTime) which hangs. When aac_probe_one
      /aac_get_adapter_info send time outs, kthread_stop is called which breaks
      the command thread out of it's hang.
      
      The code will still go back to sleep in schedule_timeout() without
      checking kthread_should_stop() so it causes aac_probe_one to hang until
      the schedule_timeout() which is 30 minutes.
      
      Fixed by: Adding another kthread_should_stop() before schedule_timeout()
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ca7bb254
    • Raghava Aditya Renukunta's avatar
      aacraid: Relinquish CPU during timeout wait · e452f738
      Raghava Aditya Renukunta authored
      [ Upstream commit 07beca2b ]
      
      aac_fib_send has a special function case for initial commands during
      driver initialization using wait < 0(pseudo sync mode). In this case,
      the command does not sleep but rather spins checking for timeout.This
      loop is calls cpu_relax() in an attempt to allow other processes/threads
      to use the CPU, but this function does not relinquish the CPU and so the
      command will hog the processor. This was observed in a KDUMP
      "crashkernel" and that prevented the "command thread" (which is
      responsible for completing the command from being timed out) from
      starting because it could not get the CPU.
      
      Fixed by replacing "cpu_relax()" call with "schedule()"
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e452f738
    • Marc Zyngier's avatar
      arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables · 660cd223
      Marc Zyngier authored
      [ Upstream commit d4b9e079 ]
      
      The ARM architecture mandates that when changing a page table entry
      from a valid entry to another valid entry, an invalid entry is first
      written, TLB invalidated, and only then the new entry being written.
      
      The current code doesn't respect this, directly writing the new
      entry and only then invalidating TLBs. Let's fix it up.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      660cd223
    • H Hartley Sweeten's avatar
      staging: comedi: das1800: fix possible NULL dereference · 788da6ee
      H Hartley Sweeten authored
      [ Upstream commit d375278d ]
      
      DMA is optional with this driver. If it was not enabled the devpriv->dma
      pointer will be NULL.
      
      Fix the possible NULL pointer dereference when trying to disable the DMA
      channels in das1800_ai_cancel() and tidy up the comments to fix the
      checkpatch.pl issues:
      WARNING: line over 80 characters
      
      It's probably harmless in das1800_ai_setup_dma() because the 'desc' pointer
      will not be used if DMA is disabled but fix it there also.
      
      Fixes: 99dfc335 ("staging: comedi: das1800: remove depends on ISA_DMA_API limitation")
      Cc: <stable@vger.kernel.org> # 4.0+
      Signed-off-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Reviewed-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      788da6ee
    • Jiri Slaby's avatar
      TTY: n_gsm, fix false positive WARN_ON · 14023eff
      Jiri Slaby authored
      [ Upstream commit d175feca ]
      
      Dmitry reported, that the current cleanup code in n_gsm can trigger a
      warning:
      WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0()
      ...
      Call Trace:
      ...
       [<ffffffff81247ab9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:490
       [<ffffffff828d0456>] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048
       [<ffffffff828d4d87>] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386
       [<ffffffff828b9078>] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447
       [<ffffffff828b973a>] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567
       [<     inline     >] tiocsetd drivers/tty/tty_io.c:2650
       [<ffffffff828a14ea>] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883
      ...
      
      But this is a legal path when open fails to find a space in the
      gsm_mux array and tries to clean up. So make it a standard test
      instead of a warning.
      Reported-by: default avatar"Dmitry Vyukov" <dvyukov@google.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com
      Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      14023eff
    • David Müller's avatar
      serial: 8250_pci: fix divide error bug if baud rate is 0 · c91d8c2d
      David Müller authored
      [ Upstream commit 6f210c18 ]
      
      Since commit 21947ba6 ("serial: 8250_pci: replace switch-case by
      formula"), the 8250 driver crashes in the byt_set_termios() function
      with a divide error. This is caused by the fact that a baud rate of 0 (B0)
      is not handled properly. Fix it by falling back to B9600 in this case.
      Signed-off-by: default avatarDavid Müller <d.mueller@elsoft.ch>
      Fixes: 21947ba6 ("serial: 8250_pci: replace switch-case by formula")
      Cc: stable@vger.kernel.org
      Suggested-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c91d8c2d
    • Chris Bainbridge's avatar
      usb: core: hub: hub_port_init lock controller instead of bus · 3afbd3e3
      Chris Bainbridge authored
      [ Upstream commit feb26ac3 ]
      
      The XHCI controller presents two USB buses to the system - one for USB2
      and one for USB3. The hub init code (hub_port_init) is reentrant but
      only locks one bus per thread, leading to a race condition failure when
      two threads attempt to simultaneously initialise a USB2 and USB3 device:
      
      [    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
      [   13.183701] usb 3-3: device descriptor read/all, error -110
      
      On a test system this failure occurred on 6% of all boots.
      
      The call traces at the point of failure are:
      
      Call Trace:
       [<ffffffff81b9bab7>] schedule+0x37/0x90
       [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
       [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
       [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
       [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
       [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Call Trace:
       [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
       [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
       [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
       [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Which results from the two call chains:
      
      hub_port_init
       usb_get_device_descriptor
        usb_get_descriptor
         usb_control_msg
          usb_internal_control_msg
           usb_start_wait_urb
            usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
      
      hub_port_init
       hub_set_address
        xhci_address_device
         xhci_setup_device
      
      Mathias Nyman explains the current behaviour violates the XHCI spec:
      
       hub_port_reset() will end up moving the corresponding xhci device slot
       to default state.
      
       As hub_port_reset() is called several times in hub_port_init() it
       sounds reasonable that we could end up with two threads having their
       xhci device slots in default state at the same time, which according to
       xhci 4.5.3 specs still is a big no no:
      
       "Note: Software shall not transition more than one Device Slot to the
        Default State at a time"
      
       So both threads fail at their next task after this.
       One fails to read the descriptor, and the other fails addressing the
       device.
      
      Fix this in hub_port_init by locking the USB controller (instead of an
      individual bus) to prevent simultaneous initialisation of both buses.
      
      Fixes: 638139eb ("usb: hub: allow to process more usb hub events in parallel")
      Link: https://lkml.org/lkml/2016/2/8/312
      Link: https://lkml.org/lkml/2016/2/4/748Signed-off-by: default avatarChris Bainbridge <chris.bainbridge@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      3afbd3e3
    • Luke Dashjr's avatar
      btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl · 7ac47d24
      Luke Dashjr authored
      [ Upstream commit 4c63c245 ]
      
      32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can
      be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr
      fail.
      Signed-off-by: default avatarLuke Dashjr <luke-jr+git@utopios.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7ac47d24
    • Andrew Jeffery's avatar
      pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range · 93ddb49f
      Andrew Jeffery authored
      [ Upstream commit 71324fdc ]
      
      The range is registered into a linked list which can be referenced
      throughout the lifetime of the driver. Ensure the range's memory is useful
      for the same lifetime by adding it to the driver's private data structure.
      
      The bug was introduced in the driver's initial commit, which was present in
      v3.10.
      
      Fixes: f0b9a7e5 ("pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndrew Jeffery <andrew@aj.id.au>
      Acked-by: default avatarTomasz Figa <tomasz.figa@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      93ddb49f
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. · a774710f
      Vittorio Gambaletta (VittGam) authored
      [ Upstream commit 0f9edcdd ]
      
      The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
      (active high instead of active low).
      
      The same PCI Subsystem ID is used by both cards, which are based on
      the same Atheros MB92 design.
      
      Cc: <linux-wireless@vger.kernel.org>
      Cc: <ath9k-devel@qca.qualcomm.com>
      Cc: <ath9k-devel@lists.ath9k.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a774710f
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Add a module parameter to invert LED polarity. · d24f503d
      Vittorio Gambaletta (VittGam) authored
      [ Upstream commit cd84042c ]
      
      The LED can be active high instead of active low on some hardware.
      
      Add the led_active_high module parameter. It defaults to -1 to obey
      platform data as before.
      
      Setting the parameter to 1 or 0 will force the LED respectively
      active high or active low.
      
      Cc: <linux-wireless@vger.kernel.org>
      Cc: <ath9k-devel@qca.qualcomm.com>
      Cc: <ath9k-devel@lists.ath9k.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d24f503d
    • Krzysztof Kozlowski's avatar
      crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks · 6be9e6ec
      Krzysztof Kozlowski authored
      [ Upstream commit 79152e8d ]
      
      The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
      testing 8 kB size blocks:
      
      	$ sudo modprobe tcrypt sec=1 mode=500
      	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
      	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
      	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
      	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
      	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
      	test 4 (128 bit key, 8192 byte blocks):
      
      This was caused by a race issue of missed BRDMA_DONE ("Block cipher
      Receiving DMA") interrupt. Device starts processing the data in DMA mode
      immediately after setting length of DMA block: receiving (FCBRDMAL) or
      transmitting (FCBTDMAL). The driver sets these lengths from interrupt
      handler through s5p_set_dma_indata() function (or xxx_setdata()).
      
      However the interrupt handler was first dealing with receive buffer
      (dma-unmap old, dma-map new, set receive block length which starts the
      operation), then with transmit buffer and finally was clearing pending
      interrupts (FCINTPEND). Because of the time window between setting
      receive buffer length and clearing pending interrupts, the operation on
      receive buffer could end already and driver would miss new interrupt.
      
      User manual for Exynos5422 confirms in example code that setting DMA
      block lengths should be the last operation.
      
      The tcrypt hang could be also observed in following blocked-task dmesg:
      
      INFO: task modprobe:258 blocked for more than 120 seconds.
            Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      modprobe        D c06b09d8     0   258    256 0x00000000
      [<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac)
      [<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178)
      [<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144)
      [<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt])
      [<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt])
      [<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
      [<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c)
      [<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac)
      [<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08)
      [<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98)
      [<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
      
      Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6be9e6ec
    • Krzysztof Kozlowski's avatar
      crypto: s5p-sss - Remove useless hash interrupt handler · cc706ae1
      Krzysztof Kozlowski authored
      [ Upstream commit 55124425 ]
      
      Beside regular feed control interrupt, the driver requires also hash
      interrupt for older SoCs (samsung,s5pv210-secss). However after
      requesting it, the interrupt handler isn't doing anything with it, not
      even clearing the hash interrupt bit.
      
      Driver does not provide hash functions so it is safe to remove the hash
      interrupt related code and to not require the interrupt in Device Tree.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      cc706ae1
    • Ulf Hansson's avatar
      PM / Runtime: Fix error path in pm_runtime_force_resume() · dae205d1
      Ulf Hansson authored
      [ Upstream commit 0ae3aeef ]
      
      As pm_runtime_set_active() may fail because the device's parent isn't
      active, we can end up executing the ->runtime_resume() callback for the
      device when it isn't allowed.
      
      Fix this by invoking pm_runtime_set_active() before running the callback
      and let's also deal with the error code.
      
      Fixes: 37f20416 (PM: Add pm_runtime_suspend|resume_force functions)
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      dae205d1
    • Hari Bathini's avatar
      powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel · b9a5eef0
      Hari Bathini authored
      [ Upstream commit 8ed8ab40 ]
      
      Some of the interrupt vectors on 64-bit POWER server processors are only
      32 bytes long (8 instructions), which is not enough for the full
      first-level interrupt handler. For these we need to branch to an
      out-of-line (OOL) handler. But when we are running a relocatable kernel,
      interrupt vectors till __end_interrupts marker are copied down to real
      address 0x100. So, branching to labels (ie. OOL handlers) outside this
      section must be handled differently (see LOAD_HANDLER()), considering
      relocatable kernel, which would need at least 4 instructions.
      
      However, branching from interrupt vector means that we corrupt the
      CFAR (come-from address register) on POWER7 and later processors as
      mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)
      that contains the part up to the point where the CFAR is saved in the
      PACA should be part of the short interrupt vectors before we branch out
      to OOL handlers.
      
      But as mentioned already, there are interrupt vectors on 64-bit POWER
      server processors that are only 32 bytes long (like vectors 0x4f00,
      0x4f20, etc.), which cannot accomodate the above two cases at the same
      time owing to space constraint. Currently, in these interrupt vectors,
      we simply branch out to OOL handlers, without using LOAD_HANDLER(),
      which leaves us vulnerable when running a relocatable kernel (eg. kdump
      case). While this has been the case for sometime now and kdump is used
      widely, we were fortunate not to see any problems so far, for three
      reasons:
      
        1. In almost all cases, production kernel (relocatable) is used for
           kdump as well, which would mean that crashed kernel's OOL handler
           would be at the same place where we end up branching to, from short
           interrupt vector of kdump kernel.
        2. Also, OOL handler was unlikely the reason for crash in almost all
           the kdump scenarios, which meant we had a sane OOL handler from
           crashed kernel that we branched to.
        3. On most 64-bit POWER server processors, page size is large enough
           that marking interrupt vector code as executable (see commit
           429d2e83) leads to marking OOL handler code from crashed kernel,
           that sits right below interrupt vector code from kdump kernel, as
           executable as well.
      
      Let us fix this by moving the __end_interrupts marker down past OOL
      handlers to make sure that we also copy OOL handlers to real address
      0x100 when running a relocatable kernel.
      
      This fix has been tested successfully in kdump scenario, on an LPAR with
      4K page size by using different default/production kernel and kdump
      kernel.
      
      Also tested by manually corrupting the OOL handlers in the first kernel
      and then kdump'ing, and then causing the OOL handlers to fire - mpe.
      
      Fixes: c1fb6816 ("powerpc: Add relocation on exception vector handlers")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHari Bathini <hbathini@linux.vnet.ibm.com>
      Signed-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b9a5eef0
    • Takashi Iwai's avatar
      Bluetooth: vhci: Fix race at creating hci device · 599a6fc3
      Takashi Iwai authored
      [ Upstream commit c7c999cb ]
      
      hci_vhci driver creates a hci device object dynamically upon each
      HCI_VENDOR_PKT write.  Although it checks the already created object
      and returns an error, it's still racy and may build multiple hci_dev
      objects concurrently when parallel writes are performed, as the device
      tracks only a single hci_dev object.
      
      This patch introduces a mutex to protect against the concurrent device
      creations.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      599a6fc3
    • Akshay Bhat's avatar
      hwmon: (ads7828) Enable internal reference · ef83ef60
      Akshay Bhat authored
      [ Upstream commit 7a18afe8 ]
      
      On ads7828 the internal reference defaults to off upon power up. When
      using internal reference, it needs to be turned on and the voltage needs
      to settle before normal conversion cycle can be started. Hence perform a
      dummy read in the probe to enable the internal reference allowing the
      voltage to settle before performing a normal read.
      
      Without this fix, the first read from the ADC when using internal
      reference always returns incorrect data.
      Signed-off-by: default avatarAkshay Bhat <akshay.bhat@timesys.com>
      Cc: stable@vger.kernel.org # v4.1+
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ef83ef60
    • Michal Nazarewicz's avatar
      usb: f_mass_storage: test whether thread is running before starting another · f5a300ce
      Michal Nazarewicz authored
      [ Upstream commit f78bbcae ]
      
      When binding the function to usb_configuration, check whether the thread
      is running before starting another one.  Without that, when function
      instance is added to multiple configurations, fsg_bing starts multiple
      threads with all but the latest one being forgotten by the driver.  This
      leads to obvious thread leaks, possible lockups when trying to halt the
      machine and possible more issues.
      
      This fixes issues with legacy/multi¹ gadget as well as configfs gadgets
      when mass_storage function is added to multiple configurations.
      
      This change also simplifies API since the legacy gadgets no longer need
      to worry about starting the thread by themselves (which was where bug
      in legacy/multi was in the first place).
      
      N.B., this patch doesn’t address adding single mass_storage function
      instance to a single configuration twice.  Thankfully, there’s no
      legitimate reason for such setup plus, if I’m not mistaken, configfs
      gadget doesn’t even allow it to be expressed.
      
      ¹ I have no example failure though.  Conclusion that legacy/multi has
        a bug is based purely on me reading the code.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Tested-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f5a300ce
    • Krzysztof Opasiak's avatar
      usb: gadget: mass_storage: Use static array for luns · 799f55d2
      Krzysztof Opasiak authored
      [ Upstream commit dd02ea5a ]
      
      This patch replace dynamicly allocated luns array with static one.
      This simplifies the code of mass storage function and modules.
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      799f55d2
    • Krzysztof Opasiak's avatar
      usb: gadget: mass_storage: Fix freeing luns sysfs implementation · a27b3984
      Krzysztof Opasiak authored
      [ Upstream commit 5542f58c ]
      
      Use device_is_registered() instad of sysfs flag to determine if
      we should free sysfs representation of particular LUN.
      
      sysfs flag in fsg common determines if luns attributes should be
      exposed using sysfs. This flag is used when creating and freeing
      luns. Unfortunately there is no guarantee that this flag will not
      be changed between creation and removal of particular LUN. Especially
      because of lun.0 which is created during allocating instance of
      function. This may lead to resource leak or NULL pointer dereference:
      
      [   62.539925] Unable to handle kernel NULL pointer dereference at virtual address 00000044
      [   62.548014] pgd = ec994000
      [   62.550679] [00000044] *pgd=6d7be831, *pte=00000000, *ppte=00000000
      [   62.556933] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      [   62.562310] Modules linked in: g_mass_storage(+)
      [   62.566916] CPU: 2 PID: 613 Comm: insmod Not tainted 4.2.0-rc4-00077-ge29ee91-dirty #125
      [   62.574984] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [   62.581061] task: eca56e80 ti: eca76000 task.ti: eca76000
      [   62.586450] PC is at kernfs_find_ns+0x8/0xe8
      [   62.590698] LR is at kernfs_find_and_get_ns+0x30/0x48
      [   62.595732] pc : [<c01277c0>]    lr : [<c0127b88>]    psr: 40010053
      [   62.595732] sp : eca77c40  ip : eca77c38  fp : 000008c1
      [   62.607187] r10: 00000001  r9 : c0082f38  r8 : ed41ce40
      [   62.612395] r7 : c05c1484  r6 : 00000000  r5 : 00000000  r4 : c0814488
      [   62.618904] r3 : 00000000  r2 : 00000000  r1 : c05c1484  r0 : 00000000
      [   62.625417] Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment user
      [   62.632620] Control: 10c5387d  Table: 6c99404a  DAC: 00000015
      [   62.638348] Process insmod (pid: 613, stack limit = 0xeca76210)
      [   62.644251] Stack: (0xeca77c40 to 0xeca78000)
      [   62.648594] 7c40: c0814488 00000000 00000000 c05c1484 ed41ce40 c0127b88 00000000 c0824888
      [   62.656753] 7c60: ed41d038 ed41d030 ed41d000 c012af4c 00000000 c0824858 ed41d038 c02e3314
      [   62.664912] 7c80: ed41d030 00000000 ed41ce04 c02d9e8c c070eda8 eca77cb4 000008c1 c058317c
      [   62.673071] 7ca0: 000008c1 ed41d030 ed41ce00 ed41ce04 ed41d000 c02da044 ed41cf48 c0375870
      [   62.681230] 7cc0: ed9d3c04 ed9d3c00 ed52df80 bf000940 fffffff0 c03758f4 c03758c0 00000000
      [   62.689389] 7ce0: bf000564 c03614e0 ed9d3c04 bf000194 c0082f38 00000001 00000000 c0000100
      [   62.697548] 7d00: c0814488 c0814488 c086b1dc c05893a8 00000000 ed7e8320 00000000 c0128b88
      [   62.705707] 7d20: ed8a6b40 00000000 00000000 ed410500 ed8a6b40 c0594818 ed7e8320 00000000
      [   62.713867] 7d40: 00000000 c0129f20 00000000 c082c444 ed8a6b40 c012a684 00001000 00000000
      [   62.722026] 7d60: c0594818 c082c444 00000000 00000000 ed52df80 ed52df80 00000000 00000000
      [   62.730185] 7d80: 00000000 00000000 00000001 00000002 ed8e9b70 ed52df80 bf0006d0 00000000
      [   62.738345] 7da0: ed8e9b70 ed410500 ed618340 c036129c ed8c1c00 bf0006d0 c080b158 ed8c1c00
      [   62.746504] 7dc0: bf0006d0 c080b158 ed8c1c08 ed410500 c0082f38 ed618340 000008c1 c03640ac
      [   62.754663] 7de0: 00000000 bf0006d0 c082c8dc c080b158 c080b158 c03642d4 00000000 bf003000
      [   62.762822] 7e00: 00000000 c0009784 00000000 00000001 00000000 c05849b0 00000002 ee7ab780
      [   62.770981] 7e20: 00000002 ed4105c0 0000c53e 000000d0 c0808600 eca77e5c 00000004 00000000
      [   62.779140] 7e40: bf000000 c0095680 c08075a0 ee001f00 ed4105c0 c00cadc0 ed52df80 bf000780
      [   62.787300] 7e60: ed4105c0 bf000780 00000001 bf0007c8 c0082f38 ed618340 000008c1 c0083e24
      [   62.795459] 7e80: 00000001 bf000780 00000001 eca77f58 00000001 bf000780 00000001 c00857f4
      [   62.803618] 7ea0: bf00078c 00007fff 00000000 c00835b4 eca77f58 00000000 c0082fac eca77f58
      [   62.811777] 7ec0: f05038c0 0003b008 bf000904 00000000 00000000 bf00078c 6e72656b 00006c65
      [   62.819936] 7ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [   62.828095] 7f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [   62.836255] 7f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000003 0003b008
      [   62.844414] 7f40: 0000017b c000f5c8 eca76000 00000000 0003b008 c0085df8 f04ef000 0001b8a9
      [   62.852573] 7f60: f0503258 f05030c2 f0509fe8 00000968 00000dc8 00000000 00000000 00000000
      [   62.860732] 7f80: 00000029 0000002a 00000011 00000000 0000000a 00000000 33f6eb00 0003b008
      [   62.868892] 7fa0: bef01cac c000f400 33f6eb00 0003b008 00000003 0003b008 00000000 00000003
      [   62.877051] 7fc0: 33f6eb00 0003b008 bef01cac 0000017b 00000000 0003b008 0000000b 0003b008
      [   62.885210] 7fe0: bef01ae0 bef01ad0 0001dc23 b6e8c162 800b0070 00000003 c0c0c0c0 c0c0c0c0
      [   62.893380] [<c01277c0>] (kernfs_find_ns) from [<c0824888>] (pm_qos_latency_tolerance_attr_group+0x0/0x10)
      [   62.903005] Code: e28dd00c e8bd80f0 e92d41f0 e2923000 (e1d0e4b4)
      [   62.909115] ---[ end trace 02fb4373ef095c7b ]---
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a27b3984
    • Krzysztof Opasiak's avatar
      usb: gadget: mass_storage: Free buffers if create lun fails · c387f28f
      Krzysztof Opasiak authored
      [ Upstream commit 903588a9 ]
      
      Creation of LUN 0 may fail (for example due to ENOMEM).
      As fsg_common_set_num_buffers() does some memory allocation
      we should free it before it becomes unavailable.
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c387f28f
    • Tiffany Lin's avatar
      [media] media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32 · 5b1e4894
      Tiffany Lin authored
      [ Upstream commit baf43c6e ]
      
      In v4l2-compliance utility, test VIDIOC_CREATE_BUFS will check whether reserved
      filed of v4l2_create_buffers filled with zero
      Reserved field is filled with zero in v4l_create_bufs.
      This patch copy reserved field of v4l2_create_buffer from kernel space to user
      space
      Signed-off-by: default avatarTiffany Lin <tiffany.lin@mediatek.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: <stable@vger.kernel.org>      # for v3.19 and up
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5b1e4894
    • Andy Shevchenko's avatar
      mfd: intel_quark_i2c_gpio: load gpio driver first · 633b243b
      Andy Shevchenko authored
      [ Upstream commit c39dc960 ]
      
      On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
      is able to generate interrupt, but interrupt line is connected to GPIO. That's
      why we have to have GPIO driver in place when we will probe i2c host with
      device connected to it.
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      633b243b