- 18 Jun, 2013 3 commits
-
-
Wei Yongjun authored
Add the missing unlock before return from function geth_alloc() in the error handling case. Introduced by commit 02832e56. (usb: gadget: f_subset: add configfs support) Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wei Yongjun authored
Add the missing unlock before return from function ncm_alloc() in the error handling case. Introduced by commit e7306603. (usb: gadget: f_ncm: add configfs support) Signed-off-by:
-
Wei Yongjun authored
Add the missing unlock before return from function ecm_alloc() in the error handling case. Introduced by commit da92801c. (usb: gadget: f_ecm: add configfs support) Signed-off-by:
-
- 17 Jun, 2013 37 commits
-
-
Emil Goode authored
This patch removes a double assignment of .start in struct hc_driver ehci_msp_hc_driver and also makes the code look more tidy. Signed-off-by:
Emil Goode <emilgoode@gmail.com> Signed-off-by:
-
Roger Quadros authored
For PHY mode, the PHYs must be brought out of reset before the EHCI controller is started. This patch fixes the issue where USB devices are not found on Beagleboard/Beagle-xm if USB has been started previously by the bootloader. (e.g. by "usb start" command in u-boot) Tested on Beagleboard, Beagleboard-xm and Pandaboard. Issue present on 3.10 onwards. Reported-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by:
Roger Quadros <rogerq@ti.com> Cc: stable <stable@vger.kernel.org> # 3.10 Signed-off-by:
-
Thierry Reding authored
Under some circumstances it happens that the connected PHY can't be powered up properly, in which case the cleanup path currently crashes because it checks the tegra->transceiver field using !IS_ERR(), which will succeed because it is in fact NULL. Dereferencing that pointer causes an oops in tegra_ehci_probe(). This patch fixes the issue by adding an additional label into the cleanup path to separately take down the PHY and the transceiver. Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Reviewed-by:
Stephen Warren <swarren@nvidia.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Stephen Warren authored
Rather than allocating struct tegra_ehci_hcd separately, use struct ehci_hcd's priv field instead. Signed-off-by:
-
Manjunath Goudar authored
Separate the Tegra on-chip host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM. Signed-off-by:
Manjunath Goudar <manjunath.goudar@linaro.org> [swarren, reworked Manjunath's patches to split them more logically, minor re-order of added lines to better match layout of other split-up HCD drivers and existing code, add MODULE_DEVICE_TABLE, fix MODULE_LICENSE, adapted to change in earlier patches which removed the ehci_driver_overrides addition, removed all PM code and solved circular dependencies.] Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Stephen Warren authored
The Tegra EHCI driver directly calls various functions in the Tegra USB PHY driver. The reverse is also true; the PHY driver calls into the EHCI driver. This is problematic when the two are built as modules. The calls from the PHY to EHCI driver were originally added in commit bbdabdb6 "usb: add APIs to access host registers from Tegra PHY", for the following reasons: 1) The register being touched is an EHCI register, so logically only the EHCI driver should touch it. 2) (1) implies that some locking may be needed to correctly implement the r/m/w access to this shared register. 3) We were expecting to pass only the PHY register space to the Tegra PHY driver, and hence it would not have access to touch the shared registers. To solve this, that commit added functions in the EHCI driver to touch the shared register on behalf of the PHY driver. In practice, we ended up not having any locking in the implementaiton of those functions, and I've been led to believe this is safe. Equally, (3) did not happen either. Hence, it is possible for the PHY driver to touch the shared register directly. Given that, this patch moves the code to touch the shared register back into the PHY driver, to eliminate the module problems. If we actually need locking or co-ordination in the future, I propose we put the lock support into some pre-existing core module, or into a third separate module, in order to avoid the circular dependencies. I apologize for my contribution to code churn here. Signed-off-by:
-
Stephen Warren authored
The PM routines in ehci-tegra.c use APIs such as ehci_reset(), ehci_halt(), and ehci_tdi_reset() that would need to be exported to convert ehci-tegra.c into a separate module from ehci-hcd.c. However, we'd prefer not to export them. Instead, simply remove all power management functionality. Runtime PM was disabled since it didn't work correctly, and system suspend isn't yet supported in a meaningful way. So, this change doesn't lose any functionality. Hopefully the power management logic can be reimplemented in a cleaner way in the future. Signed-off-by:
-
Manjunath Goudar authored
In order to split ehci-hcd.c into separate modules, handshake() must be exported. Rename the symbol to add an ehci_ prefix, to avoid any naming clashes. Signed-off-by:
-
Stephen Warren authored
When this file is built as a module, it needs a MODULE_LICENSE in order to access many exported symbols. Signed-off-by:
Felipe Balbi <balbi@ti.com> Tested-by:
-
Manjunath Goudar authored
In order to build a ULPI PHY driver as a module, this symbol needs to be exported. Signed-off-by:
-
Alexander Shishkin authored
Since someone has added camelcase detection to checkpatch.pl, chipidea udc patches have been very noisy. To make everybody's life easier, this patch changes camelcase names into something more appropriate to the coding style. No functional changes. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
This patch makes error path cleaner and probe function tidier. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
As drvdata is cleared to NULL at probe failure or at removal by the driver core, we don't have to call pci_set_drvdata(pci, NULL) any longer in each driver. Signed-off-by:
-
Sascha Hauer authored
This patch converts the driver to use devm_usb_get_phy_by_phandle which makes the code smaller and a bit simpler. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
This patch converts the driver to use the module_platform_driver macro which makes the code smaller and a bit simpler. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Michael Grzeschik <mgr@pengutronix.de> Signed-off-by:
-
Michael Grzeschik authored
The pdata structure gets copied anyway inside ci13xxx_add_device by platform_device_add. We don't need to have it static. Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Sascha Hauer authored
Even if a chipidea core is otg capable the board may not be. This allows to explicitly set the core to host/peripheral mode. Without these flags the driver falls back to the old behaviour. Signed-off-by:
-
Michael Grzeschik authored
This patch makes it possible to configure the PTW, PTS and STS bits inside the portsc register for host and device mode before the driver starts and the phy can be addressed as hardware implementation is designed. Signed-off-by:
-
Michael Grzeschik authored
This adds two little devicetree helper functions for determining the dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from the devicetree. Signed-off-by:
-
Michael Grzeschik authored
This patch removes the restriction of having a limited amount of only four active tds on one endpoint. We use the linked list implementation to manage all tds which get added and removed by hardware_{en,de}queue. The removal of this restriction adds the driver to run into a hardware errata. It's possible that the hardware will still address an transfer descriptor that already got cleaned up. To solve this the patch also postpone the cleanup of processed tds by one. Signed-off-by: -
Michael Grzeschik authored
Instead of having a limited number of usable tds in the udc we use a linked list to support dynamic amount of needed tds for all special gadget types. This improves throughput. Signed-off-by:
-
Peter Chen authored
Randy Dunlap <rdunlap@infradead.org> reported this problem on i386: > drivers/built-in.o: In function `ci_hdrc_host_init': > (.text+0x2ce75c): undefined reference to `ehci_init_driver' > > When USB_EHCI_HCD=m and USB_CHIPIDEA=y. In fact, this problem is existed on all platforms which are using chipidea driver. The root cause of this problem is the chipidea host uses symbol exported from ehci-hcd, but chipidea core does not depends on USB_EHCI_HCD. So, chipidea driver will not be compiled as module if USB_EHCI_HCD=m. It is very hard to give a perfect solution since chipidea core depends on USB || USB_GADGET, and chipdiea host depends on both USB_EHCI_HCD and USB_CHIPIDEA, the same problem exists for gadget. To fix this problem, we had to have below assumptions: - If USB_EHCI_HCD=y && USB_GADGET=y, USB_CHIPIDEA can be 'y'. - If USB_EHCI_HCD=m && USB_GADGET=y, USB_CHIPIDEA=m or USB_CHIPIDEA_HOST can't be seen if USB_CHIPIDEA=y. It will cause compile error due to no glue layer for ehci: > error: #error "missing bus glue for ehci-hcd" So, we had to compile USB_CHIPIDEA=m if USB_EHCI_HCD=m, current ehci hcd core guarantee it. - If USB_EHCI_HCD=y && USB_GADGET=m, USB_CHIPIDEA=m or USB_CHIPIDEA_UDC can't be seen if USB_CHIPIDEA=y. Of cos, the gadget will out of working at this situation, so the user had to compile USB_CHIPIDEA=m. - USB_EHCI_HCD=m && USB_GADGET=m, we can't see USB_CHIPIDEA_HOST and USB_CHIPIDEA_UDC unless USB_CHIPIDEA=m. The reason why it has above assumptions: - If both ehci core and gadget core build as module, the chipidea has to build as module. - If one of ehci core or gadget core is built in, another is built as module, we can only enable the function which is built in, or enable both roles as modules (USB_CHIPIDEA=m), since chipidea core driver takes care of both host and device roles. Signed-off-by:
-
Fabio Estevam authored
There is no need to keep a local 'phy_np' as we can directly use the private structure in data->phy_np. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Fabio Estevam authored
Similarly as it is done in ci13xxx_imx_remove(), only calls of_node_put if data->phy_np is not NULL. Signed-off-by:
-
Fabio Estevam authored
There is no need to keep a 'reg_vbus' indirection, so get rid of it. The motivation for doing this change is that in the case of error, the current code only sets the local reg_vbus to NULL instead of updating the private structure 'data->reg_vbus'. Updating only the local reg_vbus is wrong, since we currently check for data->reg_vbus in the ci13xxx_imx_remove() function. In order to avoid such issue, just use 'data->reg_vbus' directly. Signed-off-by:
-
Fabio Estevam authored
If usbmisc_ops->post() fails it should point the error path to release all previously acquired resources, so adjust it to call ci13xxx_remove_device(). While at it, remove the unnecessary 'plat_ci' indirection, as we can directly use the private structure. Signed-off-by:
-
Michael Grzeschik authored
This patch adds iso endpoint support to the device controller. It makes use of the multiplication bits in the maxpacket field of the endpoint and calculates the multiplier bits for each transfer description on every request. Signed-off-by:
-
Fabio Estevam authored
Fix the following sparse warnings: drivers/usb/chipidea/usbmisc_imx.c:246:5: warning: symbol 'usbmisc_imx_drv_init' was not declared. Should it be static? drivers/usb/chipidea/usbmisc_imx.c:252:6: warning: symbol 'usbmisc_imx_drv_exit' was not declared. Should it be static? Signed-off-by:
-
Fabio Estevam authored
Since commit ab78029e (drivers/pinctrl: grab default handles from device core), we can rely on device core for handling pinctrl. So remove devm_pinctrl_get_select_default() from the driver. Cc: <linux-usb@vger.kernel.org> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Thomas Pugliese authored
This patch adds support for scatter gather DMA to the wire adapter and updates the HWA to advertise support for SG transfers. This allows the block layer to submit transfer requests to the HWA HC without first breaking them up into PAGE_SIZE requests. Signed-off-by:
Thomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by:
-
Andrzej Pietrasiewicz authored
Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Acked-by:
-
Andrzej Pietrasiewicz authored
Add documentation for configfs-based usb gadget. Signed-off-by:
-
Andrzej Pietrasiewicz authored
USB_CONFGFS_ZZZZ should appear under a tristate option in order to allow selecting more than one function without building the legacy gadgets. Now there are two problems: 1) they can't be selected at all, because they depend on USB_CONFIGFS, and the patch which adds USB_CONFIGFS has not been merged. 2) they don't select USB_LIBCOMPOSITE (which they need but which is selected by USB_CONFIGFS) Signed-off-by:
-
Tushar Behera authored
Commit 75096579 ("lib: devres: Introduce devm_ioremap_resource()") introduced devm_ioremap_resource() and deprecated the use of devm_request_and_ioremap(). Signed-off-by:
Tushar Behera <tushar.behera@linaro.org> CC: linux-usb@vger.kernel.org CC: Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Greg Kroah-Hartman authored
When writing data we were: lock do some work unlock call function lock do some work unlock return return It turns out, that "function" was only ever called in the one place, so instead of locking/unlocking for no good reason, just inline the function and only grab the lock once. This has sped up the pathological case of sending 1 byte packets to a loop-back cdc-acm device from 49600 bytes per second to 50100 bytes a second on my workstation. A tiny increase yes, but noticable, and now the spinlock isn't the hottest thing on the perf graph anymore. Yes, we are still waiting for the hardware for the most part, but getting rid of a spinlock_irq_save() call for every packet is still a good thing. And we end up deleting lines of code, always a win overall. This was found by using a Teensy 3.0 device and the test program and firmware located at: http://www.pjrc.com/teensy/benchmark_usb_serial_receive.htmlReported-by:
Paul Stoffregen <paul@pjrc.com> Signed-off-by:
-
Greg Kroah-Hartman authored
We had the limit of 255 USB to serial devices on one system for almost 15 years, with no complaints. But now it's time to move on from these tiny "baby" systems, and bump the number up to 512, which should last us a few more years: "512 is a nice number" -- Tobias Winter Note, this is still a static value, and uses up tty core memory with this many tty devices allocated. Converting the driver to use TTY_DRIVER_DYNAMIC_DEV is the next thing to do in order to remove this limitation. Reported-by:
Tobias Winter <tobias@linuxdingsda.de> Tested-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This moves the allocation of minor device numbers from a static array to be dynamic, using the idr interface. This means that you could potentially get "gaps" in a minor number range for a single USB serial device with multiple ports, but all should still work properly. We remove the 'minor' field from the usb_serial structure, as it no longer makes any sense for it (use the field in the usb_serial_port structure if you really want to know this number), and take the fact that we were overloading a number in this field to determine if we had initialized the minor numbers or not, and just use a flag variable instead. Note, we still have the limitation of 255 USB to serial devices in the system, as that is all we are registering with the TTY layer at this point in time. Tested-by:
-
