- 27 Sep, 2015 40 commits
-
-
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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:
-
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:
-
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:
-
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:
-
Peter Chen authored
The 'length' is the transfer length, not the packet size, so change the help text. Acked-by:
-
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:
-
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:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Peter Chen authored
Using the same data format "buf[j] = (u8)(i + j)" among write, compare buf, and console output stage. Acked-by:
-
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: -
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:
-
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:
-
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:
-
Alexandre Belloni authored
struct at91_udc_data is now only used inside the driver, move it to its include. Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Felipe Balbi authored
this driver has long ago became dwc2.ko with both peripheral and host roles, there's no point in keeping the old function names. Acked-by:
-
Nikhil Badola authored
Add adjust_frame_length_quirk for writing to fladj register which adjusts (micro)frame length to value provided by "snps,quirk-frame-length-adjustment" property thus avoiding USB 2.0 devices to time-out over a longer run Signed-off-by:
Nikhil Badola <nikhil.badola@freescale.com> Signed-off-by:
-
Nikhil Badola authored
Add snps,quirk-frame-length-adjustment property which provides value for post silicon frame length adjustment Signed-off-by:
-
Ivan T. Ivanov authored
[un]register_interest and reading cable state by name have been deprecated. Switch to new API. Signed-off-by:
Ivan T. Ivanov <ivan.ivanov@linaro.org> Signed-off-by:
-
