Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 24 9月, 2014 2 次提交
  3. 19 7月, 2014 1 次提交
  5. 28 5月, 2014 3 次提交
    • D
      usb: introduce port status lock · 5c79a1e3
      由 Dan Williams 提交于 
      In general we do not want khubd to act on port status changes that are
the result of in progress resets or USB runtime PM operations.
Specifically port power control testing has been able to trigger an
unintended disconnect in hub_port_connect_change(), paraphrasing:

	if ((portstatus & USB_PORT_STAT_CONNECTION) && udev &&
	    udev->state != USB_STATE_NOTATTACHED) {
		if (portstatus & USB_PORT_STAT_ENABLE) {
			/* Nothing to do */
		} else if (udev->state == USB_STATE_SUSPENDED &&
				udev->persist_enabled) {
			...
		} else {
			/* Don't resuscitate */;
		}
	}

...by falling to the "Don't resuscitate" path or missing
USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of
modifying the port status.

So, we want a new lock to hold off khubd for a given port while the
child device is being suspended, resumed, or reset.  The lock ordering
rules are now usb_lock_device() => usb_lock_port().  This is mandated by
the device core which may hold the device_lock on the usb_device before
invoking usb_port_{suspend|resume} which in turn take the status_lock on
the usb_port.  We attempt to hold the status_lock for the duration of a
port_event() run, and drop/re-acquire it when needing to take the
device_lock.  The lock is also dropped/re-acquired during
hub_port_reconnect().

This patch also deletes hub->busy_bits as all use cases are now covered
by port PM runtime synchronization or the port->status_lock and it
pushes down usb_device_lock() into usb_remote_wakeup().
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c79a1e3
    • D
      usb: assign default peer ports for root hubs · d8521afe
      由 Dan Williams 提交于 
      Assume that the peer of a superspeed port is the port with the same id
on the shared_hcd root hub.  This identification scheme is required of
external hubs by the USB3 spec [1].  However, for root hubs, tier mismatch
may be in effect [2].  Tier mismatch can only be enumerated via platform
firmware.  For now, simply perform the nominal association.

A new lock 'usb_port_peer_mutex' is introduced to synchronize port
device add/remove with peer lookups.  It protects peering against
changes to hcd->shared_hcd, hcd->self.root_hub, hdev->maxchild, and
port_dev->child pointers.

[1]: usb 3.1 section 10.3.3
[2]: xhci 1.1 appendix D

Cc: Alan Stern <stern@rowland.harvard.edu>
[alan: usb_port_peer_mutex locking scheme]
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8521afe
    • T
      USB: separate usb_address0 mutexes for each bus · 6fecd4f2
      由 Todd E Brandt 提交于 
      This patch creates a separate instance of the usb_address0 mutex for each USB
bus, and attaches it to the usb_bus device struct. This allows devices on
separate buses to be enumerated in parallel; saving time.

In the current code, there is a single, global instance of the usb_address0
mutex which is used for all devices on all buses. This isn't completely
necessary, as this mutex is only needed to prevent address0 collisions for
devices on the *same* bus (usb 2.0 spec, sec 4.6.1). This superfluous coverage
can cause additional delay in system resume on systems with multiple hosts
(up to several seconds depending on what devices are attached).
Signed-off-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fecd4f2
  7. 20 5月, 2014 1 次提交
  9. 05 3月, 2014 2 次提交
  11. 23 1月, 2014 1 次提交
    • S
      Revert "usbcore: set lpm_capable field for LPM capable root hubs" · 140e3026
      由 Sarah Sharp 提交于 
      Commit 9df89d85 "usbcore: set
lpm_capable field for LPM capable root hubs" was created under the
assumption that all USB host controllers should have USB 3.0 Link PM
enabled for all devices under the hosts.

Unfortunately, that's not the case.  The xHCI driver relies on knowledge
of the host hardware scheduler to calculate the LPM U1/U2 timeout
values, and it only sets lpm_capable to one for Intel host controllers
(that have the XHCI_LPM_SUPPORT quirk set).

When LPM is enabled for some Fresco Logic hosts, it causes failures with
a AgeStar 3UBT USB 3.0 hard drive dock:

Jan 11 13:59:03 sg-laptop kernel: usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd
Jan 11 13:59:03 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed.
Jan 11 13:59:08 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed.
Jan 11 13:59:08 sg-laptop kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jan 11 13:59:08 sg-laptop mtp-probe[613]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-1"
Jan 11 13:59:08 sg-laptop mtp-probe[613]: bus: 3, device: 2 was not an MTP device
Jan 11 13:59:08 sg-laptop kernel: scsi6 : usb-storage 3-1:1.0
Jan 11 13:59:13 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed.
Jan 11 13:59:18 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed.
Jan 11 13:59:18 sg-laptop kernel: usbcore: registered new interface driver usb-storage
Jan 11 13:59:40 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
Jan 11 13:59:41 sg-laptop kernel: usb 3-1: device descriptor read/8, error -71
Jan 11 13:59:41 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
Jan 11 13:59:46 sg-laptop kernel: usb 3-1: device descriptor read/8, error -110
Jan 11 13:59:46 sg-laptop kernel: scsi 6:0:0:0: Device offlined - not ready after error recovery
Jan 11 13:59:46 sg-laptop kernel: usb 3-1: USB disconnect, device number 2

lspci for the affected host:

04:00.0 0c03: 1b73:1000 (rev 04) (prog-if 30 [XHCI])
        Subsystem: 1043:1039
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at dd200000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [80] Express (v1) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_hcd

The commit was backported to stable kernels, and will need to be
reverted there as well.
Signed-off-by: NSarah Sharp <sarah.a.sharp@intel.com>
Reported-by: NSergey Galanov <sergey.e.galanov@gmail.com>
Cc: stable@vger.kernel.org
      140e3026
  13. 08 1月, 2014 1 次提交
  15. 09 12月, 2013 3 次提交
  17. 15 10月, 2013 1 次提交
  19. 12 10月, 2013 2 次提交
    • M
      drivers: usb: core: hcd.c: converted busmap from struct to bitmap · 059239ad
      由 Matthias Beyer 提交于 
      The DECLARE_BITMAP macro should be used for declaring this bitmap.
This commit converts the busmap from a struct to a simple (static)
bitmap, using the DECLARE_BITMAP macro from linux/types.h.

Please review, as I'm new to kernel development, I don't know if this
has any hidden side effects!

Suggested by joe@perches.com
Signed-off-by: NMatthias Beyer <mail@beyermatthias.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      059239ad
    • H
      usb-anchor: Delay usb_wait_anchor_empty_timeout wake up till completion is done · 6ec4147e
      由 Hans de Goede 提交于 
      usb_wait_anchor_empty_timeout() should wait till the completion handler
has run. Both the zd1211rw driver and the uas driver (in its task mgmt) depend
on the completion handler having completed when usb_wait_anchor_empty_timeout()
returns, as they read state set by the completion handler after an
usb_wait_anchor_empty_timeout() call.

But __usb_hcd_giveback_urb() calls usb_unanchor_urb before calling the
completion handler. This is necessary as the completion handler may
re-submit and re-anchor the urb. But this introduces a race where the state
these drivers want to read has not been set yet by the completion handler
(this race is easily triggered with the uas task mgmt code).

I've considered adding an anchor_count to struct urb, which would be
incremented on anchor and decremented on unanchor, and then only actually
do the anchor / unanchor on 0 -> 1 and 1 -> 0 transtions, combined with
moving the unanchor call in hcd_giveback_urb to after calling the completion
handler. But this will only work if urb's are only re-anchored to the same
anchor as they were anchored to before the completion handler ran.

And at least one driver re-anchors to another anchor from the completion
handler (rtlwifi).

So I have come up with this patch instead, which adds the ability to
suspend wakeups of usb_wait_anchor_empty_timeout() waiters to the usb_anchor
functionality, and uses this in __usb_hcd_giveback_urb() to delay wake-ups
until the completion handler has run.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ec4147e
  21. 06 10月, 2013 5 次提交
  23. 18 9月, 2013 3 次提交
  25. 26 8月, 2013 1 次提交
  27. 15 8月, 2013 1 次提交
    • S
      usb: rh_call_control tbuf overflow fix · e57e780b
      由 Sean O. Stalley 提交于 
      rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.

tbuf is currently statically allocated on the stack with a size
of 15 bytes, regardless of the size specified in the URB.
This patch dynamically allocates tbuf, and ensures that tbuf is
at least as big as the buffer in the URB.

If an hcd attempts to write a descriptor containing more than
15 bytes ( such as the Standard BOS Descriptor for hubs, defined
in the USB3.0 Spec, section 10.13.1 ) the write would overflow
the buffer and corrupt the stack. This patch addresses this
behavior.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NSean O. Stalley <sean.stalley@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e57e780b
  29. 13 8月, 2013 2 次提交
    • M
      usb/hcd: Log error code if reset() fails · c10750b2
      由 Mark Brown 提交于 
      If someone provided meaningful error codes from reset() we should tell the
user what they were.
Signed-off-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c10750b2
    • M
      USB: HCD: support giveback of URB in tasklet context · 94dfd7ed
      由 Ming Lei 提交于 
      This patch implements the mechanism of giveback of URB in
tasklet context, so that hardware interrupt handling time for
usb host controller can be saved much, and HCD interrupt handling
can be simplified.

Motivations:

1), on some arch(such as ARM), DMA mapping/unmapping is a bit
time-consuming, for example: when accessing usb mass storage
via EHCI on pandaboard, the common length of transfer buffer is 120KB,
the time consumed on DMA unmapping may reach hundreds of microseconds;
even on A15 based box, the time is still about scores of microseconds

2), on some arch, reading DMA coherent memoery is very time-consuming,
the most common example is usb video class driver[1]

3), driver's complete() callback may do much things which is driver
specific, so the time is consumed unnecessarily in hardware irq context.

4), running driver's complete() callback in hardware irq context causes
that host controller driver has to release its lock in interrupt handler,
so reacquiring the lock after return may busy wait a while and increase
interrupt handling time. More seriously, releasing the HCD lock makes
HCD becoming quite complicated to deal with introduced races.

So the patch proposes to run giveback of URB in tasklet context, then
time consumed in HCD irq handling doesn't depend on drivers' complete and
DMA mapping/unmapping any more, also we can simplify HCD since the HCD
lock isn't needed to be released during irq handling.

The patch should be reasonable and doable:

1), for drivers, they don't care if the complete() is called in hard irq
context or softirq context

2), the biggest change is the situation in which usb_submit_urb() is called
in complete() callback, so the introduced tasklet schedule delay might be a
con, but it shouldn't be a big deal:

	- control/bulk asynchronous transfer isn't sensitive to schedule
	  delay

	- the patch schedules giveback of periodic URBs using
	  tasklet_hi_schedule, so the introduced delay should be very
	  small

	- for ISOC transfer, generally, drivers submit several URBs
	  concurrently to avoid interrupt delay, so it is OK with the
	  little schedule delay.

	- for interrupt transfer, generally, drivers only submit one URB
	  at the same time, but interrupt transfer is often used in event
	  report, polling, ... situations, and a little delay should be OK.

Considered that HCDs may optimize on submitting URB in complete(), the
patch may cause the optimization not working, so introduces one flag to mark
if the HCD supports to run giveback URB in tasklet context. When all HCDs
are ready, the flag can be removed.

[1], http://marc.info/?t=136438111600010&r=1&w=2

Cc: Oliver Neukum <oliver@neukum.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94dfd7ed
  31. 03 8月, 2013 1 次提交
  33. 04 6月, 2013 1 次提交
  35. 29 3月, 2013 1 次提交
    • A
      USB: remove CONFIG_USB_SUSPEND option · 84ebc102
      由 Alan Stern 提交于 
      This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
in hub.c, where it is replaced with CONFIG_PM because the code needs
to be used in both runtime and system PM).  The net result is code
shrinkage and simplification.

There's very little point in keeping CONFIG_USB_SUSPEND because almost
everybody enables it.  The few that don't will find that the usbcore
module has gotten somewhat bigger and they will have to take active
measures if they want to prevent hubs from being runtime suspended.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Peter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84ebc102
  37. 26 3月, 2013 1 次提交
    • L
      usb: add find_raw_port_number callback to struct hc_driver() · 3f5eb141
      由 Lan Tianyu 提交于 
      xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw port number which is reflected in the xhci
extended capabilities table. This patch is to add find_raw_port_number
callback to struct hc_driver(), fill it with xhci_find_raw_port_number()
which will return raw port number and add a wrap usb_hcd_find_raw_port_number().

Otherwise, refactor xhci_find_real_port_number(). Using
xhci_find_raw_port_number() to get real index in the HW port status
registers instead of scanning through the xHCI roothub port array.
This can help to speed up.

All addresses in xhci->usb2_ports and xhci->usb3_ports array are
kown good ports and don't include following bad ports in the extended
capabilities talbe.
     (1) root port that doesn't have an entry
     (2) root port with unknown speed
     (3) root port that is listed twice and with different speeds.

So xhci_find_raw_port_number() will only return port num of good ones
and never touch bad ports above.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3f5eb141
  39. 26 1月, 2013 1 次提交
    • A
      USB: add usb_hcd_{start,end}_port_resume · da0aa716
      由 Alan Stern 提交于 
      This patch (as1649) adds a mechanism for host controller drivers to
inform usbcore when they have begun or ended resume signalling on a
particular root-hub port.  The core will then make sure that the root
hub does not get runtime-suspended while the port resume is going on.

Since commit 596d789a (USB: set hub's
default autosuspend delay as 0), the system tries to suspend hubs
whenever they aren't in use.  While a root-hub port is being resumed,
the root hub does not appear to be in use.  Attempted runtime suspends
fail because of the ongoing port resume, but the PM core just keeps on
trying over and over again.  We want to prevent this wasteful effort.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da0aa716
  41. 22 1月, 2013 1 次提交
    • L
      USB: Set usb port's DeviceRemovable according acpi information · d2123fd9
      由 Lan Tianyu 提交于 
      ACPI provide "_PLD" and "_UPC" aml methods to describe usb port
visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable()
to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in
the rh_call_control(). When hub descriptor request is issued at first time,
usb port device isn't created and usb port is not bound with acpi. So first
hub descriptor request is not changed based on ACPI information. After usb
port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure()
and then set hub port's DeviceRemovable according ACPI information and this also works
for non-root hub.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2123fd9
  43. 12 1月, 2013 1 次提交
  45. 14 11月, 2012 1 次提交
  47. 25 10月, 2012 1 次提交
    • A
      USB: speed up usb_bus_resume() · bfd1e910
      由 Alan Stern 提交于 
      This patch (as1620) speeds up USB root-hub resumes in the common case
where every enabled port has its suspend feature set (which currently
will be true for every runtime resume of the root hub).  If all the
enabled ports are suspended then resuming the root hub won't resume
any of the downstream devices.  In this case there's no need for a
Resume Recovery delay, because that delay is meant to give devices a
chance to get ready for active use.

To keep track of the port suspend features, the patch adds a
"port_is_suspended" flag to struct usb_device.  This has to be tracked
separately from the device's state; it's entirely possible for a USB-2
device to be suspended while the suspend feature on its parent port is
clear.  The reason is that devices will go into suspend whenever their
parent hub does.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reviewed-by: NPeter Chen <peter.chen@freescale.com>
Tested-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfd1e910
  49. 28 9月, 2012 1 次提交
    • A
      USB: Fix race condition when removing host controllers · 0d00dc26
      由 Alan Stern 提交于 
      This patch (as1607) fixes a race that can occur if a USB host
controller is removed while a process is reading the
/sys/kernel/debug/usb/devices file.

The usb_device_read() routine uses the bus->root_hub pointer to
determine whether or not the root hub is registered.  The is not a
valid test, because the pointer is set before the root hub gets
registered and remains set even after the root hub is unregistered and
deallocated.  As a result, usb_device_read() or usb_device_dump() can
access freed memory, causing an oops.

The patch changes the test to use the hcd->rh_registered flag, which
does get set and cleared at the appropriate times.  It also makes sure
to hold the usb_bus_list_lock mutex while setting the flag, so that
usb_device_read() will become aware of new root hubs as soon as they
are registered.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDon Zickus <dzickus@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d00dc26
  51. 27 9月, 2012 1 次提交
    • A
      USB: Fix race condition when removing host controllers · 0a231403
      由 Alan Stern 提交于 
      This patch (as1607) fixes a race that can occur if a USB host
controller is removed while a process is reading the
/sys/kernel/debug/usb/devices file.

The usb_device_read() routine uses the bus->root_hub pointer to
determine whether or not the root hub is registered.  The is not a
valid test, because the pointer is set before the root hub gets
registered and remains set even after the root hub is unregistered and
deallocated.  As a result, usb_device_read() or usb_device_dump() can
access freed memory, causing an oops.

The patch changes the test to use the hcd->rh_registered flag, which
does get set and cleared at the appropriate times.  It also makes sure
to hold the usb_bus_list_lock mutex while setting the flag, so that
usb_device_read() will become aware of new root hubs as soon as they
are registered.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDon Zickus <dzickus@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a231403