Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 9月, 2011 7 次提交
    • S
      xhci: Track interval bandwidth tables per port/TT. · 2e27980e
      由 Sarah Sharp 提交于 
      In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval.  That way we can
easily know the new largest max packet size when we have to remove an
endpoint.

Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size.  Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size.  Only insert endpoints and update the interval table with new
information when those endpoints are periodic.

Make sure to update the number of active TTs when we add or drop periodic
endpoints.  A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus).  If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport.  If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.

We have to be careful when we're checking the bandwidth for a new
configuration/alt setting.  If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table.  We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list.  Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.

We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits.  Besides which, we can't fail a device disconnect.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2e27980e
    • S
      xhci: Store endpoint bandwidth information. · 9af5d71d
      由 Sarah Sharp 提交于 
      In the upcoming patches, we'll use some stored endpoint information to
make software keep track of the worst-case bandwidth schedule.  We need to
store several variables associated with each periodic endpoint:
 - the type of endpoint
 - Max Packet Size
 - Mult
 - Max ESIT payload
 - Max Burst Size (aka number of packets, stored in one-based form)
 - the endpoint interval (normalized to powers of 2 microframes)

All this information is available to the hardware, and stored in its
device output context.  However, we need to ensure that the new
information is stored before the xHCI driver drops the xhci->lock to wait
on the Configure Endpoint command, so that another driver requesting a
configuration or alt setting change will see the update.  The Configure
Endpoint command will never fail on the hardware that needs this software
bandwidth checking (assuming the slot is enabled and the flags are set
properly), so updating the endpoint info before the command completes
should be fine.

Until we add in the bandwidth checking code, just update the endpoint
information after the Configure Endpoint command completes, and after a
Reset Device command completes.  Don't bother to clear the endpoint
bandwidth info when a device is being freed, since the xhci_virt_ep is
just going to be freed anyway.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9af5d71d
    • S
      xhci: Store information about roothubs and TTs. · 839c817c
      由 Sarah Sharp 提交于 
      For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host.  Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.

If the table were in text form, it would look a bit like this:

EP Interval	Sum of Number	Largest Max	Max Packet
		of Packets	Packet Size	Overhead
	0	   N		   mps		  overhead
...
	15	   N		   mps		  overhead

Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval.  Devices with
different speeds have different max packet overhead.  For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead).  Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size.  That's stored in
the interval0_esit_payload variable.  For root ports, we also need to keep
track of the number of active TTs.

For each root port, and each TT under a root port, store some information
about the bandwidth consumption.  Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port.  A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.

When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub.  When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub.  Keep track of which TT entry is associated with a
device under a TT.

LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub.  Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      839c817c
    • S
      xhci: Store the "real" root port number. · 66381755
      由 Sarah Sharp 提交于 
      Since the xHCI driver now has split USB2/USB3 roothubs, devices under each
roothub can have duplicate "fake" port numbers.  For the next set of
patches, we need to keep track of the "real" port number that the xHCI
host uses to index into the port status arrays.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      66381755
    • S
      xhci: Refactor endpoint limit checking. · 750645f8
      由 Sarah Sharp 提交于 
      Move the code to check whether we've reached the host controller's limit
on the number of endpoints out of the two conditional statements, to
remove duplicate code.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      750645f8
    • S
      xhci: Rename virt_dev->port to fake_port. · fe30182c
      由 Sarah Sharp 提交于 
      The "port" field in xhci_virt_dev stores the port number associated with
one of the two xHCI split roothubs, not the unique port number the xHCI
hardware uses.  Since we'll need to store the real hardware port number in
future patches, rename this field to "fake_port".
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fe30182c
    • S
      xhci: If no endpoints changed, don't issue BW command. · 2dc37539
      由 Sarah Sharp 提交于 
      Some alternate interface settings have no endpoints associated with them.
This shows up in some USB webcams, particularly the Logitech HD 1080p,
which uses the uvcvideo driver.  If a driver switches between two alt
settings with no endpoints, there is no need to issue a configure endpoint
command, because there is no endpoint information to update.

The only time a configure endpoint command with just the add slot flag set
makes sense is when the driver is updating hub characteristics in the slot
context.  However, that code never calls xhci_check_bandwidth, so we
should be safe not issuing a command if only the slot context add flag is
set.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2dc37539
  3. 25 8月, 2011 1 次提交
  5. 24 8月, 2011 2 次提交
    • K
      USB: use usb_endpoint_maxp() instead of le16_to_cpu() · 29cc8897
      由 Kuninori Morimoto 提交于 
      Now ${LINUX}/drivers/usb/* can use usb_endpoint_maxp(desc) to get maximum packet size
instead of le16_to_cpu(desc->wMaxPacketSize).
This patch fix it up

Cc: Armin Fuerst <fuerst@in.tum.de>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Johannes Erdfelt <johannes@erdfelt.com>
Cc: Vojtech Pavlik <vojtech@suse.cz>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: David Kubicek <dave@awk.cz>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Brad Hards <bhards@bigpond.net.au>
Acked-by: NFelipe Balbi <balbi@ti.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Dahlmann <dahlmann.thomas@arcor.de>
Cc: David Brownell <david-b@pacbell.net>
Cc: David Lopo <dlopo@chipidea.mips.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Michal Nazarewicz <m.nazarewicz@samsung.com>
Cc: Xie Xiaobo <X.Xie@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Jiang Bo <tanya.jiang@freescale.com>
Cc: Yuan-hsin Chen <yhchen@faraday-tech.com>
Cc: Darius Augulis <augulis.darius@gmail.com>
Cc: Xiaochen Shen <xiaochen.shen@intel.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: OKI SEMICONDUCTOR, <toshiharu-linux@dsn.okisemi.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Ben Dooks <ben@simtec.co.uk>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Herbert Pötzl <herbert@13thfloor.at>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Roman Weissgaerber <weissg@vienna.at>
Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: Florian Floe Echtler <echtler@fs.tum.de>
Cc: Christian Lucht <lucht@codemercs.com>
Cc: Juergen Stuber <starblue@sourceforge.net>
Cc: Georges Toth <g.toth@e-biz.lu>
Cc: Bill Ryder <bryder@sgi.com>
Cc: Kuba Ober <kuba@mareimbrium.org>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      29cc8897
    • J
      usb: fhci-hcd: Allocate pram dynamically. · 39eb4ed5
      由 Joakim Tjernlund 提交于 
      MPC832x does not have enough MURAM to do fixed MURAM allocation.
Change to dynamic allocation.
Signed-off-by: NJoakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      39eb4ed5
  7. 23 8月, 2011 13 次提交
  9. 17 8月, 2011 1 次提交
    • S
      xhci: Handle zero-length isochronous packets. · 48df4a6f
      由 Sarah Sharp 提交于 
      For a long time, the xHCI driver has had this note:
	/* FIXME: Ignoring zero-length packets, can those happen? */

It turns out that, yes, there are drivers that need to queue zero-length
transfers for isochronous OUT transfers.  Without this patch, users will
see kernel hang messages when a driver attempts to enqueue an isochronous
URB with a zero length transfer (because count_isoc_trbs_needed will return
zero for that TD, xhci_td->last_trb will never be set, and updating the
dequeue pointer will cause an infinite loop).

Matěj ran into this issue when using an NI Audio4DJ USB soundcard
with the snd-usb-caiaq driver.  See
	https://bugzilla.kernel.org/show_bug.cgi?id=40702

Fix count_isoc_trbs_needed() to return 1 for zero-length transfers (thanks
Alan on the math help).  Update the various TRB field calculations to deal
with zero-length transfers.  We're still transferring one packet with a
zero-length data payload, so the total_packet_count should be 1. The
Transfer Burst Count (TBC) and Transfer Last Burst Packet Count (TLBPC)
fields should be set to zero.

This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NMatěj Laitl <matej@laitl.cz>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@kernel.org
      48df4a6f
  11. 12 8月, 2011 1 次提交
  13. 10 8月, 2011 5 次提交
    • S
      xhci: Remove TDs from TD lists when URBs are canceled. · 585df1d9
      由 Sarah Sharp 提交于 
      When a driver tries to cancel an URB, and the host controller is dying,
xhci_urb_dequeue will giveback the URB without removing the xhci_tds
that comprise that URB from the td_list or the cancelled_td_list.  This
can cause a race condition between the driver calling URB dequeue and
the stop endpoint command watchdog timer.

If the timer fires on a dying host, and a driver attempts to resubmit
while the watchdog timer has dropped the xhci->lock to giveback a
cancelled URB, URBs may be given back by the xhci_urb_dequeue() function.
At that point, the URB's priv pointer will be freed and set to NULL, but
the TDs will remain on the td_list.  This will cause an oops in
xhci_giveback_urb_in_irq() when the watchdog timer attempts to loop
through the endpoints' td_lists, giving back killed URBs.

Make sure that xhci_urb_dequeue() removes TDs from the TD lists and
canceled TD lists before it gives back the URB.

This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
      585df1d9
    • S
      xhci: Fix failed enqueue in the middle of isoch TD. · 522989a2
      由 Sarah Sharp 提交于 
      When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB.  However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.

With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state.  The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware.  The
enqueue pointer is left on the TRB after the last successfully enqueued
TD.  This means the ring is basically useless.  Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them.  The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.

The untransferred TDs will also remain on the TD list.  Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).

Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv.  If the Nth TD failed, first remove the TDs
from the td_list.  Then convert the TRBs that were enqueued into No-op
TRBs.  Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact.  Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.

This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.

This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue.  I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.

This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
      522989a2
    • S
      xhci: Fix memory leak during failed enqueue. · d13565c1
      由 Sarah Sharp 提交于 
      When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.

xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.

xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail.  Instead, it expects those functions to
free urb_priv if an error occurs.  However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL.  It will, however, get freed if prepare_transfer() fails in those
enqueue functions.

Several of the error paths in the isochronous endpoint enqueue function
also fail to free it.  xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB.  If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.

This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.

This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.

This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
      d13565c1
    • A
      xHCI: report USB2 port in resuming as suspend · 8a8ff2f9
      由 Andiry Xu 提交于 
      When a USB2 port initiate a remote wakeup, software shall ensure that
resume is signaled for at least 20ms, and then write '0' to the PLS field.
According to this, xhci driver do the following things:

1. When receive a remote wakeup event in irq_handler, set the resume_done
   value as jiffies + 20ms, and modify rh_timer to poll root hub status at
   that time;
2. When receive a GetPortStatus request, if the jiffies is after the
   resume_done value, clear the resume signal and resume_done.

However, if usb_port_resume() is called before the rh_timer triggered, it
will indicate the port as Suspend Cleared and skip the clear resume signal
part. The device will fail the usb_get_status request in finish_port_resume(),
and usbcore will try a reset-resume instead. Device will work OK after
reset-resume, but resume_done value is not cleared in this case, and
xhci_bus_suspend() will fail because when it finds a non-zero resume_done
value, it will regard the port as resuming and return -EBUSY.

This causes issue on some platforms that the system fail to suspend
after remote wakeup from suspend by USB2 devices connected to xHCI port.

To fix this issue, report the port status as suspend if the resume is
signaling less that 20ms, and usb_port_resume() will wait 25ms and check
port status again, so xHCI driver can clear the resume signaling and
resume_done value.

This should be backported to kernels as old as 2.6.37.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      8a8ff2f9
    • A
      xHCI: fix port U3 status check condition · 5ac04bf1
      由 Andiry Xu 提交于 
      Fix the port U3 status check when Clear PORT_SUSPEND Feature.
The port status should be masked with PORT_PLS_MASK to check if it's in
U3 state.

This should be backported to kernels as old as 2.6.37.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      5ac04bf1
  15. 09 8月, 2011 4 次提交
  17. 02 8月, 2011 3 次提交
    • M
      usb: host: ehci-omap: fix .remove and failure handling path of .probe(v1) · d4aefec5
      由 Ming Lei 提交于 
      Obviously, disabling & put regulator and iounmap(hcd->regs)
are missed in .remove and failure handling path of .probe,
so add them.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NKeshava Munegowda <Keshava_mgowda@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      d4aefec5
    • J
      USB: xhci: fix OS want to own HC · 6768458b
      由 JiSheng Zhang 提交于 
      Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC.

This patch should be backported to kernels as far back as 2.6.31.
Signed-off-by: NJiSheng Zhang <jszhang3@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      6768458b
    • S
      xhci: Don't submit commands or URBs to halted hosts. · 7bd89b40
      由 Sarah Sharp 提交于 
      Commit fccf4e86
"USB: Free bandwidth when usb_disable_device is called" caused a bit of an
issue when the xHCI host controller driver is unloaded.  It changed the
USB core to remove all endpoints when a USB device is disabled.  When the
driver is unloaded, it will remove the SuperSpeed split root hub, which
will disable all devices under that roothub and then halt the host
controller.  When the second High Speed split roothub is removed, the USB
core will attempt to disable the endpoints, which will submit a Configure
Endpoint command to a halted host controller.

The command will eventually time out, but it makes the xHCI driver unload
take *minutes* if there are a couple of USB 1.1/2.0 devices attached.  We
must halt the host controller when the SuperSpeed roothub is removed,
because we can't allow any interrupts from things like port status
changes.

Make several different functions not submit commands or URBs to the host
controller when the host is halted, by adding a check in
xhci_check_args().  xhci_check_args() is used by these functions:

xhci.c-int xhci_urb_enqueue()
xhci.c-int xhci_drop_endpoint()
xhci.c-int xhci_add_endpoint()
xhci.c-int xhci_check_bandwidth()
xhci.c-void xhci_reset_bandwidth()
xhci.c-static int xhci_check_streams_endpoint()
xhci.c-int xhci_discover_or_reset_device()

It's also used by xhci_free_dev().  However, we have to take special
care in that case, because we want the device memory to be freed if the
host controller is halted.

This patch should be backported to the 2.6.39 and 3.0 kernel.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      7bd89b40
  19. 20 7月, 2011 1 次提交
    • A
      EHCI: fix direction handling for interrupt data toggles · e04f5f7e
      由 Alan Stern 提交于 
      This patch (as1480) fixes a rather obscure bug in ehci-hcd.  The
qh_update() routine needs to know the number and direction of the
endpoint corresponding to its QH argument.  The number can be taken
directly from the QH data structure, but the direction isn't stored
there.  The direction is taken instead from the first qTD linked to
the QH.

However, it turns out that for interrupt transfers, qh_update() gets
called before the qTDs are linked to the QH.  As a result, qh_update()
computes a bogus direction value, which messes up the endpoint toggle
handling.  Under the right combination of circumstances this causes
usb_reset_endpoint() not to work correctly, which causes packets to be
dropped and communications to fail.

Now, it's silly for the QH structure not to have direct access to all
the descriptor information for the corresponding endpoint.  Ultimately
it may get a pointer to the usb_host_endpoint structure; for now,
adding a copy of the direction flag solves the immediate problem.

This allows the Spyder2 color-calibration system (a low-speed USB
device that sends all its interrupt data packets with the toggle set
to 0 and hance requires constant use of usb_reset_endpoint) to work
when connected through a high-speed hub.  Thanks to Graeme Gill for
supplying the hardware that allowed me to track down this bug.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NGraeme Gill <graeme@argyllcms.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e04f5f7e
  21. 16 7月, 2011 1 次提交
    • A
      USB: OHCI: fix another regression for NVIDIA controllers · 6ea12a04
      由 Alan Stern 提交于 
      The NVIDIA series of OHCI controllers continues to be troublesome.  A
few people using the MCP67 chipset have reported that even with the
most recent kernels, the OHCI controller fails to handle new
connections and spams the system log with "unable to enumerate USB
port" messages.  This is different from the other problems previously
reported for NVIDIA OHCI controllers, although it is probably related.

It turns out that the MCP67 controller does not like to be kept in the
RESET state very long.  After only a few seconds, it decides not to
work any more.  This patch (as1479) changes the PCI initialization
quirk code so that NVIDIA controllers are switched into the SUSPEND
state after 50 ms of RESET.  With no interrupts enabled and all the
downstream devices reset, and thus unable to send wakeup requests,
this should be perfectly safe (even for non-NVIDIA hardware).

The removal code in ohci-hcd hasn't been changed; it will still leave
the controller in the RESET state.  As a result, if someone unloads
ohci-hcd and then reloads it, the controller won't work again until
the system is rebooted.  If anybody complains about this, the removal
code can be updated similarly.

This fixes Bugzilla #22052.
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6ea12a04
  23. 09 7月, 2011 1 次提交