- 27 Sep, 2015 40 commits
-
-
Heikki Krogerus authored
of_usb_get_dr_mode will be converted into more generic usb_get_dr_mode function that will take struct device instead of struct device_node as its parameter. To make the conversion possible later, waiting for the platform device for dwc3 to be populated before calling of_usb_get_dr_mode. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> CC: Giuseppe Cavallaro <peppe.cavallaro@st.com> CC: Peter Griffin <peter.griffin@linaro.org> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Heikki Krogerus authored
By using the unified device property interface, the function can be made available for all platforms and not just the ones using DT. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
- Replace all "transceiver" with "phy" - Replace one "OTG controller" with "phy" Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of tcm, ep->driver_data was used only for endpoint claiming so we can simplify code by reducing it. We also remove give_back_ep() function which is not needed after all - when error code is returned from bind() function, composite will release all endpoints anyway. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of dbgp, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of u_serial ep->driver_data stores pointer to struct gs_port, which is referenced in many places in code. Code using ep->driver_data to mark endpoint as enabled/disabled has been removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of u_ether we only need to store in ep->driver_data pointer to struct eth_dev, as it's used in rx_complete() and tx_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uvc, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uac2, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uac1, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_subset, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_sourcesink we only need to store in ep->driver_data pointer to struct f_sourcesink, as it's used in source_sink_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_serial, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_rndis, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_printer we only need to store in ep->driver_data pointer to struct printer_dev, as it's used in rx_complete() and tx_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_phonet we only need to store in ep->driver_data pointer to struct f_phonet, as it's used in pn_tx_complete() and pn_rx_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_obex, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ncm, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_midi we only need to store in ep->driver_data pointer to struct f_midi, as it's used in f_midi_complete() callback and related functions. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_mass_storage we only need to store in ep->driver_data pointer to struct fsg_common, which is used in bulk_in_complete() and bulk_out_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_hid we only need to store in ep->driver_data pointer to struct f_loopback, as it's used in loopback_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_hid we only need to store in ep->driver_data pointer to struct f_hidg, as it's used in f_hidg_req_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ecm, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_acm we only need to store in ep->driver_data pointer to struct f_acm, as it's used in acm_complete_set_line_coding() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ecm, ep->driver_data was used only for endpoint claiming and marking endpoints as enabled, so we can simplify code by reducing it. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
This patch introduces 'enabled' flag in struct usb_ep, and modifies usb_ep_enable() and usb_ep_disable() functions to encapsulate endpoint enabled/disabled state. It helps to avoid enabling endpoints which are already enabled, and disabling endpoints which are already disables. From now USB functions don't have to remember current endpoint enable/disable state, as this state is now handled automatically which makes this API less bug-prone. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
This patch introduces usb_ep_autoconfig_release() function which allows to release endpoint previously obtained from usb_ep_autoconfig() during USB function bind. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
The 'driver_data' field in ep0 is never set to pointer to cdev, so we have to obtain it from another source as in this context ep->driver_data contains invalid data. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Robert Baldyga authored
Fix comments in code to make them up to date. composite: claiming endpoint is now done by setting ep->claimed flag, not ep->driver_data. epautoconf: usb_ep_autoconfig() and usb_ep_autoconfig_ss() return claimed endpoint with ep->claimed flag already set. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
WEN Pingbo authored
The millisecond of the last second will be normal if tv_sec is overflowed. But for y2038 consistency and demonstration purpose, and avoiding further risks, we need to remove 'timeval' in this driver, to avoid similair problems. Signed-off-by:
Pingbo Wen <pingbo.wen@linaro.org> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Sekhar Nori authored
Add support for USB DRVVBUS pinctrl state change during suspend/resume. This helps is conserving power during system sleep. Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
For ctrl out test, it needs length > vary, so in order to run it with default parameters, we do this change. Acked-by:
Michal Nazarewicz <mina86@mina86.com> Cc: Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The 'length' is the transfer length, not the packet size, so change the help text. Acked-by:
Michal Nazarewicz <mina86@mina86.com> Cc: Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
Since the host and gadget can't agree with transfer length before each transfer, but they agree with max packet size for each endpoint, we use max packet size to format data pattern. Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Alan Stern authored
With this change, the host and gadget doesn't need to agree with transfer length for comparing the data, since they doesn't know each other's transfer size, but know max packet size. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Acked-by:
Michal Nazarewicz <mina86@mina86.com> (Fixed the 'line over 80 characters warning' by Peter Chen) Tested-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
Using the same data format "buf[j] = (u8)(i + j)" among write, compare buf, and console output stage. Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The element of urbs array will be initialized at below code at once. for (i = 0; i < param->sglen; i++) { urbs[i] = iso_alloc_urb(udev, pipe, desc, param->length, offset); Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
Allocate the size of urb pointer array according to testusb's parameter sglen, and limits the length of sglen as MAX_SGLEN (128 currently). Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Antti Seppälä authored
This patch switches calls to readl/writel to their dwc2_readl/dwc2_writel equivalents which preserve platform endianness. This patch is necessary to access dwc2 registers correctly on big-endian systems such as the mips based SoCs made by Lantiq. Then dwc2 can be used to replace ifx-hcd driver for Lantiq platforms found e.g. in OpenWrt. The patch was autogenerated with the following commands: $EDITOR core.h sed -i "s/\<readl\>/dwc2_readl/g" *.c hcd.h hw.h sed -i "s/\<writel\>/dwc2_writel/g" *.c hcd.h hw.h Some files were then hand-edited to fix checkpatch.pl warnings about too long lines. Signed-off-by:
Antti Seppälä <a.seppala@gmail.com> Signed-off-by:
Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by:
John Youn <johnyoun@synopsys.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Mike Looijmans authored
USB network adapters support Jumbo frames. The only thing blocking that feature is the code in the gadget driver that disposes of packets larger than 1518 bytes, and the limit on the ioctl to set the mtu. This patch relaxes these limits, and allows up to 15k frames sizes. The 15k value was chosen because 16k does not work on all platforms, and usingclose to 16k will result in allocating 5 or 8 4k pages to store the skb, wasting pages at no measurable performance gain. On a topic-miami board (Zynq-7000), iperf3 performance reports: MTU= 1500, PC-to-gadget: 139 Mbps, Gadget-to-PC: 116 Mbps MTU=15000, PC-to-gadget: 239 Mbps, Gadget-to-PC: 361 Mbps On boards with slower CPUs the performance improvement will be relatively much larger, e.g. an OMAP-L138 increased from 40 to 220 Mbps using a similar patch on an 2.6.37 kernel. Signed-off-by:
Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-