1. 16 Aug, 2017 40 commits
    • Marc Zyngier's avatar
      xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue · 0e1f0eae
      Marc Zyngier authored
      commit 8466489e upstream.
      
      The Renesas uPD72020x XHCI controller seems to suffer from a really
      annoying bug, where it may retain some of its DMA programming across a XHCI
      reset, and despite the driver correctly programming new DMA addresses.
      This is visible if the device has been using 64-bit DMA addresses, and is
      then switched to using 32-bit DMA addresses.  The top 32 bits of the
      address (now zero) are ignored are replaced by the 32 bits from the
      *previous* programming.  Sticking with 64-bit DMA always works, but doesn't
      seem very appropriate.
      
      A PCI reset of the device restores the normal functionality, which is done
      at probe time.  Unfortunately, this has to be done before any quirk has
      been discovered, hence the intrusive nature of the fix.
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e1f0eae
    • Marc Zyngier's avatar
      PCI: Add pci_reset_function_locked() · ea9647cf
      Marc Zyngier authored
      commit a477b9cd upstream.
      
      The implementation of PCI workarounds may require that the device is reset
      from its probe function.  This implies that the PCI device lock is already
      held, and makes calling pci_reset_function() impossible (since it will
      itself try to take that lock).
      
      Add pci_reset_function_locked(), which is the equivalent of
      pci_reset_function(), except that it requires the PCI device lock to be
      already held by the caller.
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      [bhelgaas: folded in fix for conflict with 52354b9d ("PCI: Remove
      __pci_dev_reset() and pci_dev_reset()")]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea9647cf
    • Christoph Hellwig's avatar
      PCI: Remove __pci_dev_reset() and pci_dev_reset() · c71305e6
      Christoph Hellwig authored
      commit 52354b9d upstream.
      
      Implement the reset probing / reset chain directly in
      __pci_probe_reset_function() and __pci_reset_function_locked()
      respectively.
      
      Link: http://lkml.kernel.org/r/20170601111039.8913-4-hch@lst.deSigned-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c71305e6
    • Christoph Hellwig's avatar
      PCI: Protect pci_error_handlers->reset_notify() usage with device_lock() · 31e71939
      Christoph Hellwig authored
      commit b014e96d upstream.
      
      Every method in struct device_driver or structures derived from it like
      struct pci_driver MUST provide exclusion vs the driver's ->remove() method,
      usually by using device_lock().
      
      Protect use of pci_error_handlers->reset_notify() by holding the device
      lock while calling it.
      
      Note:
      
        - pci_dev_lock() calls device_lock() in addition to blocking user-space
          config accesses.
      
        - pci_err_handlers->reset_notify() is used inside
          pci_dev_save_and_disable() and pci_dev_restore().  We could hold the
          device lock directly in pci_reset_notify(), but we expand the region
          since we have several calls following each other.
      
      Without this, ->reset_notify() may race with ->remove() calls, which can be
      easily triggered in NVMe.
      
      [bhelgaas: changelog, add pci_reset_notify() comment]
      [bhelgaas: fold in fix from Dan Carpenter <dan.carpenter@oracle.com>:
      http://lkml.kernel.org/r/20170701135323.x5vaj4e2wcs2mcro@mwanda]
      Link: http://lkml.kernel.org/r/20170601111039.8913-2-hch@lst.deReported-by: default avatarRakesh Pandit <rakesh@tuxera.com>
      Tested-by: default avatarRakesh Pandit <rakesh@tuxera.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31e71939
    • Sandeep Singh's avatar
      usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume · b23ef7b8
      Sandeep Singh authored
      commit e788787e upstream.
      
      Certain HP keyboards would keep inputting a character automatically which
      is the wake-up key after S3 resume
      
      On some AMD platforms USB host fails to respond (by holding resume-K) to
      USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures
      that resume is signaled for at least 20 ms (TDRSMDN), which is defined in
      USB 2.0 spec. The result is that the keyboard is out of function.
      
      In SNPS USB design, the host responds to the resume request only after
      system gets back to S0 and the host gets to functional after the internal
      HW restore operation that is more than 1 second after the initial resume
      request from the USB device.
      
      As a workaround for specific keyboard ID(HP Keyboards), applying port reset
      after resume when the keyboard is plugged in.
      Signed-off-by: default avatarSandeep Singh <Sandeep.Singh@amd.com>
      Signed-off-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
      Reviewed-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b23ef7b8
    • Kai-Heng Feng's avatar
      usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter · 73e7a2dc
      Kai-Heng Feng authored
      commit 7496cfe5 upstream.
      
      Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
      connect to Realtek r8153.
      
      The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
      can make it work.
      
      Since another r8153 dongle at my hand does not have the issue, so add
      the quirk to the Genesys Logic hub instead.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73e7a2dc
    • Bin Liu's avatar
      usb: core: unlink urbs from the tail of the endpoint's urb_list · 488f4d80
      Bin Liu authored
      commit 2eac1362 upstream.
      
      While unlink an urb, if the urb has been programmed in the controller,
      the controller driver might do some hw related actions to tear down the
      urb.
      
      Currently usb_hcd_flush_endpoint() passes each urb from the head of the
      endpoint's urb_list to the controller driver, which could make the
      controller driver think each urb has been programmed and take the
      unnecessary actions for each urb.
      
      This patch changes the behavior in usb_hcd_flush_endpoint() to pass the
      urbs from the tail of the list, to avoid any unnecessary actions in an
      controller driver.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      488f4d80
    • Alan Stern's avatar
      USB: Check for dropped connection before switching to full speed · 7ff799af
      Alan Stern authored
      commit 94c43b98 upstream.
      
      Some buggy USB disk adapters disconnect and reconnect multiple times
      during the enumeration procedure.  This may lead to a device
      connecting at full speed instead of high speed, because when the USB
      stack sees that a device isn't able to enumerate at high speed, it
      tries to hand the connection over to a full-speed companion
      controller.
      
      The logic for doing this is careful to check that the device is still
      connected.  But this check is inadequate if the device disconnects and
      reconnects before the check is done.  The symptom is that a device
      works, but much more slowly than it is capable of operating.
      
      The situation was made worse recently by commit 22547c4c ("usb:
      hub: Wait for connection to be reestablished after port reset"), which
      increases the delay following a reset before a disconnect is
      recognized, thus giving the device more time to reconnect.
      
      This patch makes the check more robust.  If the device was
      disconnected at any time during enumeration, we will now skip the
      full-speed handover.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarZdenek Kabelac <zkabelac@redhat.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ff799af
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: Fix UGCTRL2 value for R-Car Gen3 · c45923eb
      Yoshihiro Shimoda authored
      commit 2acecd58 upstream.
      
      The latest HW manual (Rev.0.55) shows us this UGCTRL2.VBUSSEL bit.
      If the bit sets to 1, the VBUS drive is controlled by phy related
      registers (called "UCOM Registers" on the manual). Since R-Car Gen3
      environment will control VBUS by phy-rcar-gen3-usb2 driver,
      the UGCTRL2.VBUSSEL bit should be set to 1. So, this patch fixes
      the register's value. Otherwise, even if the ID pin indicates to
      peripheral, the R-Car will output USBn_PWEN to 1 when a host driver
      is running.
      
      Fixes: de18757e ("usb: renesas_usbhs: add R-Car Gen3 power control"
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c45923eb
    • Yoshihiro Shimoda's avatar
      usb: gadget: udc: renesas_usb3: Fix usb_gadget_giveback_request() calling · f5324020
      Yoshihiro Shimoda authored
      commit aca5b9eb upstream.
      
      According to the gadget.h, a "complete" function will always be called
      with interrupts disabled. However, sometimes usb3_request_done() function
      is called with interrupts enabled. So, this function should be held
      by spin_lock_irqsave() to disable interruption. Also, this driver has
      to call spin_unlock() to avoid spinlock recursion by this driver before
      calling usb_gadget_giveback_request().
      Reported-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      Tested-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5324020
    • Bart Van Assche's avatar
      block: Make blk_mq_delay_kick_requeue_list() rerun the queue at a quiet time · 79263486
      Bart Van Assche authored
      commit d4acf365 upstream.
      
      The blk_mq_delay_kick_requeue_list() function is used by the device
      mapper and only by the device mapper to rerun the queue and requeue
      list after a delay. This function is called once per request that
      gets requeued. Modify this function such that the queue is run once
      per path change event instead of once per request that is requeued.
      
      Fixes: commit 2849450a ("blk-mq: introduce blk_mq_delay_kick_requeue_list()")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@wdc.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79263486
    • Luis R. Rodriguez's avatar
      firmware: avoid invalid fallback aborts by using killable wait · 67e1a98e
      Luis R. Rodriguez authored
      commit 260d9f2f upstream.
      
      Commit 0cb64249 ("firmware_loader: abort request if wait_for_completion
      is interrupted") added via 4.0 added support to abort the fallback mechanism
      when a signal was detected and wait_for_completion_interruptible() returned
      -ERESTARTSYS -- for instance when a user hits CTRL-C. The abort was overly
      *too* effective.
      
      When a child process terminates (successful or not) the signal SIGCHLD can
      be sent to the parent process which ran the child in the background and
      later triggered a sync request for firmware through a sysfs interface which
      relies on the fallback mechanism. This signal in turn can be recieved by the
      interruptible wait we constructed on firmware_class and detects it as an
      abort *before* userspace could get a chance to write the firmware. Upon
      failure -EAGAIN is returned, so userspace is also kept in the dark about
      exactly what happened.
      
      We can reproduce the issue with the fw_fallback.sh selftest:
      
      Before this patch:
      $ sudo tools/testing/selftests/firmware/fw_fallback.sh
      ...
      tools/testing/selftests/firmware/fw_fallback.sh: error - sync firmware request cancelled due to SIGCHLD
      
      After this patch:
      $ sudo tools/testing/selftests/firmware/fw_fallback.sh
      ...
      tools/testing/selftests/firmware/fw_fallback.sh: SIGCHLD on sync ignored as expected
      
      Fix this by making the wait killable -- only killable by SIGKILL (kill -9).
      We loose the ability to allow userspace to cancel a write with CTRL-C
      (SIGINT), however its been decided the compromise to require SIGKILL is
      worth the gains.
      
      Chances of this issue occuring are low due to the number of drivers upstream
      exclusively relying on the fallback mechanism for firmware (2 drivers),
      however this is observed in the field with custom drivers with sysfs
      triggers to load firmware. Only distributions relying on the fallback
      mechanism are impacted as well. An example reported issue was on Android,
      as follows:
      
      1) Android init (pid=1) fork()s (say pid=42) [this child process is totally
         unrelated to firmware loading, it could be sleep 2; for all we care ]
      2) Android init (pid=1) does a write() on a (driver custom) sysfs file which
         ends up calling request_firmware() kernel side
      3) The firmware loading fallback mechanism is used, the request is sent to
         userspace and pid 1 waits in the kernel on wait_*
      4) before firmware loading completes pid 42 dies (for any reason, even
         normal termination)
      5) Kernel delivers SIGCHLD to pid=1 to tell it a child has died, which
         causes -ERESTARTSYS to be returned from wait_*
      6) The kernel's wait aborts and return -EAGAIN for the
         request_firmware() caller.
      
      Fixes: 0cb64249 ("firmware_loader: abort request if wait_for_completion is interrupted")
      Suggested-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Suggested-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Tested-by: default avatarMartin Fuzzey <mfuzzey@parkeon.com>
      Reported-by: default avatarMartin Fuzzey <mfuzzey@parkeon.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67e1a98e
    • Luis R. Rodriguez's avatar
      firmware: fix batched requests - send wake up on failure on direct lookups · b1b5c0b2
      Luis R. Rodriguez authored
      commit 90d41e74 upstream.
      
      Fix batched requests from waiting forever on failure.
      
      The firmware API batched requests feature has been broken since the API call
      request_firmware_direct() was introduced on commit bba3a87e ("firmware:
      Introduce request_firmware_direct()"), added on v3.14 *iff* the firmware
      being requested was not present in *certain kernel builds* [0].
      
      When no firmware is found the worker which goes on to finish never informs
      waiters queued up of this, so any batched request will stall in what seems
      to be forever (MAX_SCHEDULE_TIMEOUT). Sadly, a reboot will also stall, as
      the reboot notifier was only designed to kill custom fallback workers. The
      issue seems to the user as a type of soft lockup, what *actually* happens
      underneath the hood is a wait call which never completes as we failed to
      issue a completion on error.
      
      For device drivers with optional firmware schemes (ie, Intel iwlwifi, or
      Netronome -- even though it uses request_firmware() and not
      request_firmware_direct()), this could mean that when you boot a system with
      multiple cards the firmware will seem to never load on the system, or that
      the card is just not responsive even the driver initialization. Due to
      differences in scheduling possible this should not always trigger --
      one would need to to ensure that multiple requests are in place at the
      right time for this to work, also release_firmware() must not be called
      prior to any other incoming request. The complexity may not be worth
      supporting batched requests in the future given the wait mechanism is
      only used also for the fallback mechanism. We'll keep it for now and
      just fix it.
      
      Its reported that at least with the Intel WiFi cards on one system this
      issue was creeping up 50% of the boots [0].
      
      Before this commit batched requests testing revealed:
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Most common Linux distribution setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     FAIL                OK
      request_firmware_direct()              FAIL                OK
      request_firmware_nowait(uevent=true)   FAIL                OK
      request_firmware_nowait(uevent=false)  FAIL                OK
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=n
      
      Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     FAIL                OK
      request_firmware_direct()              FAIL                OK
      request_firmware_nowait(uevent=true)   FAIL                OK
      request_firmware_nowait(uevent=false)  FAIL                OK
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Google Android setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     OK                  OK
      request_firmware_direct()              FAIL                OK
      request_firmware_nowait(uevent=true)   OK                  OK
      request_firmware_nowait(uevent=false)  OK                  OK
      ============================================================================
      
      Ater this commit batched testing results:
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Most common Linux distribution setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     OK                  OK
      request_firmware_direct()              OK                  OK
      request_firmware_nowait(uevent=true)   OK                  OK
      request_firmware_nowait(uevent=false)  OK                  OK
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=n
      
      Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     OK                  OK
      request_firmware_direct()              OK                  OK
      request_firmware_nowait(uevent=true)   OK                  OK
      request_firmware_nowait(uevent=false)  OK                  OK
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Google Android setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     OK                  OK
      request_firmware_direct()              OK                  OK
      request_firmware_nowait(uevent=true)   OK                  OK
      request_firmware_nowait(uevent=false)  OK                  OK
      ============================================================================
      
      [0] https://bugzilla.kernel.org/show_bug.cgi?id=195477
      
      Fixes: bba3a87e ("firmware: Introduce request_firmware_direct()"
      Reported-by: default avatarNicolas <nbroeking@me.com>
      Reported-by: default avatarJohn Ewalt  <jewalt@lgsinnovations.com>
      Reported-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1b5c0b2
    • Luis R. Rodriguez's avatar
      firmware: fix batched requests - wake all waiters · c2c32ed5
      Luis R. Rodriguez authored
      commit e44565f6 upstream.
      
      The firmware cache mechanism serves two purposes, the secondary purpose is
      not well documented nor understood. This fixes a regression with the
      secondary purpose of the firmware cache mechanism: batched requests on
      successful lookups. Without this fix *any* time a batched request is
      triggered, secondary requests for which the batched request mechanism
      was designed for will seem to last forver and seem to never return.
      This issue is present for all kernel builds possible, and a hard reset
      is required.
      
      The firmware cache is used for:
      
      1) Addressing races with file lookups during the suspend/resume cycle
         by keeping firmware in memory during the suspend/resume cycle
      
      2) Batched requests for the same file rely only on work from the first file
         lookup, which keeps the firmware in memory until the last
         release_firmware() is called
      
      Batched requests *only* take effect if secondary requests come in prior to
      the first user calling release_firmware(). The devres name used for the
      internal firmware cache is used as a hint other pending requests are
      ongoing, the firmware buffer data is kept in memory until the last user of
      the buffer calls release_firmware(), therefore serializing requests and
      delaying the release until all requests are done.
      
      Batched requests wait for a wakup or signal so we can rely on the first file
      fetch to write to the pending secondary requests. Commit 5b029624
      ("firmware: do not use fw_lock for fw_state protection") ported the firmware
      API to use swait, and in doing so failed to convert complete_all() to
      swake_up_all() -- it used swake_up(), loosing the ability for *some* batched
      requests to take effect.
      
      We *could* fix this by just using swake_up_all() *but* swait is now known
      to be very special use case, so its best to just move away from it. So we
      just go back to using completions as before commit 5b029624 ("firmware:
      do not use fw_lock for fw_state protection") given this was using
      complete_all().
      
      Without this fix it has been reported plugging in two Intel 6260 Wifi cards
      on a system will end up enumerating the two devices only 50% of the time
      [0]. The ported swake_up() should have actually handled the case with two
      devices, however, *if more than two cards are used* the swake_up() would
      not have sufficed. This change is only part of the required fixes for
      batched requests. Another fix is provided in the next patch.
      
      This particular change should fix the cases where more than three requests
      with the same firmware name is used, otherwise batched requests will wait
      for MAX_SCHEDULE_TIMEOUT and just timeout eventually.
      
      Below is a summary of tests triggering batched requests on different
      kernel builds.
      
      Before this patch:
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Most common Linux distribution setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     FAIL                FAIL
      request_firmware_direct()              FAIL                FAIL
      request_firmware_nowait(uevent=true)   FAIL                FAIL
      request_firmware_nowait(uevent=false)  FAIL                FAIL
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=n
      
      Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     FAIL                FAIL
      request_firmware_direct()              FAIL                FAIL
      request_firmware_nowait(uevent=true)   FAIL                FAIL
      request_firmware_nowait(uevent=false)  FAIL                FAIL
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Google Android setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     FAIL                FAIL
      request_firmware_direct()              FAIL                FAIL
      request_firmware_nowait(uevent=true)   FAIL                FAIL
      request_firmware_nowait(uevent=false)  FAIL                FAIL
      ============================================================================
      
      After this patch:
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Most common Linux distribution setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     FAIL                OK
      request_firmware_direct()              FAIL                OK
      request_firmware_nowait(uevent=true)   FAIL                OK
      request_firmware_nowait(uevent=false)  FAIL                OK
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
      CONFIG_FW_LOADER_USER_HELPER=n
      
      Only possible if CONFIG_DELL_RBU=n and CONFIG_LEDS_LP55XX_COMMON=n, rare.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     FAIL                OK
      request_firmware_direct()              FAIL                OK
      request_firmware_nowait(uevent=true)   FAIL                OK
      request_firmware_nowait(uevent=false)  FAIL                OK
      ============================================================================
      CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
      CONFIG_FW_LOADER_USER_HELPER=y
      
      Google Android setup.
      
      API-type                               no-firmware-found   firmware-found
      ----------------------------------------------------------------------
      request_firmware()                     OK                  OK
      request_firmware_direct()              FAIL                OK
      request_firmware_nowait(uevent=true)   OK                  OK
      request_firmware_nowait(uevent=false)  OK                  OK
      ============================================================================
      
      [0] https://bugzilla.kernel.org/show_bug.cgi?id=195477
      
      Cc: Ming Lei <ming.lei@redhat.com>
      Fixes: 5b029624 ("firmware: do not use fw_lock for fw_state protection")
      Reported-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2c32ed5
    • Alan Swanson's avatar
      uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069 · f0834df3
      Alan Swanson authored
      commit 89f23d51 upstream.
      
      Similar to commit d595259f ("usb-storage: Add ignore-residue quirk for
      Initio INIC-3619") for INIC-3169 in unusual_devs.h but INIC-3069 already
      present in unusual_uas.h. Both in same controller IC family.
      
      Issue is that MakeMKV fails during key exchange with installed bluray drive
      with following error:
      
      002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED'
      occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'
      Signed-off-by: default avatarAlan Swanson <reiver@improbability.net>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0834df3
    • Ian Abbott's avatar
      staging: comedi: comedi_fops: do not call blocking ops when !TASK_RUNNING · c208cb9a
      Ian Abbott authored
      commit cef98864 upstream.
      
      Comedi's read and write file operation handlers (`comedi_read()` and
      `comedi_write()`) currently call `copy_to_user()` or `copy_from_user()`
      whilst in the `TASK_INTERRUPTIBLE` state, which falls foul of the
      `might_fault()` checks when enabled.  Fix it by setting the current task
      state back to `TASK_RUNNING` a bit earlier before calling these
      functions.
      Reported-by: default avatarPiotr Gregor <piotrgregor@rsyncme.org>
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c208cb9a
    • Hans de Goede's avatar
      iio: adc: Revert "axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications" · 20035abc
      Hans de Goede authored
      commit 631b010a upstream.
      
      Inheriting the ADC BIAS current settings from the BIOS instead of
      hardcoding then causes the AXP288 to disable charging (I think it
      mis-detects an overheated battery) on at least one model tablet.
      
      So lets go back to hard coding the values, this reverts
      commit fa2849e9 ("iio: adc: axp288: Drop bogus
      AXP288_ADC_TS_PIN_CTRL register modifications"), fixing charging not
      working on the model tablet in question.
      
      The exact cause is not fully understood, hence the revert to a known working
      state.
      Reported-by: default avatarUmberto Ixxo <sfumato1977@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20035abc
    • Akinobu Mita's avatar
      iio: light: tsl2563: use correct event code · c1164cc2
      Akinobu Mita authored
      commit a3507e48 upstream.
      
      The TSL2563 driver provides three iio channels, two of which are raw ADC
      channels (channel 0 and channel 1) in the device and the remaining one
      is calculated by the two.  The ADC channel 0 only supports programmable
      interrupt with threshold settings and this driver supports the event but
      the generated event code does not contain the corresponding iio channel
      type.
      
      This is going to change userspace ABI.  Hopefully fixing this to be
      what it should always have been won't break any userspace code.
      
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1164cc2
    • Lorenzo Bianconi's avatar
      iio: pressure: st_pressure_core: disable multiread by default for LPS22HB · 39e07a5c
      Lorenzo Bianconi authored
      commit add6e6ab upstream.
      
      Set multiread variable to false for LPS22HB pressure sensor since
      it is already enabled in CTRL_REG2. Previous configuration does not
      cause any issue in I2C communication since SUB Msb has no meaning
      whereas it breaks register address in SPI communication
      
      Fixes: e039e2f5 (iio:st_pressure:initial lps22hb sensor support)
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@st.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39e07a5c
    • Hans de Goede's avatar
      iio: accel: bmc150: Always restore device to normal mode after suspend-resume · 8886738d
      Hans de Goede authored
      commit e59e1898 upstream.
      
      After probe we would put the device in normal mode, after a runtime
      suspend-resume we would put it back in normal mode. But for a regular
      suspend-resume we would only put it back in normal mode if triggers
      or events have been requested.  This is not consistent and breaks
      reading raw values after a suspend-resume.
      
      This commit changes the regular resume path to also unconditionally put
      the device back in normal mode, fixing reading of raw values not working
      after a regular suspend-resume cycle.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8886738d
    • Lorenzo Bianconi's avatar
      iio: accel: st_accel: add SPI-3wire support · 3fdd0854
      Lorenzo Bianconi authored
      commit a7b8829d upstream.
      
      Add SPI Serial Interface Mode (SIM) register information
      in st_sensor_settings look up table to support devices
      (like LSM303AGR accel sensor) that allow just SPI-3wire
      communication mode. SIM mode has to be configured before any
      other operation since it is not enabled by default and the driver
      is not able to read without that configuration
      
      Whilst a fairly substantial patch, the actual logic is simple and it
      is better to have the generic fix than a band aid.
      
      Fixes: ddc05fa2 (iio: st-accel: add support for lsm303agr accel)
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@st.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fdd0854
    • Mykola Kostenok's avatar
      iio: aspeed-adc: wait for initial sequence. · 5f26ebe1
      Mykola Kostenok authored
      commit 737cc2a5 upstream.
      
      This patch enables adc engine at initialization time and waits
      for the initial sequence completion before enabling adc channels.
      
      Without this code adc channels are not functional and shows
      zeros for all connected channels.
      
      Tested on mellanox msn platform.
      
      v1 -> v2:
      Pointed by Rick Altherr:
       - Wait init sequence code enabled by bool
      from OF match table.
      Signed-off-by: default avatarMykola Kostenok <c_mykolak@mellanox.com>
      Reviewed-by: default avatarRick Altherr <raltherr@google.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f26ebe1
    • Arnd Bergmann's avatar
      staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read · f0ab97d1
      Arnd Bergmann authored
      commit 105967ad upstream.
      
      gcc-7 points out an older regression:
      
      drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw':
      drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]
      
      The original code had 'unsigned short' here, but incorrectly got
      converted to 'bool'. This reverts the regression and uses a normal
      type instead.
      
      Fixes: 29148543 ("staging:iio:resolver:ad2s1210 minimal chan spec conversion.")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0ab97d1
    • Rafael J. Wysocki's avatar
      USB: hcd: Mark secondary HCD as dead if the primary one died · 9ccd63a6
      Rafael J. Wysocki authored
      commit cd5a6a4f upstream.
      
      Make usb_hc_died() clear the HCD_FLAG_RH_RUNNING flag for the shared
      HCD and set HCD_FLAG_DEAD for it, in analogy with what is done for
      the primary one.
      
      Among other thigs, this prevents check_root_hub_suspended() from
      returning -EBUSY for dead HCDs which helps to work around system
      suspend issues in some situations.
      
      This actually fixes occasional suspend failures on one of my test
      machines.
      Suggested-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ccd63a6
    • Bin Liu's avatar
      usb: musb: fix tx fifo flush handling again · 792c00cb
      Bin Liu authored
      commit 45d73860 upstream.
      
      commit 68fe05e2 ("usb: musb: fix tx fifo flush handling") drops the
      1ms delay trying to solve the long disconnect time issue when
      application queued many tx urbs. However, the 1ms delay is needed for
      some use cases, for example, without the delay, reconnecting AR9271 WIFI
      dongle no longer works if the connection is dropped from the AP.
      
      So let's add back the 1ms delay in musb_h_tx_flush_fifo(), and solve the
      long disconnect time problem with a separate patch for
      usb_hcd_flush_endpoint().
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      792c00cb
    • Greg Kroah-Hartman's avatar
      USB: serial: pl2303: add new ATEN device id · ab51515e
      Greg Kroah-Hartman authored
      commit 3b6bcd3d upstream.
      
      This adds a new ATEN device id for a new pl2303-based device.
      Reported-by: default avatarPeter Kuo <PeterKuo@aten.com.tw>
      Cc: Johan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab51515e
    • Stefan Triller's avatar
      USB: serial: cp210x: add support for Qivicon USB ZigBee dongle · 492eb612
      Stefan Triller authored
      commit 9585e340 upstream.
      
      The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
      for their SmartHome Home Base in its 1. Generation. The productId is not
      known by the according kernel module, this patch adds support for it.
      Signed-off-by: default avatarStefan Triller <github@stefantriller.de>
      Reviewed-by: default avatarFrans Klaver <fransklaver@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      492eb612
    • Hector Martin's avatar
      USB: serial: option: add D-Link DWM-222 device ID · b576de1e
      Hector Martin authored
      commit fd1b8668 upstream.
      
      Add device id for D-Link DWM-222.
      Signed-off-by: default avatarHector Martin <marcan@marcan.st>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b576de1e
    • Maarten Lankhorst's avatar
      drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut · 59f1322c
      Maarten Lankhorst authored
      commit 5279fc77 upstream.
      
      bdw_load_gamma_lut is writing beyond the array to the maximum value.
      The intend of the function is to clamp values > 1 to 1, so write
      the intended color to the max register.
      
      This fixes the following KASAN warning:
      
      [  197.020857] [IGT] kms_pipe_color: executing
      [  197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0
      [  197.078989] ==================================================================
      [  197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
      [  197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839
      [  197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G     U 4.13.0-rc1-patser+ #5211
      [  197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
      [  197.079220] Call Trace:
      [  197.079230]  dump_stack+0x68/0x9e
      [  197.079239]  print_address_description+0x6f/0x250
      [  197.079251]  kasan_report+0x216/0x370
      [  197.079374]  ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
      [  197.079451]  ? gen8_write16+0x4e0/0x4e0 [i915]
      [  197.079460]  __asan_report_load2_noabort+0x14/0x20
      [  197.079535]  bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
      [  197.079612]  broadwell_load_luts+0x1df/0x550 [i915]
      [  197.079690]  intel_color_load_luts+0x7b/0x80 [i915]
      [  197.079764]  intel_begin_crtc_commit+0x138/0x760 [i915]
      [  197.079783]  drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper]
      [  197.079859]  ? intel_pre_plane_update+0x571/0x580 [i915]
      [  197.079937]  intel_update_crtc+0x238/0x330 [i915]
      [  197.080016]  intel_update_crtcs+0x10f/0x210 [i915]
      [  197.080092]  intel_atomic_commit_tail+0x1552/0x3340 [i915]
      [  197.080101]  ? _raw_spin_unlock+0x3c/0x40
      [  197.080110]  ? __queue_work+0xb40/0xbf0
      [  197.080188]  ? skl_update_crtcs+0xc00/0xc00 [i915]
      [  197.080195]  ? trace_hardirqs_on+0xd/0x10
      [  197.080269]  ? intel_atomic_commit_ready+0x128/0x13c [i915]
      [  197.080329]  ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915]
      [  197.080336]  ? debug_object_activate+0x39e/0x580
      [  197.080397]  ? i915_sw_fence_await+0x30/0x30 [i915]
      [  197.080409]  ? __might_sleep+0x15b/0x180
      [  197.080483]  intel_atomic_commit+0x944/0xa70 [i915]
      [  197.080490]  ? refcount_dec_and_test+0x11/0x20
      [  197.080567]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
      [  197.080597]  ? drm_atomic_crtc_set_property+0x303/0x580 [drm]
      [  197.080674]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
      [  197.080704]  drm_atomic_commit+0xd7/0xe0 [drm]
      [  197.080722]  drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper]
      [  197.080749]  drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm]
      [  197.080775]  drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm]
      [  197.080783]  ? __might_fault+0x104/0x180
      [  197.080809]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
      [  197.080838]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
      [  197.080861]  drm_ioctl_kernel+0x154/0x1a0 [drm]
      [  197.080885]  drm_ioctl+0x624/0x8f0 [drm]
      [  197.080910]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
      [  197.080934]  ? drm_getunique+0x210/0x210 [drm]
      [  197.080943]  ? __handle_mm_fault+0x1bd0/0x1ce0
      [  197.080949]  ? lock_downgrade+0x610/0x610
      [  197.080957]  ? __lru_cache_add+0x15a/0x180
      [  197.080967]  do_vfs_ioctl+0xd92/0xe40
      [  197.080975]  ? ioctl_preallocate+0x1b0/0x1b0
      [  197.080982]  ? selinux_capable+0x20/0x20
      [  197.080991]  ? __do_page_fault+0x7b7/0x9a0
      [  197.080997]  ? lock_downgrade+0x5bb/0x610
      [  197.081007]  ? security_file_ioctl+0x57/0x90
      [  197.081016]  SyS_ioctl+0x4e/0x80
      [  197.081024]  entry_SYSCALL_64_fastpath+0x18/0xad
      [  197.081030] RIP: 0033:0x7f61f287a987
      [  197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [  197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987
      [  197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003
      [  197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000
      [  197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58
      [  197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: default avatarMartin Peres <martin.peres@linux.intel.com>
      Cc: Martin Peres <martin.peres@linux.intel.com>
      Fixes: 82cf435b ("drm/i915: Implement color management on bdw/skl/bxt/kbl")
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Kiran S Kumar <kiran.s.kumar@intel.com>
      Cc: Kausal Malladi <kausalmalladi@gmail.com>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20170724091431.24251-1-maarten.lankhorst@linux.intel.comReviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      (cherry picked from commit 09a92bc8)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59f1322c
    • Wladimir J. van der Laan's avatar
      drm/etnaviv: Fix off-by-one error in reloc checking · 4eedc8a7
      Wladimir J. van der Laan authored
      commit d6f756e0 upstream.
      
      A relocation pointing to the last four bytes of a buffer can
      legitimately happen in the case of small vertex buffers.
      Signed-off-by: default avatarWladimir J. van der Laan <laanwj@gmail.com>
      Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Reviewed-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4eedc8a7
    • Lucas Stach's avatar
      drm/bridge: tc358767: fix probe without attached output node · 8f0f15cc
      Lucas Stach authored
      commit d630213f upstream.
      
      The output node of the TC358767 is only used if another bridge is chained
      behind it. Panels attached to the TC358767 can be detected using the usual
      DP AUX probing. This restores the old behavior of ignoring the output if
      no endpoint is found.
      
      Fixes: ebc94461 (drm: convert drivers to use drm_of_find_panel_or_bridge)
      Acked-by: default avatarAndrey Gusakov <andrey.gusakov@cogentembedded.com>
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170710124125.9019-1-l.stach@pengutronix.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f0f15cc
    • Weston Andros Adamson's avatar
      nfs/flexfiles: fix leak of nfs4_ff_ds_version arrays · 1cc5cd5b
      Weston Andros Adamson authored
      commit 1feb2616 upstream.
      
      The client was freeing the nfs4_ff_layout_ds, but not the contained
      nfs4_ff_ds_version array.
      Signed-off-by: default avatarWeston Andros Adamson <dros@primarydata.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cc5cd5b
    • Haibo Chen's avatar
      mmc: mmc: correct the logic for setting HS400ES signal voltage · 8d189f60
      Haibo Chen authored
      commit 92ddd959 upstream.
      
      Change the default err value to -EINVAL, make sure the card only
      has type EXT_CSD_CARD_TYPE_HS400_1_8V also do the signal voltage
      setting when select hs400es mode.
      
      Fixes: commit 1720d354 ("mmc: core: switch to 1V8 or 1V2 for hs400es mode")
      Signed-off-by: default avatarHaibo Chen <haibo.chen@nxp.com>
      Reviewed-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d189f60
    • Miquel Raynal's avatar
      nand: fix wrong default oob layout for small pages using soft ecc · 3329fe0e
      Miquel Raynal authored
      commit f7f8c175 upstream.
      
      When using soft ecc, if no ooblayout is given, the core automatically
      uses one of the nand_ooblayout_{sp,lp}*() functions to determine the
      layout inside the out of band data.
      
      Until kernel version 4.6, struct nand_ecclayout was used for that
      purpose. During the migration from 4.6 to 4.7, an error shown up in the
      small page layout, in the case oob section is only 8 bytes long.
      
      The layout was using three bytes (0, 1, 2) for ecc, two bytes (3, 4)
      as free bytes, one byte (5) for bad block marker and finally
      two bytes (6, 7) as free bytes, as shown there:
      
      [linux-4.6] drivers/mtd/nand/nand_base.c:52
      static struct nand_ecclayout nand_oob_8 = {
      	.eccbytes = 3,
      	.eccpos = {0, 1, 2},
      	.oobfree = {
      		{.offset = 3,
      		 .length = 2},
      		{.offset = 6,
      		 .length = 2} }
      };
      
      This fixes the current implementation which is incoherent. It
      references bit 3 at the same time as an ecc byte and a free byte.
      
      Furthermore, it is clear with the previous implementation that there
      is only one ecc section with 8 bytes oob sections. We shall return
      -ERANGE in the nand_ooblayout_ecc_sp() function when asked for the
      second section.
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@free-electrons.com>
      Fixes: 41b207a7 ("mtd: nand: implement the default mtd_ooblayout_ops")
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3329fe0e
    • Hans de Goede's avatar
      i2c: designware: Some broken DSTDs use 1MiHz instead of 1MHz · 1f2f0f1a
      Hans de Goede authored
      commit 682c6c21 upstream.
      
      At least the Acer Iconia Tab8 / aka W1-810 uses 1MiHz instead of
      1MHz for one of its busses, fix this up to 1MHz instead of failing
      the probe of that bus.
      
      This fixes the accelerometer on the Acer Iconia Tab8 not working.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f2f0f1a
    • Mateusz Jurczyk's avatar
      fuse: initialize the flock flag in fuse_file on allocation · cfea0422
      Mateusz Jurczyk authored
      commit 68227c03 upstream.
      
      Before the patch, the flock flag could remain uninitialized for the
      lifespan of the fuse_file allocation. Unless set to true in
      fuse_file_flock(), it would remain in an indeterminate state until read in
      an if statement in fuse_release_common(). This could consequently lead to
      taking an unexpected branch in the code.
      
      The bug was discovered by a runtime instrumentation designed to detect use
      of uninitialized memory in the kernel.
      Signed-off-by: default avatarMateusz Jurczyk <mjurczyk@google.com>
      Fixes: 37fb3a30 ("fuse: fix flock")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfea0422
    • Nicholas Bellinger's avatar
      target: Fix node_acl demo-mode + uncached dynamic shutdown regression · 59c74236
      Nicholas Bellinger authored
      commit 6f48655f upstream.
      
      This patch fixes a generate_node_acls = 1 + cache_dynamic_acls = 0
      regression, that was introduced by
      
        commit 01d4d673
        Author: Nicholas Bellinger <nab@linux-iscsi.org>
        Date:   Wed Dec 7 12:55:54 2016 -0800
      
      which originally had the proper list_del_init() usage, but was
      dropped during list review as it was thought unnecessary by HCH.
      
      However, list_del_init() usage is required during the special
      generate_node_acls = 1 + cache_dynamic_acls = 0 case when
      transport_free_session() does a list_del(&se_nacl->acl_list),
      followed by target_complete_nacl() doing the same thing.
      
      This was manifesting as a general protection fault as reported
      by Justin:
      
      kernel: general protection fault: 0000 [#1] SMP
      kernel: Modules linked in:
      kernel: CPU: 0 PID: 11047 Comm: iscsi_ttx Not tainted 4.13.0-rc2.x86_64.1+ #20
      kernel: Hardware name: Intel Corporation S5500BC/S5500BC, BIOS S5500.86B.01.00.0064.050520141428 05/05/2014
      kernel: task: ffff88026939e800 task.stack: ffffc90007884000
      kernel: RIP: 0010:target_put_nacl+0x49/0xb0
      kernel: RSP: 0018:ffffc90007887d70 EFLAGS: 00010246
      kernel: RAX: dead000000000200 RBX: ffff8802556ca000 RCX: 0000000000000000
      kernel: RDX: dead000000000100 RSI: 0000000000000246 RDI: ffff8802556ce028
      kernel: RBP: ffffc90007887d88 R08: 0000000000000001 R09: 0000000000000000
      kernel: R10: ffffc90007887df8 R11: ffffea0009986900 R12: ffff8802556ce020
      kernel: R13: ffff8802556ce028 R14: ffff8802556ce028 R15: ffffffff88d85540
      kernel: FS:  0000000000000000(0000) GS:ffff88027fc00000(0000) knlGS:0000000000000000
      kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      kernel: CR2: 00007fffe36f5f94 CR3: 0000000009209000 CR4: 00000000003406f0
      kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      kernel: Call Trace:
      kernel:  transport_free_session+0x67/0x140
      kernel:  transport_deregister_session+0x7a/0xc0
      kernel:  iscsit_close_session+0x92/0x210
      kernel:  iscsit_close_connection+0x5f9/0x840
      kernel:  iscsit_take_action_for_connection_exit+0xfe/0x110
      kernel:  iscsi_target_tx_thread+0x140/0x1e0
      kernel:  ? wait_woken+0x90/0x90
      kernel:  kthread+0x124/0x160
      kernel:  ? iscsit_thread_get_cpumask+0x90/0x90
      kernel:  ? kthread_create_on_node+0x40/0x40
      kernel:  ret_from_fork+0x22/0x30
      kernel: Code: 00 48 89 fb 4c 8b a7 48 01 00 00 74 68 4d 8d 6c 24 08 4c
      89 ef e8 e8 28 43 00 48 8b 93 20 04 00 00 48 8b 83 28 04 00 00 4c 89
      ef <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 20
      kernel: RIP: target_put_nacl+0x49/0xb0 RSP: ffffc90007887d70
      kernel: ---[ end trace f12821adbfd46fed ]---
      
      To address this, go ahead and use proper list_del_list() for all
      cases of se_nacl->acl_list deletion.
      Reported-by: default avatarJustin Maggard <jmaggard01@gmail.com>
      Tested-by: default avatarJustin Maggard <jmaggard01@gmail.com>
      Cc: Justin Maggard <jmaggard01@gmail.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59c74236
    • Alan Stern's avatar
      usb-storage: fix deadlock involving host lock and scsi_done · 7b0d44e2
      Alan Stern authored
      commit 8b52291a upstream.
      
      Christoph Hellwig says that since version 4.12, the kernel switched to
      using blk-mq by default.  The old code used a softirq for handling
      request completions, but blk-mq can handle completions in the caller's
      context.  This may cause a problem for usb-storage, because it invokes
      the ->scsi_done callback while holding the host lock, and the
      completion routine sometimes tries to acquire the same lock (when
      running the error handler, for example).
      
      The consequence is that the existing code will sometimes deadlock upon
      error completion of a SCSI command (with a lockdep warning).
      
      This is easy enough to fix, since usb-storage doesn't really need to
      hold the host lock while the callback runs.  It was simpler to write
      it that way, but moving the call outside the locked region is pretty
      easy and there's no downside.  That's what this patch does.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarArthur Marsh <arthur.marsh@internode.on.net>
      CC: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b0d44e2
    • Nicholas Bellinger's avatar
      iscsi-target: Fix iscsi_np reset hung task during parallel delete · 42804812
      Nicholas Bellinger authored
      commit 978d13d6 upstream.
      
      This patch fixes a bug associated with iscsit_reset_np_thread()
      that can occur during parallel configfs rmdir of a single iscsi_np
      used across multiple iscsi-target instances, that would result in
      hung task(s) similar to below where configfs rmdir process context
      was blocked indefinately waiting for iscsi_np->np_restart_comp
      to finish:
      
      [ 6726.112076] INFO: task dcp_proxy_node_:15550 blocked for more than 120 seconds.
      [ 6726.119440]       Tainted: G        W  O     4.1.26-3321 #2
      [ 6726.125045] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 6726.132927] dcp_proxy_node_ D ffff8803f202bc88     0 15550      1 0x00000000
      [ 6726.140058]  ffff8803f202bc88 ffff88085c64d960 ffff88083b3b1ad0 ffff88087fffeb08
      [ 6726.147593]  ffff8803f202c000 7fffffffffffffff ffff88083f459c28 ffff88083b3b1ad0
      [ 6726.155132]  ffff88035373c100 ffff8803f202bca8 ffffffff8168ced2 ffff8803f202bcb8
      [ 6726.162667] Call Trace:
      [ 6726.165150]  [<ffffffff8168ced2>] schedule+0x32/0x80
      [ 6726.170156]  [<ffffffff8168f5b4>] schedule_timeout+0x214/0x290
      [ 6726.176030]  [<ffffffff810caef2>] ? __send_signal+0x52/0x4a0
      [ 6726.181728]  [<ffffffff8168d7d6>] wait_for_completion+0x96/0x100
      [ 6726.187774]  [<ffffffff810e7c80>] ? wake_up_state+0x10/0x10
      [ 6726.193395]  [<ffffffffa035d6e2>] iscsit_reset_np_thread+0x62/0xe0 [iscsi_target_mod]
      [ 6726.201278]  [<ffffffffa0355d86>] iscsit_tpg_disable_portal_group+0x96/0x190 [iscsi_target_mod]
      [ 6726.210033]  [<ffffffffa0363f7f>] lio_target_tpg_store_enable+0x4f/0xc0 [iscsi_target_mod]
      [ 6726.218351]  [<ffffffff81260c5a>] configfs_write_file+0xaa/0x110
      [ 6726.224392]  [<ffffffff811ea364>] vfs_write+0xa4/0x1b0
      [ 6726.229576]  [<ffffffff811eb111>] SyS_write+0x41/0xb0
      [ 6726.234659]  [<ffffffff8169042e>] system_call_fastpath+0x12/0x71
      
      It would happen because each iscsit_reset_np_thread() sets state
      to ISCSI_NP_THREAD_RESET, sends SIGINT, and then blocks waiting
      for completion on iscsi_np->np_restart_comp.
      
      However, if iscsi_np was active processing a login request and
      more than a single iscsit_reset_np_thread() caller to the same
      iscsi_np was blocked on iscsi_np->np_restart_comp, iscsi_np
      kthread process context in __iscsi_target_login_thread() would
      flush pending signals and only perform a single completion of
      np->np_restart_comp before going back to sleep within transport
      specific iscsit_transport->iscsi_accept_np code.
      
      To address this bug, add a iscsi_np->np_reset_count and update
      __iscsi_target_login_thread() to keep completing np->np_restart_comp
      until ->np_reset_count has reached zero.
      Reported-by: default avatarGary Guo <ghg@datera.io>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42804812
    • Varun Prakash's avatar
      iscsi-target: fix memory leak in iscsit_setup_text_cmd() · f838bd17
      Varun Prakash authored
      commit ea8dc5b4 upstream.
      
      On receiving text request iscsi-target allocates buffer for
      payload in iscsit_handle_text_cmd() and assigns buffer pointer
      to cmd->text_in_ptr, this buffer is currently freed in
      iscsit_release_cmd(), if iscsi-target sets 'C' bit in text
      response then it will receive another text request from the
      initiator with ttt != 0xffffffff in this case iscsi-target
      will find cmd using itt and call iscsit_setup_text_cmd()
      which will set cmd->text_in_ptr to NULL without freeing
      previously allocated buffer.
      
      This patch fixes this issue by calling kfree(cmd->text_in_ptr)
      in iscsit_setup_text_cmd() before assigning NULL to it.
      
      For the first text request cmd->text_in_ptr is NULL as
      cmd is memset to 0 in iscsit_allocate_cmd().
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f838bd17