- 30 Mar, 2013 16 commits
-
-
Michael Grzeschik authored
This adds mx53 as the next user of the usbmisc driver and makes it possible to disable the overcurrent-detection of the internal phy. Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> [Alex: fixed another set of line-too-long and void pointer cast] Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marc Kleine-Budde authored
This attaches the usbmisc_ops to the of_device_id data and makes it possible to define special functions per soc. Signed-off-by:
-
Marc Kleine-Budde authored
This fixes a potential race condition where the ci13xxx_imx glue code could be fast enough to call one of the usbmisc_ops before he got a valid value on the static usbmisc pointer. To fix that we first set usbmisc, then call usbmisc_set_ops(). Signed-off-by:
-
Marc Kleine-Budde authored
The probe function checks usbmisc to be NULL in the beginning. Without this patch the can only be loaded once. Signed-off-by:
-
Michael Grzeschik authored
This driver will be used for every Freescale SoC which has this misc memory layout to control the basic usb handling. So better name this driver, function and struct names in a more generic way. Reported-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Felipe Balbi authored
chipidea's ffs_nr() is pretty much what __ffs() does. Use that one instead. Signed-off-by:
Felipe Balbi <balbi@ti.com> [rebased on top of debug infrastructure rework] Signed-off-by:
-
Dan Carpenter authored
The intent here was to have parenthesis around the (ci->hw_ep_max / 2) so that it counts like "0 1 2 0 1 2". In the current code, the mod operation happens first so it counts like "0 0 1 1 2 2". Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> [rebased on top of debug.c changes] Signed-off-by:
-
Alexander Shishkin authored
Create and remove debugfs entries in hdrc probe/remove instead of start/stop of the device controller. Gadget specific will not export anything while the controller is in host mode. Signed-off-by:
-
Alexander Shishkin authored
Manual role switching function is there for debugging purposes, so has to move to debugfs. Signed-off-by:
-
Alexander Shishkin authored
Currently, we have a bunch of files in sysfs that display all sorts of debugging information for the device controller, so they have to move to debugfs where they belong. The "registers" interface have been removed, since it doesn't fit into the current driver design as is and it's hardly a good idea to touch the registers from userspace anyway. Signed-off-by:
-
Alexander Shishkin authored
As part of the legacy from the original driver design, we retain home-grown tracing infrastructure, complete with own ring buffer and timestamps, which among other things has a performance penalty. This patch removes it. Signed-off-by:
-
Peter Chen authored
There are several problems with this patch: + in introduces a sparse warning for a condition that's always negative, + and because of that, it actually doesn't do anything useful, + and vbus detection belongs to otg, not device function anyway. This reverts commit 8c4fc031. Signed-off-by:
Peter Chen <peter.chen@freescale.com> [Alex: amended the above text] Signed-off-by:
-
Felipe Balbi authored
switch over to the newly added devm_ioremap_resource which provides more consistent error messages. Signed-off-by:
-
Alexander Shishkin authored
Some headers included in the chipidea controller core are not needed, remove them. Signed-off-by:
-
Alexander Shishkin authored
Some headers included in udc core code are not actually needed, remove them and add irqreturn.h, which was implicitly included via irq.h. Signed-off-by:
-
Alexander Shishkin authored
debug.c is carrying a lot of includes that aren't needed there, although they implicitly include the ones that are actually needed. Replace the former with the latter. Signed-off-by:
-
- 29 Mar, 2013 1 commit
-
-
Julius Werner authored
Commit 9214d1d8 set the USB persist flag as a default for all devices. This might be desirable for some distributions, but it certainly has its trade-offs... most importantly, it can significantly increase system resume time, because the kernel blocks on resuming (and sometimes resetting) USB devices before it unfreezes userspace. This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST, which allows distributions to make this decision on their own without the need to carry a custom patch or revert the kernel's setting in userspace. [edited the Kconfig help text a bit - gregkh] Signed-off-by:
Julius Werner <jwerner@chromium.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
- 28 Mar, 2013 14 commits
-
-
Arnd Bergmann authored
Patch 4d053fda "usb: ehci: unlink_empty_async_suspended() only used with CONFIG_PM" tried to hide the unlink_empty_async_suspended function inside of an #ifdef to work around an unused function warning. Unfortunately that had the effect of introducing a new warning: drivers/usb/host/ehci-q.c:1297:13: warning: 'unlink_empty_async_suspended' declared 'static' but never defined [-Wunused-function] While we could add another #ifdef around the function declaration to avoid this, a nicer solution is to mark it as __maybe_unused, which will let gcc silently drop the function definition when it is not needed. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Alan Stern authored
It seems to be getting more common recently for EHCI host controllers to be probed after their companion UHCI or OHCI controllers. This may be caused partly by splitting the ehci-pci driver out from ehci-hcd, or it may be caused by changes in the way the kernel does driver probing. Regardless, it has a tendency to cause problems. When an EHCI controller is initialized, it takes ownership of all the ports away from the companions. In effect, it forcefully disconnects all the USB devices that may already be using a companion controller. This patch (as1672b) tries to make the transition more orderly by deconfiguring the root hubs for all the companion controllers before initializing the EHCI controller, and reconfiguring them afterward. The result is a soft disconnect rather than a hard one. Internally, the patch refactors the code involved in associating EHCI controllers with their companions. The old approach, in which a single function is called with an argument telling it what to do (the companion_action enum), has been replaced with a scheme using multiple callback functions, each performing a single task. This patch won't solve all the problems people encounter when their EHCI controllers start up, but it will at least reduce the number of error messages generated by the unexpected disconnections. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Jenya Y <jy.gerstmaier@gmail.com> Signed-off-by:
-
Alan Stern authored
An earlier patch removed the CONFIG_USB_SUSPEND symbol but forgot to update the Documentation files. This patch (as1676) rectifies that omission. Signed-off-by:
-
Arnd Bergmann authored
This lets us use the ehci-platform driver on platforms without special requirements for their ehci controllers. In particular, this is true for the vt8500/wm8x50 platforms, which currently have a separate driver that causes problems with multiplatform configurations. Tested-by:
Tony Prisk <linux@prisktech.co.nz> Tested-by:
Peter Vasil <petervasil@gmail.com> Acked-by:
-
Tony Prisk authored
Compiling with !CONFIG_PM generates an unused function warning on unlink_empty_async_suspended(). Enclose the function in a #ifdef CONFIG_PM Signed-off-by:
-
Jingoo Han authored
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/usb/host/ehci-spear.c:82:12: warning: 'ehci_spear_drv_suspend' defined but not used [-Wunused-function] drivers/usb/host/ehci-spear.c:90:12: warning: 'ehci_spear_drv_resume' defined but not used [-Wunused-function] Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by:
-
Nobuhiro Iwamatsu authored
By commit 39d35681 (USB: remove incorrect __exit markups), comma following ehci_hcd_sh_remove has been deleted. This fixes the error by the correction. Signed-off-by:
-
Alan Stern authored
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:
-
Alan Stern authored
This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems. Signed-off-by:
-
Alan Stern authored
This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit eba0e3c3. When merged together (usb-linus and usb-next), this fix isn't needed and causes a build error. Revert the commit to solve the build issue. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This lets us fix the build error that happens when these two trees are merged together. Signed-off-by: -
Konstantin Holoborodko authored
It enhances the driver for FTDI-based USB serial adapters to recognize Mitsubishi Electric Corp. USB/RS422 Converters as FT232BM chips and support them. https://search.meau.com/?q=FX-USB-AWSigned-off-by:
Konstantin Holoborodko <klh.kernel@gmail.com> Tested-by:
-
- 27 Mar, 2013 1 commit
-
-
Roland Stigge authored
The current lpc32xx_defconfig breaks like this, caused by recent phy restructuring: LD init/built-in.o drivers/built-in.o: In function `usb_hcd_nxp_probe': drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client' drivers/built-in.o: In function `lpc32xx_udc_probe': drivers/usb/gadget/lpc32xx_udc.c:3104: undefined reference to `isp1301_get_client' distcc[27867] ERROR: compile (null) on localhost failed make: *** [vmlinux] Error 1 Caused by 1c208881 (usb: Makefile: fix drivers/usb/phy/ Makefile entry) This patch fixes this by selecting USB_OTG_UTILS in Kconfig which causes the phy driver to be built again. Signed-off-by:
Roland Stigge <stigge@antcom.de> Acked-by:
-
- 26 Mar, 2013 2 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'for-usb-linus-2013-03-26' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus Misc xHCI fixes for 3.9 Hi Greg, Here's a couple of fixes for the xHCI driver. Three patches are nothing major: build warning fix, macro field width fix, and removing some unnecessary log spam. The only interesting thing here is Tianyu's two patches to fix the USB port connection type discovery, for the USB port power off mechanism. This adds new USB host API, but as discussed, it's necessary to avoid powering off the wrong USB port. It's not marked for backport to stable kernels, since the sysfs mechanism to manually power off a port didn't go in until 3.9. I've smoke tested these, including system suspend, USB device suspend, and rocking out in my cube with a pair of USB headphones. They look fine to me. Hibernate is currently broken on my system, due to some nouveau MMIO read faults. I'll report that separately. Sarah Sharp
-
Ming Lei authored
Johan's 'fix use-after-free in TIOCMIWAIT' patchset[1] introduces one bug which can cause kernel hang when opening port. This patch initialized the 'port->delta_msr_wait' waitqueue head to fix the bug which is introduced in 3.9-rc4. [1], http://marc.info/?l=linux-usb&m=136368139627876&w=2 Cc: stable <stable@vger.kernel.org> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Acked-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
- 25 Mar, 2013 6 commits
-
-
Soeren Moch authored
[Description written by Alan Stern] Soeren tracked down a very difficult bug in ehci-hcd's DMA pool management of iTD and siTD structures. Some background: ehci-hcd gives each isochronous endpoint its own set of active and free itd's (or sitd's for full-speed devices). When a new itd is needed, it is taken from the head of the free list, if possible. However, itd's must not be used twice in a single frame because the hardware continues to access the data structure for the entire duration of a frame. Therefore if the itd at the head of the free list has its "frame" member equal to the current value of ehci->now_frame, it cannot be reused and instead a new itd is allocated from the DMA pool. The entries on the free list are not released back to the pool until the endpoint is no longer in use. The bug arises from the fact that sometimes an itd can be moved back onto the free list before itd->frame has been set properly. In Soeren's case, this happened because ehci-hcd can allocate one more itd than it actually needs for an URB; the extra itd may or may not be required depending on how the transfer aligns with a frame boundary. For example, an URB with 8 isochronous packets will cause two itd's to be allocated. If the URB is scheduled to start in microframe 3 of frame N then it will require both itds: one for microframes 3 - 7 of frame N and one for microframes 0 - 2 of frame N+1. But if the URB had been scheduled to start in microframe 0 then it would require only the first itd, which could cover microframes 0 - 7 of frame N. The second itd would be returned to the end of the free list. The itd allocation routine initializes the entire structure to 0, so the extra itd ends up on the free list with itd->frame set to 0 instead of a meaningful value. After a while the itd reaches the head of the list, and occasionally this happens when ehci->now_frame is equal to 0. Then, even though it would be okay to reuse this itd, the driver thinks it must get another itd from the DMA pool. For as long as the isochronous endpoint remains in use, this flaw in the mechanism causes more and more itd's to be taken slowly from the DMA pool. Since none are released back, the pool eventually becomes exhausted. This reuslts in memory allocation failures, which typically show up during a long-running audio stream. Video might suffer the same effect. The fix is very simple. To prevent allocations from the pool when they aren't needed, make sure that itd's sent back to the free list prematurely have itd->frame set to an invalid value which can never be equal to ehci->now_frame. This should be applied to -stable kernels going back to 3.6. Signed-off-by:
Soeren Moch <smoch@web.de> Signed-off-by:
-
Johan Hovold authored
Update copyright information. Signed-off-by:
-
Johan Hovold authored
Remove bogus disconnect test for serial device being NULL in close. This can never happen as close is guaranteed to be called before the last tty reference is dropped (and port->serial is cleared). Signed-off-by:
-
Johan Hovold authored
Remove bogus disconnect test for serial device being NULL in read bulk callback. This can never happen as the port read urb is killed (and poisoned) at close, which in turn is guaranteed to be called before the last tty reference is dropped (and port->serial is cleared). Signed-off-by:
-
Johan Hovold authored
Remove bogus disconnect test for serial device being NULL in close. This can never happen as close is guaranteed to be called before the last tty reference is dropped (and port->serial is cleared). Signed-off-by:
-
Johan Hovold authored
Always try to disable the uart on close. Since the switch to tty ports, close will be called as part of shutdown before disconnect returns. Hence there is no need to check the disconnected flag, and we can put devices in disabled states also on driver unbind. Signed-off-by:
-
