'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0f) created a regression
with Beagleboard xM if booting the kernel after running 'usb start' under u-boot.
Finishing the reset before calling 'usb_add_hcd' fixes the regression. This is most likely due to
usb_add_hcd calling the driver's reset and init functions which expect the hardware to be
up and running.
I previously cleaned up the err() call usage in this driver, but it
really was calling this macro instead. To remove future confusion, just
delete this unused macro now.
Ideally, the warn() and info() macros should also be removed, and the
"real" dev_warn() and dev_info() calls should be used instead.
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:16 +0000 (15:33 -0700)]
USB: input: usbtouchscreen.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:13 +0000 (15:33 -0700)]
USB: input: wacom_sys.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com> CC: Ping Cheng <pingc@wacom.com> CC: Chris Bagwell <chris@cnpbagwell.com> CC: Eduard Hasenleithner <eduard@hasenleithner.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:11 +0000 (15:33 -0700)]
USB: input: kbtab.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:09 +0000 (15:33 -0700)]
USB: input: gtco.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:06 +0000 (15:33 -0700)]
USB: input: aiptek.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:04 +0000 (15:33 -0700)]
USB: input: acecad.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:02 +0000 (15:33 -0700)]
USB: input: bcm5974.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:01 +0000 (15:33 -0700)]
USB: input: appletouch.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:01 +0000 (15:33 -0700)]
USB: input: yealink.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:33:00 +0000 (15:33 -0700)]
USB: input: powermate.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:32:58 +0000 (15:32 -0700)]
USB: input: keyspan_remote.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:32:55 +0000 (15:32 -0700)]
USB: input: cm109.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com> CC: Axel Lin <axel.lin@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 4 May 2012 22:32:53 +0000 (15:32 -0700)]
USB: input: xpad.c: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Fri, 4 May 2012 22:23:04 +0000 (15:23 -0700)]
USB: input: iforce: fix up dev_* messages
Previously I had made the struct device point to the input device, but
after talking with Dmitry, he said that the USB device would make more
sense for this driver to point to. So converted it to use that instead.
Greg Kroah-Hartman [Thu, 3 May 2012 23:44:48 +0000 (16:44 -0700)]
USB: sierra.c: remove dbg() tracing calls
dbg() was used a lot a long time ago to trace code flow. Now that we have
ftrace, this isn't needed at all, so remove these calls.
CC: Alan Stern <stern@rowland.harvard.edu> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Johan Hovold <jhovold@gmail.com> CC: Anton Samokhvalov <pg83@yandex.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 3 May 2012 23:44:33 +0000 (16:44 -0700)]
USB: mos7840.c: remove dbg() tracing calls
dbg() was used a lot a long time ago to trace code flow. Now that we have
ftrace, this isn't needed at all, so remove these calls.
CC: Johan Hovold <jhovold@gmail.com> CC: Donald Lee <donald@asix.com.tw> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 3 May 2012 23:44:12 +0000 (16:44 -0700)]
USB: garmin_gps.c: remove dbg() tracing calls
dbg() was used a lot a long time ago to trace code flow. Now that we have
ftrace, this isn't needed at all, so remove these calls.
CC: Johan Hovold <jhovold@gmail.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 3 May 2012 23:39:27 +0000 (16:39 -0700)]
USB: serial: pl2303: convert dbg() calls to dev_dbg()
This converts the usage of dbg() to dev_dbg() where needed, and removed
a bunch of these calls where they were just "tracing" calls, which are
no longer needed.
Greg Kroah-Hartman [Thu, 3 May 2012 20:40:55 +0000 (13:40 -0700)]
Merge tag 'for-usb-next-2012-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next
xhci: isoc, Intel xHCI, and suspend races.
Hi Greg,
Here's some xHCI fixes that should be queued for 3.5.
The first patch builds on Alan Stern's 3.4 patch to close the suspend and port
event race conditions. It's marked for 3.4 stable, since that's where Alan's
patch landed. The second patch fixes an incorrect error code that the xHCI
driver would return when an isochronous transfer error occurred.
The third and fourth patches fix issues seen on Intel xHCI host controllers.
The third patch fixes a dead port issue that was seen on the Panther Point
EHCI/xHCI host when CONFIG_USB_XHCI_HCD was turned off. The ports were being
switched over to xHCI, even though the xHCI driver was never even built. The
fourth patch adds support for the EHCI to xHCI port switchover for the upcoming
Intel Lynx Point chipset.
As I said, there's nothing here that's terribly urgent, and these patches can
wait a couple weeks for the 3.5 merge window.
Sarah Sharp [Thu, 9 Feb 2012 23:55:13 +0000 (15:55 -0800)]
xhci: Add Lynx Point to list of Intel switchable hosts.
The upcoming Intel Lynx Point chipset includes an xHCI host controller
that can have ports switched from the EHCI host controller, just like
the Intel Panther Point xHCI host. This time, ports from both EHCI
hosts can be switched to the xHCI host controller. The PCI config
registers to do the port switching are in the exact same place in the
xHCI PCI configuration registers, with the same semantics.
Hooray for shipping patches for next-gen hardware before the current gen
hardware is even available for purchase!
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
Sarah Sharp [Mon, 16 Apr 2012 17:56:47 +0000 (10:56 -0700)]
xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n
If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system
with an Intel Panther Point chipset, the PCI quirks code or the EHCI
driver will switch the ports over to the xHCI host, but the xHCI driver
will never load. The ports will be powered off and seem "dead" to the
user.
Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is
either compiled in, or compiled as a module.
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
"Intel xhci: Support EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Eric Anholt <eric.anholt@intel.com> Reported-by: David Bein <d.bein@f5.com> Cc: stable@vger.kernel.org
Hans de Goede [Mon, 23 Apr 2012 13:06:09 +0000 (15:06 +0200)]
usb-xhci: Handle COMP_TX_ERR for isoc tds
While testing unplugging an UVC HD webcam with usb-redirection (so through
usbdevfs), my userspace usb-redir code was getting a value of -1 in
iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
is not a valid value.
The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
in this case, so this patch adds handling for that completion code to
process_isoc_td().
This was observed and tested with the following xhci controller:
1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
do, but since I cannot come up with anything better I've left that as is.
This patch should be backported to kernels as old as 2.6.36, which contain the
commit 04e51901dd44f40a5a385ced897f6bca87d5f40a "USB: xHCI: Isochronous
transfer implementation".
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
xHCI: keep track of ports being resumed and indicate in hub_status_data
This commit adds a bit-array to xhci bus_state for keeping track of
which ports are undergoing a resume transition. If any of the bits
are set when xhci_hub_status_data() is called, the routine will return
a non-zero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.
This patch should be backported to kernels as old as 3.4, that contain
the commit 879d38e6bc36d73b0ac40ec9b0d839fda9fa8b1a "USB: fix race
between root-hub suspend and remote wakeup".
Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
Preston Fick [Tue, 1 May 2012 04:06:48 +0000 (23:06 -0500)]
usb: cp210x: Corrected USB request type definitions
The original request types in the cp210x driver are labled as "DEVICE_TO_HOST" and
"HOST_TO_DEVICE" but the actual bit definition corresponds to a request to the
interface. This has been corrected, and the actual definition for the device
requests have been added.
Signed-off-by: Preston Fick <preston.fick@silabs.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / users / willy / linux.git / log