Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 25 5月, 2013 4 次提交
    • S
      xhci: Disable D3cold for buggy TI redrivers. · c3897aa5
      由 Sarah Sharp 提交于 
      Some xHCI hosts contain a "redriver" from TI that silently drops port
status connect changes if the port slips into Compliance Mode.  If the
port slips into compliance mode while the host is in D0, there will not
be a port status change event.  If the port slips into compliance mode
while the host is in D3, the host will not send a PME.  This includes
when the system is suspended (S3) or hibernated (S4).

If this happens when the system is in S3/S4, there is nothing software
can do.  Other port status change events that would normally cause the
host to wake the system from S3/S4 may also be lost.  This includes
remote wakeup, disconnects and connects on other ports, and overrcurrent
events.  A decision was made to _NOT_ disable system suspend/hibernate
on these systems, since users are unlikely to enable wakeup from S3/S4
for the xHCI host.

Software can deal with this issue when the system is in S0.  A work
around was put in to poll the port status registers for Compliance Mode.
The xHCI driver will continue to poll the registers while the host is
runtime suspended.  Unfortunately, that means we can't allow the PCI
device to go into D3cold, because power will be removed from the host,
and the config space will read as all Fs.

Disable D3cold in the xHCI PCI runtime suspend function.

This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a2 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: stable@vger.kernel.org
      c3897aa5
    • T
      xhci - correct comp_mode_recovery_timer on return from hibernate · 77df9e0b
      由 Tony Camuso 提交于 
      Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.

The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.

Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.

At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.

The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty
list.

This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.

Thanks to Alan Stern for his help with understanding the problem.

[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false.  The original patch would have caused list corruption in this
case.]

This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a2 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: NTony Camuso <tcamuso@redhat.com>
Tested-by: NTony Camuso <tcamuso@redhat.com>
Acked-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      77df9e0b
    • V
      xhci: fix list access before init · 88696ae4
      由 Vladimir Murzin 提交于 
      If for whatever reason we fall into fail path in xhci_mem_init()
before bw table gets initialized we may access the uninitialized lists
in xhci_mem_cleanup().

Check for bw table before traversing lists in cleanup routine.

This patch should be backported to kernels as old as 3.2, that contain
the commit 839c817c "xhci: Store
information about roothubs and TTs."
Reported-by: NSergey Dyasly <dserrg@gmail.com>
Tested-by: NSergey Dyasly <dserrg@gmail.com>
Signed-off-by: NVladimir Murzin <murzin.v@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      88696ae4
    • S
      xhci-mem: init list heads at the beginning of init · 331de00a
      由 Sergio Aguirre 提交于 
      It is possible that we fail on xhci_mem_init, just before doing
the INIT_LIST_HEAD, and calling xhci_mem_cleanup.

Problem is that, the list_for_each_entry_safe macro, assumes
list heads are initialized (not NULL), and dereferences their 'next'
pointer, causing a kernel panic if this is not yet initialized.

Let's protect from that by moving inits to the beginning.

This patch should be backported to kernels as old as 3.2, that
contain the commit 9574323c "xHCI: test
USB2 software LPM".
Signed-off-by: NSergio Aguirre <sergio.a.aguirre.rodriguez@intel.com>
Acked-by: NDavid Cohen <david.a.cohen@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      331de00a
  3. 21 5月, 2013 1 次提交
  5. 18 5月, 2013 1 次提交
  7. 17 5月, 2013 18 次提交
  9. 16 5月, 2013 7 次提交
    • A
      USB: remove remaining instances of USB_SUSPEND · 98f541c6
      由 Alan Stern 提交于 
      Commit 84ebc102 (USB: remove
CONFIG_USB_SUSPEND option) failed to remove all of the usages of
USB_SUSPEND throughout the kernel.  This patch (as1677) removes the
remaining instances of that symbol.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98f541c6
    • A
      USB: OHCI: fix logic for scheduling isochronous URBs · 815fa7b9
      由 Alan Stern 提交于 
      The isochronous scheduling logic in ohci-hcd has a bug.  The
calculation for skipping TDs that are too late should be carried out
only in the !URB_ISO_ASAP case.  When URB_ISO_ASAP is set, the URB is
pushed back so that none of the TDs are too late, which would cause
the calculation to overflow.

The patch also fixes the calculation to avoid overflow in the case
where the frame value wraps around.

This should be applied to -stable kernels going back to 3.8.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      815fa7b9
    • A
      USB: fix latency in uhci-hcd and ohci-hcd · e1944017
      由 Alan Stern 提交于 
      Commits c44b2250 (UHCI: implement new
semantics for URB_ISO_ASAP) and
6a41b4d3 (OHCI: implement new
semantics for URB_ISO_ASAP) increased the latency for isochronous URBs
in uhci-hcd and ohci-hcd respectively to 2 milliseconds, in an
attempt to avoid underruns.  It turns out that not only was this
unnecessary -- 1-ms latency works okay -- it also causes problems with
certain application loads such as real-time audio.

This patch changes the latency for both drivers back to 1 ms.

This should be applied to -stable kernels going back to 3.8.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: NJoe Rayhawk <jrayhawk@fairlystable.org>
CC: Clemens Ladisch <clemens@ladisch.de>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1944017
    • A
      USB: UHCI: fix for suspend of virtual HP controller · 997ff893
      由 Alan Stern 提交于 
      HP's virtual UHCI host controller takes a long time to suspend
(several hundred microseconds), even when no devices are attached.
This provokes a warning message from uhci-hcd in the auto-stop case.

To prevent this from happening, this patch adds a test to avoid
performing an auto-stop when the wait_for_hp quirk flag is set.  The
controller will still suspend through the normal runtime PM mechanism.
And since that pathway includes a 1-ms delay, the slowness of the
virtual hardware won't matter.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: NZhenHua <zhen-hual@hp.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      997ff893
    • A
      USB: fix Kconfig logic for USB_UHCI_HCD · ccd9509a
      由 Alan Stern 提交于 
      The Kconfig settings for uhci-hcd are too permissive; they allow the
driver to be built without any bus-glue modules configured
(USB_UHCI_HCD enabled, PCI disabled, SPARC_LEON disabled, ARCH_VT8500
enabled, and USB_UHCI_PLATFORM disabled).

This patch fixes the problem by rearranging the dependencies.  Now the
platform-dependent config options don't depend on USB_UHCI_HCD;
instead it depends on them.  Furthermore, there is no user-selectable
choice as to which glue modules will be built.  If USB_UHCI_HCD is
enabled then all applicable bus glues will be built.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ccd9509a
    • A
      USB: xHCI: override bogus bulk wMaxPacketSize values · e4f47e36
      由 Alan Stern 提交于 
      This patch shortens the logic in xhci_endpoint_init() by moving common
calculations involving max_packet and max_burst outside the switch
statement, rather than repeating the same code in multiple
case-specific statements.  It also replaces two usages of max_packet
which were clearly intended to be max_burst all along.

More importantly, it compensates for a common bug in high-speed bulk
endpoint descriptors.  In many devices there is a bulk endpoint having
a wMaxPacketSize value smaller than 512, which is forbidden by the USB
spec.  Some xHCI controllers can't handle this and refuse to accept
the endpoint.  This patch changes the max_packet value to 512, which
allows the controller to use the endpoint properly.

In practice the bogus maxpacket size doesn't matter, because none of
the transfers sent via these endpoints are longer than the maxpacket
value anyway.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: N"Aurélien Leblond" <blablack@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4f47e36
    • G
      Merge tag 'fixes-for-v3.10-rc2' of... · 4089ffd7
      由 Greg Kroah-Hartman 提交于 
      Merge tag 'fixes-for-v3.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus

Felipe writes:

usb: fixes for v3.10-rc2

Here's the initial set of fixes for v3.10-rc series. It countains miscellaneous
fixes in numerous drivers.

Many gadget drivers and PHY drivers learned that it's not necessary to
platform_set_drvdata() twice, that's not necessary to check the resource
pointer returned by platform_get_resource() when using devm_ioremap_resource()
and they learned that we shouldn't return 0 in case of errors.

DWC3 got a build fix for cases where DWC3 is marked as 'y' while gadget API is
marked as 'm'.

There's also a NULL pointer exception fix on usb_get_phy(), mxs-phy now knows
which PHY type it is and s3c-hsotg is now passing proper arguments to
usb_gadget_unmap_request().

Other than that there are some spelling fixes and kernel-doc warnings.
Signed-of-by: NFelipe Balbi <balbi@ti.com>
      4089ffd7
  11. 15 5月, 2013 9 次提交