Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 30 4月, 2011 25 次提交
  3. 15 4月, 2011 2 次提交
    • G
      Revert "usb: usb_storage: do not align length of request for CBW to maxp size" · 98346f7d
      由 Greg Kroah-Hartman 提交于 
      This reverts commit 806e8f8f.

To quote Alan Stern:
	The necessity for this patch has been under discussion.

	It turns out the UDC that Mian has been working on and Felipe's
	UDC have contradictory requirements.  Mian's UDC driver wants a
	bulk-OUT transfer length to be shorter than the maxpacket size
	if a short packet is expected, whereas Felipe's UDC hardware
	always needs bulk-OUT transfer lengths to be evenly divisible by
	the maxpacket size.

	Mian has agreed to go back over the driver to resolve this
	conflict.  This means we probably will not want this patch after
	all.  (In fact, we may ultimately decide to change the gadget
	framework to require that bulk-OUT transfer lengths _always_ be
	divisible by the maxpacket size -- only the g_file_storage and
	g_mass_storage gadgets would need to be changed.)

Cc: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      98346f7d
    • G
      Revert "USB: isp1760-hcd: move imask clear after pending work is done" · 753d8534
      由 Greg Kroah-Hartman 提交于 
      This reverts commit 58085446.

To quote Richard:
	I don't think this should be mainlined. It was a
	misunderstanding on my part.  If you see all the other hdc
	drivers in the same location, they all do the same thing (i.e.
	clear the interrupt status first, then do the work) that
	"glitch" I think I saw was actually two back-to-back
	interrupts.

	Sebastian (the original author of isp1760) explained it to me a
	few days after my submission.

	sorry for the confusion

Cc: Richard Retanubun <RichardRetanubun@ruggedcom.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      753d8534
  5. 14 4月, 2011 13 次提交
    • M
      usb: gadget: storage_common: use kstrto*() · db8fa285
      由 Michal Nazarewicz 提交于 
      This commit replaces the usage of strict_strtoul() (which
became deprecated after commit 33ee3b2e) with kstrtouint().
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      db8fa285
    • G
      USB: ohci: add bus glue for the Atheros AR71XX/AR7240 SoCs · 90e6ca5c
      由 Gabor Juhos 提交于 
      The Atheros AR71XX/AR7240 SoCs have a built-in OHCI controller.
This patch adds the necessary glue code to make the generic OHCI
driver usable for them.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NImre Kaloz <kaloz@openwrt.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      90e6ca5c
    • G
      USB: ehci: add workaround for Synopsys HC bug · 2f7ac6c1
      由 Gabor Juhos 提交于 
      A Synopsys USB core used in various SoCs has a bug which might cause
that the host controller not issuing ping.

When software uses the Doorbell mechanism to remove queue heads, the
host controller still has references to the removed queue head even
after indicating an Interrupt on Async Advance. This happens if the last
executed queue head's Next Link queue head is removed.

Consequences of the defect:
The Host controller fetches the removed queue head, using memory that
would otherwise be deallocated.This results in incorrect transactions on
both the USB and system memory. This may result in undefined behavior.

Workarounds:

1) If no queue head is active (no Status field's Active bit is set)
after removing the queue heads, the software can write one of the valid
queue head addresses to the ASYNCLISTADDR register and deallocate the
removed queue head's memory after 2 microframes.

If one or more of the queue heads is active (the Active bit is set in
the Status field) after removing the queue heads, the software can delay
memory deallocation after time X, where X is the time required for the
Host Controller to go through all the queue heads once. X varies with
the number of queue heads and the time required to process periodic
transactions: if more periodic transactions must be performed, the Host
Controller has less time to process asynchronous transaction processing.

2) Do not use the Doorbell mechanism to remove the queue heads. Disable
the Asynchronous Schedule Enable bit instead.

The bug has been discussed on the linux-usb-devel mailing-list
four years ago, the original thread can be found here:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg45345.html

This patch implements the first workaround as suggested by David Brownell.

The built-in USB host controller of the Atheros AR7130/AR7141/AR7161 SoCs
requires this to work properly.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2f7ac6c1
    • G
      USB: ehci: add bus glue for the Atheros AR71XX/AR724X/AR91XX SoCs · 502fa841
      由 Gabor Juhos 提交于 
      The Atheros AR71XX/AR91XX SoCs have a built-in EHCI controller.
This patch adds the necessary glue code to make the generic EHCI
driver usable for them.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NImre Kaloz <kaloz@openwrt.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      502fa841
    • A
      xHCI: Implement AMD PLL quirk · c41136b0
      由 Andiry Xu 提交于 
      This patch disable the optional PM feature inside the Hudson3 platform under
the following conditions:

1. If an isochronous device is connected to xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

The PM feature needs to be disabled to eliminate PLL startup delays when the
link comes out of low power state. The performance of DMA data transfer could
be impacted if system delay were encountered and in addition to the PLL start
up delays. Disabling the PM would leave room for unpredictable system delays
in order to guarantee uninterrupted data transfer to isochronous audio or
video stream devices that require time sensitive information. If data in an
audio/video stream was interrupted then erratic audio or video performance
may be encountered.

AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
quirk code to pci-quirks.c and export them, xHCI driver can call it directly
without having the quirk implementation in itself.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c41136b0
    • S
      xhci: Tell USB core both roothubs lost power. · fedd383e
      由 Sarah Sharp 提交于 
      On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:

[  164.748310] usb usb1: root hub lost power or was reset
[  164.748353] usb usb2: root hub lost power or was reset
[  164.748487] usb usb3: root hub lost power or was reset
[  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[  164.870039] hub 4-0:1.0: hub_resume
...
[  164.870054] hub 3-0:1.0: hub_reset_resume

This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active.  It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:

[  164.980044] hub 4-1:1.0: hub_resume
[  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
[  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
[  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980094] hub 4-1:1.0: activate --> -22
[  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980123] hub 4-1:1.0: can't resume port 4, status -22
[  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[  164.980129] usb 4-1.4: can't resume, status -22
[  164.980131] hub 4-1:1.0: logical disconnect on port 4

This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:

[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760

Make sure to inform the USB core that *both* xHCI roothubs lost power.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      fedd383e
    • A
      usbcore: Bug fix: system can't suspend with USB3.0 device connected to USB3.0 hub · a8f08d86
      由 Andiry Xu 提交于 
      This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0
external hub, so the system can suspend and resume.

Note USB3.0 device may not work after system resume and this is a temporary
workaround. The correct fix will be in future patches.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      a8f08d86
    • M
      USB: Fix unplug of device with active streams · b214f191
      由 Matthew Wilcox 提交于 
      If I unplug a device while the UAS driver is loaded, I get an oops
in usb_free_streams().  This is because usb_unbind_interface() calls
usb_disable_interface() which calls usb_disable_endpoint() which sets
ep_out and ep_in to NULL.  Then the UAS driver calls usb_pipe_endpoint()
which returns a NULL pointer and passes an array of NULL pointers to
usb_free_streams().

I think the correct fix for this is to check for the NULL pointer
in usb_free_streams() rather than making the driver check for this
situation.  My original patch for this checked for dev->state ==
USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
conditional, so not all drivers would want this check.

Note from Sarah Sharp: This patch does avoid a potential dereference,
but the real fix (which will be implemented later) is to set the
.soft_unbind flag in the usb_driver structure for the UAS driver, and
all drivers that allocate streams.  The driver should free any streams
when it is unbound from the interface.  This avoids leaking stream rings
in the xHCI driver when usb_disable_interface() is called.

This should be queued for stable trees back to 2.6.35.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      b214f191
    • D
      USB: xhci - also free streams when resetting devices · 2dea75d9
      由 Dmitry Torokhov 提交于 
      Currently, when resetting a device, xHCI driver disables all but one
endpoints and frees their rings, but leaves alone any streams that
might have been allocated. Later, when users try to free allocated
streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
ep->ring is NULL.

Let's free not only rings but also stream data as well, so that
calling free_streams() on a device that was reset will be safe.

This should be queued for stable trees back to 2.6.35.
Reviewed-by: NMicah Elizabeth Scott <micah@vmware.com>
Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
      2dea75d9
    • J
      USB: Add initial S5P EHCI driver · 1bcc5aa8
      由 Joonyoung Shim 提交于 
      This patch adds host USB high speed driver for samsung S5P series. This
is initial driver and we need additional implementation to support some
functions like power management.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1bcc5aa8
    • J
      Revert "USB: sam-ba: add driver for Atmel SAM Boot Assistant (SAM-BA)" · b750106b
      由 Johan Hovold 提交于 
      This reverts commit 90593899.

SAM-BA devices identify themselves CDC-ACM devices and should be using
the cdc-acm driver.

Since commit 5b239f0a (USB: cdc-acm: Add pseudo
modem without AT command capabilities) cdc-acm also binds to them.

Note that the Atmel SAM-BA tools expect to use a USB-serial driver and thus
require a symlink from /dev/ttyACMn to some /dev/ttyUSBm (with m < 30) to be
able to select the device. This is simply a UI-issue that should be
fixed by Atmel.

Tested with the SAM-BA 2.10 tools and an Atmel at91sam9260-ek.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Cc: Sven Köhler <sven.koehler@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b750106b
    • M
      USB: twl4030-usb: Report correct vbus value for accessory charger adapters1 · a87103a6
      由 Matthias Kaehlcke 提交于 
      The twl4030-usb driver exports the status of VBUS as sysfs attribute.
In case an accessory charger adapter (ACA) is connected to the OTG
transceiver the attribute is always 'off', even when the charger
provides VBUS. Added a variable to keep track of the status of VBUS
and report it correctly
Signed-off-by: NMatthias Kaehlcke <matthias.kaehlcke@tomtom.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a87103a6
    • F
      USB: Mark ehci_adjust_port_wakeup_flags as __maybe_unused · 0b0cd6c8
      由 Fabio Estevam 提交于 
      Mark ehci_adjust_port_wakeup_flags as __maybe_unused to avoid the following
warning when building the ehci-mxc driver:

  CC      drivers/usb/host/ehci-hcd.o
drivers/usb/host/ehci-hub.c:130: warning: 'ehci_adjust_port_wakeup_flags' defined but not used

Current ehci-mxc driver implementation does not support suspend/resume.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0b0cd6c8