aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2013-08-12usb: phy: tegra: Program new PHY parametersTuomas Tynkkynen1-18/+63
The Tegra30 TRM recommends configuration of certain PHY parameters for optimal quality. Program the following registers based on device tree parameters: - UTMIP_XCVR_HSSLEW: HS slew rate control. - UTMIP_HSSQUELCH_LEVEL: HS squelch detector level - UTMIP_HSDISCON_LEVEL: HS disconnect detector level. These registers exist in Tegra20, but programming them hasn't been necessary, so these parameters won't be set on Tegra20 to keep the device trees backward compatible. Additionally, the UTMIP_XCVR_SETUP parameter can be set from fuses instead of a software-programmed value, as the optimal value can vary between invidual boards. The boolean property nvidia,xcvr-setup-use-fuses can be used to enable this behaviour. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-12usb: phy: tegra: Tegra30 supportTuomas Tynkkynen1-27/+92
The Tegra30 USB PHY is a bit different than the Tegra20 PHY: - The EHCI controller supports the HOSTPC register extension, and some of the fields that the PHY needs to modify (PHCD and PTS) have moved to the new HOSTPC register. - Some of the UTMI PLL configuration registers have moved from the USB register space to the Clock-And-Reset controller space. In Tegra30 the clock driver is responsible for configuring the UTMI PLL. - The USBMODE register must be explicitly written to enter host mode. - Certain PHY parameters need to be programmed for optimal signal quality. Support for this will be added in the next patch. The new tegra_phy_soc_config structure is added to describe the differences between the SoCs. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-12usb: phy: tegra: Fix wrong PHY parametersTuomas Tynkkynen1-6/+14
Some of the PHY parameters are not set according to the TRMs: - UTMIP_FS_PREABMLE_J should be set, not cleared - UTMIP_XCVR_LSBIAS_SEL should be cleared, not set - UTMIP_PD_CHRG should be set in host mode and cleared in device mode - UTMIP_XCVR_SETUP is a two-part field; the upper bits were not set properly Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-12usb: host: add has_tdi_phy_lpm capability bitTuomas Tynkkynen3-7/+9
The has_hostpc capability bit indicates that the host controller has the HOSTPC register extensions, but at the same time enables clock disabling power saving features with the PHY Low Power Clock Disable (PHCD) bit. However, some host controllers have the HOSTPC extensions but don't support the low-power feature, so the PHCD bit must not be set on those controllers. Add a separate capability bit for the low-power feature instead, and change all existing users of has_hostpc to use this new capability bit. The idea for this commit is taken from an old 2012 commit that never got merged ("disociate chipidea PHY low power suspend control from hostpc") Inspired-by: Matthieu CASTET <matthieu.castet@parrot.com> Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: gadget: uvc: Fix error handling in uvc_queue_buffer()Laurent Pinchart1-1/+5
The conversion to videobuf2 failed to check the return value of vb2_qbuf(). Fix it. Cc: stable@vger.kernel.org Reported-by: Michael Grzeschik <mgr@pengutronix.de> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-By: Michael Grzeschik <mgr@pengutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: musb dma: add cppi41 dma driverSebastian Andrzej Siewior4-1/+558
This driver is currently used by musb' cppi41 couter part. I may merge both dma engine user of musb at some point but not just yet. The driver seems to work in RX/TX mode in host mode, tested on mass storage. I increaed the size of the TX / RX transfers and waited for the core code to cancel a transfers and it seems to recover. v2..3: - use mall transfers on RX side and check data toggle. - use rndis mode on tx side so we haveon interrupt for 4096 transfers. - remove custom "transferred" hack and use dmaengine_tx_status() to compute the total amount of data that has been transferred. - cancel transfers and reclaim descriptors v1..v2: - RX path added - dma mode 0 & 1 is working - device tree nodes re-created. Cc: Vinod Koul <vinod.koul@intel.com> Cc: Dan Williams <djbw@fb.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: musb: dsps: use proper child nodesSebastian Andrzej Siewior4-156/+159
This moves the two instances from the big node into two child nodes. The glue layer ontop does almost nothing. There is one devices containing the control module for USB (2) phy, (2) usb and later the dma engine. The usb device is the "glue device" which contains the musb device as a child. This is what we do ever since. The new file musb_am335x is just here to prob the new bus and populate child devices. There are a lot of changes to the dsps file as a result of the changes: - musb_core_offset This is gone. The device tree provides memory ressources information for the device there is no need to "fix" things - instances This is gone as well. If we have two instances then we have have two child enabled nodes in the device tree. For instance the SoC in beagle bone has two USB instances but only one has been wired up so there is no need to load and init the second instance since it won't be used. - dsps_glue is now per glue device In the past there was one of this structs but with an array of two and each instance accessed its variable depending on the platform device id. - no unneeded copy of structs I do not know why struct dsps_musb_wrapper is copied but it is not necessary. The same goes for musb_hdrc_platform_data which allocated on demand and then again by platform_device_add_data(). One copy is enough. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: musb: dsps: remove the hardcoded phy piecesSebastian Andrzej Siewior1-96/+1
dsps uses a nop driver which is added in dsps itself and does the PHY on/off calls within dsps. Since those calls are now moved the nop driver itself, we can now request the phy proper phy and remove those calls. Currently only the first musb interface is used so we only add one phy node for now. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: phy: Add AM335x PHY driverSebastian Andrzej Siewior5-0/+270
This driver is a redo of my earlier attempt. It uses parts of the generic PHY driver and uses the new control driver for the register the phy needs to power on/off the phy. It also enables easy access for the wakeup register which is not yet implemented. The difference between the omap attempt is: - no static holding variable - one global visible function which exports a struct with callbacks to access the "control" registers. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: phy: phy-generic: export init functionsSebastian Andrzej Siewior2-58/+94
This patch exports the mostly generic functions so they can be used from other phy driver instead of duplicating the code. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09Merge branch 'nop-phy-rename' into nextFelipe Balbi10-37/+37
Signed-off-by: Felipe Balbi <balbi@ti.com> Conflicts: drivers/usb/phy/phy-generic.c
2013-08-09usb: phy: rename nop_usb_xceiv => usb_phy_gen_xceivSebastian Andrzej Siewior10-37/+37
The "nop" driver isn't a do-nothing-stub but supports a couple functions like clock on/off or is able to use a voltage regulator. This patch simply renames the driver to "generic" since it is easy possible to extend it by a simple function istead of writing a complete driver. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: phy: mv-usb: remove incorrect __exit_p annotationJingoo Han1-2/+2
When platform_driver_probe() is not used, bind/unbind via sysfs is enabled. Thus, __exit_p annotation should be removed from remove(). Also, mv_otg_remove() is staticized, because this function is used only in this file. Fix the following sparse warning: drivers/usb/phy/phy-mv-usb.c:656:5: warning: symbol 'mv_otg_remove' was not declared. Should it be static? Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: phy: mv-u3d: Staticize mv_u3d_phy_shutdown()Jingoo Han1-1/+1
mv_u3d_phy_shutdown() is used only in this file. Fix the following sparse warning: drivers/usb/phy/phy-mv-u3d-usb.c:85:6: warning: symbol 'mv_u3d_phy_shutdown' was not declared. Should it be static? Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: gadget: f_uac1: Staticize local functionsJingoo Han1-2/+2
control_selector_init() is used only in this file. audio_bind_config() is used only in audio.c file to which f_uac1.c is included. Thus, these functions are staticized to fix the following warnings. drivers/usb/gadget/f_uac1.c:698:12: warning: symbol 'control_selector_init' was not declared. Should it be static? drivers/usb/gadget/f_uac1.c:722:12: warning: symbol 'audio_bind_config' was not declared. Should it be static? Acked-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: gadget: u_uac1: add __user annotationJingoo Han1-1/+1
Added __user annotation to fix the following sparse warning. drivers/usb/gadget/u_uac1.c:194:52: warning: incorrect type in argument 2 (different address spaces) drivers/usb/gadget/u_uac1.c:194:52: expected void const [noderef] <asn:1>*buf drivers/usb/gadget/u_uac1.c:194:52: got void *buf Acked-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: gadget: rndis: Staticize rndis_init()/rndis_exit()Jingoo Han1-2/+2
rndis_init() and rndis_exit() are used only in this file. Fix the following sparse warnings: drivers/usb/gadget/rndis.c:1145:5: warning: symbol 'rndis_init' was not declared. Should it be static? drivers/usb/gadget/rndis.c:1179:6: warning: symbol 'rndis_exit' was not declared. Should it be static? Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: gadget: f_mass_storage: use NULL instead of 0Jingoo Han1-3/+3
The local variables such as 'filename', 'vendor_name', and 'product_name' are pointers; thus, use NULL instead of 0 to fix the following sparse warnings drivers/usb/gadget/f_mass_storage.c:3046:27: warning: Using plain integer as NULL pointer drivers/usb/gadget/f_mass_storage.c:3050:28: warning: Using plain integer as NULL pointer drivers/usb/gadget/f_mass_storage.c:3051:29: warning: Using plain integer as NULL pointer Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-09usb: gadget: amd5536udc: unconditionally use GFP_ATOMIC in udc_queue()Alexey Khoroshilov1-2/+2
As far as prep_dma() is called with spinlock held, we have to pass GFP_ATOMIC regardless of gfp argument. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-05Merge 3.11-rc4 into usb-nextGreg Kroah-Hartman14-91/+223
We want those fixes in here also. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-05usb: dwc3: use extcon fwrk to receive connect/disconnectKishon Vijay Abraham I2-19/+107
Modified dwc3-omap to receive connect and disconnect notification using extcon framework. Also did the necessary cleanups required after adapting to extcon framework. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
2013-08-03usb: fix some scripts/kernel-doc warningsYacine Belkadi9-83/+165
When building the htmldocs (in verbose mode), scripts/kernel-doc reports the following type of warnings: Warning(drivers/usb/core/usb.c:76): No description found for return value of 'usb_find_alt_setting' Fix them by: - adding some missing descriptions of return values - using "Return" sections for those descriptions Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02usb: gadget: at91_udc: add usb_clk for transition to common clk frameworkBoris BREZILLON2-3/+16
The AT91 PMC (Power Management Controller) provides an USB clock used by USB Full Speed host (ohci) and USB Full Speed device (udc). The usb drivers (ohci and udc) must configure this clock to 48Mhz. This configuration was formely done in mach-at91/clock.c, but this implementation will be removed when moving to common clk framework. This patch adds support for usb clock retrieval and configuration, and is backward compatible with the current at91 clk implementation (if usb clk is not found, it does not configure/enable it). Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-02usb: gadget: at91_udc: add missing clk_put on fclk and iclkBoris BREZILLON1-0/+4
This patch adds missing clk_put on fclk and iclk in case the probe function fails after these clocks have been retrieved. Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-02usb: gadget: fusb300_udc: Staticize fusb300_rdcxf()Jingoo Han1-1/+1
fusb300_rdcxf() used only in this file. Fix the following sparse warning: drivers/usb/gadget/fusb300_udc.c:560:6: warning: symbol 'fusb300_rdcxf' was not declared. Should it be static? Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-02usb: gadget: goku_udc: use NULL instead of 0Jingoo Han1-1/+1
'req' is a pointer; thus, use NULL instead of 0 to fix the following sparse warning: drivers/usb/gadget/goku_udc.c:775:13: warning: Using plain integer as NULL pointer Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-02usb: dwc3: pci: add CONFIG_PM_SLEEP to suspend/resume functionsJingoo Han1-7/+3
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 SET_SYSTEM_SLEEP_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. Unnecessary CONFIG_PM ifdefs are removed. drivers/usb/dwc3/dwc3-pci.c:215:12: warning: 'dwc3_pci_suspend' defined but not used [-Wunused-function] drivers/usb/dwc3/dwc3-pci.c:224:12: warning: 'dwc3_pci_resume' defined but not used [-Wunused-function] Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-08-02USB: ohci-at91: add usb_clk for transition to common clk frameworkBoris BREZILLON1-2/+21
The AT91 PMC (Power Management Controller) provides an USB clock used by USB Full Speed host (ohci) and USB Full Speed device (udc). The usb drivers (ohci and udc) must configure this clock to 48Mhz. This configuration was formely done in mach-at91/clock.c, but this implementation will be removed when moving to common clk framework. This patch adds support for usb clock retrieval and configuration, and is backward compatible with the current at91 clk implementation (if usb clk is not found, it does not configure/enable it). Changes since v1: - use IS_ENABLED(CONFIG_COMMON_CLK) to isolate new at91 clk support Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02USB: EHCI: don't depend on hardware for tracking port resets and resumesAlan Stern1-33/+25
In theory, an EHCI controller can turn off the PORT_RESUME or PORT_RESET bits in a port status register all by itself (and some controllers actually do this). We shouldn't depend on these bits being set correctly. This patch rearranges the code in ehci-hcd that handles completion of port resets and resumes. We guarantee that ehci->reset_done[portnum] is nonzero if a reset or resume is in progress, and that the portnum bit is set in ehci->resuming_ports if the operation is a resume. (To help enforce this guarantee, the patch prevents suspended ports from being reset.) Therefore it's not necessary to look at the port status bits to learn what's going on. The patch looks bigger than it really is, because it changes the indentation level of a sizeable region of code. Most of what it actually does is interchange some tests. The only functional changes are testing reset_done and resuming_ports rather than PORT_RESUME and PORT_RESET, removing a now-unnecessary check for spontaneous resets of the PORT_RESUME and PORT_RESET bits, and preventing a suspended or resuming port from being reset. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-02USB: EHCI: keep better track of resuming portsAlan Stern1-1/+2
The ehci-hcd driver isn't as careful as it should be about the way it uses ehci->resuming_ports. One of the omissions was fixed recently by commit 47a64a13d54 (USB: EHCI: Fix resume signalling on remote wakeup), but there are other places that need attention: When a port's suspend feature is explicitly cleared, the corresponding bit in resuming_ports should be set and the core should be notified about the port resume. We don't need to clear a resuming_ports bit when a reset completes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31USB: pl2303: restrict the divisor based baud rate encoding method to the "HX" chip typeFrank Schäfer1-1/+5
It's not clear if the type_0 and type_1 chips support the divisor based baud rate encoding method, so don't use it until anyone with such chip has tested it to avoid regressions with the following patches. Even if it has been working fine with these chips since the code has been added 2 years ago, this change will not cause any regressions, because the baud rates currently supported/allowed with the divisor based method are supported with the direct method, too. The code for the divisor based method also isn't entirely correct (yet), so that the direct encoding method actually works better (sets the baud rate more precisely). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31USB: host: use dev_get_platdata()Jingoo Han26-64/+65
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31USB: handle LPM errors during device suspend correctlyAlan Stern1-22/+26
The hub driver's usb_port_suspend() routine doesn't handle errors related to Link Power Management properly. It always returns failure, it doesn't try to clean up the wakeup setting, (in the case of system sleep) it doesn't try to go ahead with the port suspend regardless, and it doesn't try to apply the new power-off mechanism. This patch fixes these problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31USB: refactor code for enabling/disabling remote wakeupAlan Stern1-52/+46
The hub driver is inconsistent in its organization of code for enabling and disabling remote wakeup. There is a special routine to disable wakeup for SuperSpeed devices but not for slower devices, and there is no special routine to enable wakeup. This patch refactors the code. It renames and changes the existing function to make it handle both SuperSpeed and non-SuperSpeed devices, and it adds a corresponding routine to enable remote wakeup. It also changes the speed determination to look at the device's speed rather than the speed of the parent hub -- this shouldn't make any difference because a SuperSpeed device always has to be attached to a SuperSpeed hub and conversely. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31USB: simplify the interface of usb_get_status()Alan Stern3-17/+15
This patch simplifies the interface presented by usb_get_status(). Instead of forcing callers to check for the proper data length and convert the status value to host byte order, the function will now do these things itself. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31usb: misc: usb3503: use dev_get_platdata()Jingoo Han1-1/+1
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31usb: renesas: use dev_get_platdata()Jingoo Han1-2/+2
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31USB: c67x00: use dev_get_platdata()Jingoo Han1-2/+2
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31usb: core: don't try to reset_device() a port that got just disconnectedJulius Werner1-2/+3
The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() function based on whether there was a device attached to the port. However, there are device/hub combinations (found with a JetFlash Transcend mass storage stick (8564:1000) on the root hub of an Intel LynxPoint PCH) which can transition to the SS.Inactive state on disconnect (and stay there long enough for the host to notice). In this case, above-mentioned reset check will call usb_reset_device() on the stale device data structure. The kernel will send pointless LPM control messages to the no longer connected device address and can even cause several 5 second khubd stalls on some (buggy?) host controllers, before finally accepting the device's fate amongst a flurry of error messages. This patch makes the choice of reset dependent on the port status that has just been read from the hub in addition to the existence of an in-kernel data structure for the device, and only proceeds with the more extensive reset if both are valid. Signed-off-by: Julius Werner <jwerner@chromium.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-31usb: xhci: add missing dma-mapping.h includesJames Hogan2-0/+2
A randconfig build hit the following build errors because xhci.c and xhci-mem.c use dma mapping functions but don't include <linux/dma-mapping.h>. Add the missing includes to fix the build errors. drivers/usb/host/xhci.c In function 'xhci_gen_setup': drivers/usb/host/xhci.c +4872 : error: implicit declaration of function 'dma_set_mask' drivers/usb/host/xhci.c +4872 : error: implicit declaration of function 'DMA_BIT_MASK' drivers/usb/host/xhci-mem.c In function 'xhci_free_stream_ctx': drivers/usb/host/xhci-mem.c +435 : error: implicit declaration of function 'dma_free_coherent' drivers/usb/host/xhci-mem.c In function 'xhci_alloc_stream_ctx': drivers/usb/host/xhci-mem.c +463 : error: implicit declaration of function 'dma_alloc_coherent' Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-07-31usb: core: don't try to reset_device() a port that got just disconnectedJulius Werner1-2/+3
The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() function based on whether there was a device attached to the port. However, there are device/hub combinations (found with a JetFlash Transcend mass storage stick (8564:1000) on the root hub of an Intel LynxPoint PCH) which can transition to the SS.Inactive state on disconnect (and stay there long enough for the host to notice). In this case, above-mentioned reset check will call usb_reset_device() on the stale device data structure. The kernel will send pointless LPM control messages to the no longer connected device address and can even cause several 5 second khubd stalls on some (buggy?) host controllers, before finally accepting the device's fate amongst a flurry of error messages. This patch makes the choice of reset dependent on the port status that has just been read from the hub in addition to the existence of an in-kernel data structure for the device, and only proceeds with the more extensive reset if both are valid. Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-07-31usb: dwc3: use dev_get_platdata()Felipe Balbi1-3/+3
Use the wrapper function for retrieving the platform_data instead of accessing dev->platform_data directly. While at that also make change 'node' initialization to use the dev pointer. Inspired-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-30aio: Kill aio_rw_vect_retry()Kent Overstreet1-3/+3
This code doesn't serve any purpose anymore, since the aio retry infrastructure has been removed. This change should be safe because aio_read/write are also used for synchronous IO, and called from do_sync_read()/do_sync_write() - and there's no looping done in the sync case (the read and write syscalls). Signed-off-by: Kent Overstreet <koverstreet@google.com> Cc: Zach Brown <zab@redhat.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Jens Axboe <axboe@kernel.dk> Cc: Asai Thambi S P <asamymuthupa@micron.com> Cc: Selvan Mani <smani@micron.com> Cc: Sam Bradshaw <sbradshaw@micron.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30aio: io_cancel() no longer returns the io_eventKent Overstreet1-2/+1
Originally, io_event() was documented to return the io_event if cancellation succeeded - the io_event wouldn't be delivered via the ring buffer like it normally would. But this isn't what the implementation was actually doing; the only driver implementing cancellation, the usb gadget code, never returned an io_event in its cancel function. And aio_complete() was recently changed to no longer suppress event delivery if the kiocb had been cancelled. This gets rid of the unused io_event argument to kiocb_cancel() and kiocb->ki_cancel(), and changes io_cancel() to return -EINPROGRESS if kiocb->ki_cancel() returned success. Also tweak the refcounting in kiocb_cancel() to make more sense. Signed-off-by: Kent Overstreet <koverstreet@google.com> Cc: Zach Brown <zab@redhat.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Jens Axboe <axboe@kernel.dk> Cc: Asai Thambi S P <asamymuthupa@micron.com> Cc: Selvan Mani <smani@micron.com> Cc: Sam Bradshaw <sbradshaw@micron.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30usb: renesas: use dev_get_platdata()Jingoo Han1-2/+2
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-30usb: musb: use dev_get_platdata()Jingoo Han10-19/+19
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-30usb: phy: use dev_get_platdata()Jingoo Han12-20/+22
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-30usb: gadget: use dev_get_platdata()Jingoo Han16-29/+29
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-29USB: serial: ftdi_sio: add more RT Systems ftdi devicesRick Farina (Zero_Chaos)2-8/+57
RT Systems makes many usb serial cables based on the ftdi_sio driver for programming various amateur radios. This patch is a full listing of their current product offerings and should allow these cables to all be recognized. Signed-off-by: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-29usb: host: Faraday fotg210-hcd driverFeng-Hsin Chiang5-0/+6813
FOTG210 is an OTG controller which can be configured as an USB2.0 host. FOTG210 host is an ehci-like controller with some differences. First, register layout of FOTG210 is incompatible with EHCI. Furthermore, FOTG210 is lack of siTDs which means iTDs are used for both HS and FS ISO transfer. Signed-off-by: Feng-Hsin Chiang <john453@faraday-tech.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>