1. 17 1月, 2019 1 次提交
  2. 14 1月, 2019 4 次提交
    • D
      usb: gadget: Potential NULL dereference on allocation error · df28169e
      Dan Carpenter 提交于
      The source_sink_alloc_func() function is supposed to return error
      pointers on error.  The function is called from usb_get_function() which
      doesn't check for NULL returns so it would result in an Oops.
      
      Of course, in the current kernel, small allocations always succeed so
      this doesn't affect runtime.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      df28169e
    • Z
      usb: dwc3: gadget: Fix the uninitialized link_state when udc starts · 88b1bb1f
      Zeng Tao 提交于
      Currently the link_state is uninitialized and the default value is 0(U0)
      before the first time we start the udc, and after we start the udc then
       stop the udc, the link_state will be undefined.
      We may have the following warnings if we start the udc again with
      an undefined link_state:
      
      WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308
      dwc3 100e0000.hidwc3_0: wakeup failed --> -22
      [...]
      Call Trace:
      [<c010f270>] (unwind_backtrace) from [<c010b3d8>] (show_stack+0x10/0x14)
      [<c010b3d8>] (show_stack) from [<c034a4dc>] (dump_stack+0x84/0x98)
      [<c034a4dc>] (dump_stack) from [<c0118000>] (__warn+0xe8/0x100)
      [<c0118000>] (__warn) from [<c0118050>](warn_slowpath_fmt+0x38/0x48)
      [<c0118050>] (warn_slowpath_fmt) from [<c0442ec0>](dwc3_send_gadget_ep_cmd+0x304/0x308)
      [<c0442ec0>] (dwc3_send_gadget_ep_cmd) from [<c0445e68>](dwc3_ep0_start_trans+0x48/0xf4)
      [<c0445e68>] (dwc3_ep0_start_trans) from [<c0446750>](dwc3_ep0_out_start+0x64/0x80)
      [<c0446750>] (dwc3_ep0_out_start) from [<c04451c0>](__dwc3_gadget_start+0x1e0/0x278)
      [<c04451c0>] (__dwc3_gadget_start) from [<c04452e0>](dwc3_gadget_start+0x88/0x10c)
      [<c04452e0>] (dwc3_gadget_start) from [<c045ee54>](udc_bind_to_driver+0x88/0xbc)
      [<c045ee54>] (udc_bind_to_driver) from [<c045f29c>](usb_gadget_probe_driver+0xf8/0x140)
      [<c045f29c>] (usb_gadget_probe_driver) from [<bf005424>](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite])
      [<bf005424>] (gadget_dev_desc_UDC_store [libcomposite]) from[<c023d8e0>] (configfs_write_file+0xd4/0x160)
      [<c023d8e0>] (configfs_write_file) from [<c01d51e8>] (__vfs_write+0x1c/0x114)
      [<c01d51e8>] (__vfs_write) from [<c01d5ff4>] (vfs_write+0xa4/0x168)
      [<c01d5ff4>] (vfs_write) from [<c01d6d40>] (SyS_write+0x3c/0x90)
      [<c01d6d40>] (SyS_write) from [<c0107400>] (ret_fast_syscall+0x0/0x3c)
      Signed-off-by: NZeng Tao <prime.zeng@hisilicon.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      88b1bb1f
    • J
      usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup · bd674224
      Jack Pham 提交于
      OUT endpoint requests may somtimes have this flag set when
      preparing to be submitted to HW indicating that there is an
      additional TRB chained to the request for alignment purposes.
      If that request is removed before the controller can execute the
      transfer (e.g. ep_dequeue/ep_disable), the request will not go
      through the dwc3_gadget_ep_cleanup_completed_request() handler
      and will not have its needs_extra_trb flag cleared when
      dwc3_gadget_giveback() is called.  This same request could be
      later requeued for a new transfer that does not require an
      extra TRB and if it is successfully completed, the cleanup
      and TRB reclamation will incorrectly process the additional TRB
      which belongs to the next request, and incorrectly advances the
      TRB dequeue pointer, thereby messing up calculation of the next
      requeust's actual/remaining count when it completes.
      
      The right thing to do here is to ensure that the flag is cleared
      before it is given back to the function driver.  A good place
      to do that is in dwc3_gadget_del_and_unmap_request().
      
      Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
      Cc: stable@vger.kernel.org
      Signed-off-by: NJack Pham <jackp@codeaurora.org>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      bd674224
    • B
      usb: dwc3: gadget: synchronize_irq dwc irq in suspend · 01c10880
      Bo He 提交于
      We see dwc3 endpoint stopped by unwanted irq during
      suspend resume test, which is caused dwc3 ep can't be started
      with error "No Resource".
      
      Here, add synchronize_irq before suspend to sync the
      pending IRQ handlers complete.
      Signed-off-by: NBo He <bo.he@intel.com>
      Signed-off-by: NYu Wang <yu.y.wang@intel.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      01c10880
  3. 13 1月, 2019 1 次提交
  4. 12 1月, 2019 6 次提交
    • M
      ata: ahci: mvebu: request PHY suspend/resume for Armada 3700 · bde0b5c1
      Miquel Raynal 提交于
      A feature has been added in the libahci driver: the possibility to set
      a new flag in hpriv->flags to let the core handle PHY suspend/resume
      automatically. Make use of this feature to make suspend to RAM work
      with SATA drives on A3700.
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      bde0b5c1
    • M
      ata: ahci: mvebu: add Armada 3700 initialization needed for S2RAM · 2f558bc3
      Miquel Raynal 提交于
      A3700 comphy initialization is done in the firmware (TF-A). Looking at
      the SATA PHY initialization routine, there is a comment about "vendor
      specific" registers. Two registers are mentioned. They are not
      initialized there in the firmware because they are AHCI related, while
      the firmware at this location does only PHY configuration. The
      solution to avoid doing such initialization is relying on U-Boot.
      
      While this work at boot time, U-Boot is definitely not going to run
      during a resume after suspending to RAM.
      
      Two possible solutions were considered:
      * Fixing the firmware.
      * Fixing the kernel driver.
      
      The first solution would take ages to propagate, while the second
      solution is easy to implement as the driver as been a little bit
      reworked to prepare for such platform configuration. Hence, this patch
      adds an Armada 3700 configuration function to set these two registers
      both at boot time (in the probe) and after a suspend (in the resume
      path).
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      2f558bc3
    • M
      ata: ahci: mvebu: do Armada 38x configuration only on relevant SoCs · 96dbcb40
      Miquel Raynal 提交于
      At the beginning, only Armada 38x SoCs where supported by the
      ahci_mvebu.c driver. Commit 15d3ce7b ("ata: ahci_mvebu: add
      support for Armada 3700 variant") introduced Armada 3700 support. As
      opposed to Armada 38x SoCs, the 3700 variants do not have to configure
      mbus and the regret option. This patch took care of avoiding such
      configuration when not needed in the probe function, but failed to do
      the same in the resume path. While doing so looks harmless by
      experience, let's clean the driver logic and avoid doing this useless
      configuration with Armada 3700 SoCs.
      
      Because the logic is very similar between these two places, it has
      been decided to factorize this code and put it in a "Armada 38x
      configuration function". This function is part of a new
      (per-compatible) platform data structure, so that the addition of such
      configuration function for Armada 3700 will be eased.
      
      Fixes: 15d3ce7b ("ata: ahci_mvebu: add support for Armada 3700 variant")
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      96dbcb40
    • M
      ata: ahci: mvebu: remove stale comment · c9bc1367
      Miquel Raynal 提交于
      For Armada-38x (32-bit) SoCs, PM platform support has been added since:
      commit 32f9494c ("ARM: mvebu: prepare pm-board.c for the
                            introduction of Armada 38x support")
      commit 3cbd6a6c ("ARM: mvebu: Add standby support")
      
      For Armada 64-bit SoCs, like the A3700 also using this AHCI driver, PM
      platform support has always existed.
      
      There are even suspend/resume hooks in this driver since:
      commit d6ecf158 ("ata: ahci_mvebu: add suspend/resume support")
      
      Remove the stale comment at the end of this driver stating that all
      the above does not exist yet.
      
      Fixes: d6ecf158 ("ata: ahci_mvebu: add suspend/resume support")
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      c9bc1367
    • M
      ata: libahci_platform: comply to PHY framework · 49e54187
      Miquel Raynal 提交于
      Current implementation of the libahci does not take into account the
      new PHY framework. Correct the situation by adding a call to
      phy_set_mode() before phy_power_on().
      
      PHYs should also be handled at suspend/resume time. For this, call
      ahci_platform_enable/disable_phys() at suspend/resume_host() time. These
      calls are guarded by a HFLAG (AHCI_HFLAG_SUSPEND_PHYS) that the user of
      the libahci driver must set manually in hpriv->flags at probe time. This
      is to avoid breaking users that have not been tested with this change.
      Reviewed-by: NHans de Goede <hdegoede@redhat.com>
      Suggested-by: NGrzegorz Jaszczyk <jaz@semihalf.com>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      49e54187
    • D
      tty: Don't hold ldisc lock in tty_reopen() if ldisc present · d3736d82
      Dmitry Safonov 提交于
      Try to get reference for ldisc during tty_reopen().
      If ldisc present, we don't need to do tty_ldisc_reinit() and lock the
      write side for line discipline semaphore.
      Effectively, it optimizes fast-path for tty_reopen(), but more
      importantly it won't interrupt ongoing IO on the tty as no ldisc change
      is needed.
      Fixes user-visible issue when tty_reopen() interrupted login process for
      user with a long password, observed and reported by Lukas.
      
      Fixes: c96cf923 ("tty: Don't block on IO when ldisc change is pending")
      Fixes: 83d817f4 ("tty: Hold tty_ldisc_lock() during tty_reopen()")
      Cc: Jiri Slaby <jslaby@suse.com>
      Reported-by: NLukas F. Hartmann <lukas@mntmn.com>
      Tested-by: NLukas F. Hartmann <lukas@mntmn.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3736d82
  5. 11 1月, 2019 7 次提交
  6. 10 1月, 2019 21 次提交