aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* usb: dwc2: host: create a function to handle port_resumeGregory Herrero2015-10-01
| | | | | | | | | | | | | | | | | | | port resume sequence may be used in different places. Create a function to handle it. Make hprt0 read-modify-write atomic and clear HPRT0_SUSP for both writes as it is a "read, write-set, and self-clear (R_WS_SC)" bit. Since the lock is released between the writes, read hprt0 again. Since the phy clock is stopped in dwc2_port_suspend(), enable it here and remove the PCGCTL write from dwc2_hcd_hub_control() Signed-off-by: Gregory Herrero <gregory.herrero@intel.com> Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@intel.com> Tested-by: Robert Baldyga <r.baldyga@samsung.com> Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com> Tested-by: John Youn <johnyoun@synopsys.com> Acked-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: dwc2: host: don't clear hprt0 status bits when exiting hibernationGregory Herrero2015-10-01
| | | | | | | | | | | | | | When entering hibernation hprt0 must be read using dwc2_read_hprt0(). Otherwise, any set hprt0 status bits will be cleared when restoring hprt0 on exit from hibernation. Signed-off-by: Gregory Herrero <gregory.herrero@intel.com> Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@intel.com> Tested-by: Robert Baldyga <r.baldyga@samsung.com> Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com> Tested-by: John Youn <johnyoun@synopsys.com> Acked-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: dwc3: gadget: remove unnecessary _irqsave()Felipe Balbi2015-09-28
| | | | | | | | We *know* our threads executes with our IRQs disabled. We really don't need to use the _irqsave() variant of spin_lock(). Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: dwc3: gadget: use Update Transfer from Xfer In ProgressFelipe Balbi2015-09-28
| | | | | | | | Instead of limiting __dwc3_gadget_kick_transfer() to Xfer Complete, we can try to issue Update Transfer command from Xfer In Progress too. Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: dwc3: gadget: use update transfer commandFelipe Balbi2015-09-28
| | | | | | | | | | If we get a Xfer Not Ready event with reason "Transfer Active" it means endpoint is still transferring data and we can use that to issue update transfer for this particular endpoint in case we have pending requests in our queue. Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: dwc3: gadget: start transfer on XFER_COMPLETEFelipe Balbi2015-09-28
| | | | | | | | | | if by the time we get to XFER_COMPLETE we have pending requests to be processed, instead of waiting for a following XFER_NOT_READY, let's start the request right away and, maybe, save the time of a few NAKs due to lack of started transfers. Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: gadget: pch-udc: fix lockFelipe Balbi2015-09-28
| | | | | | | | gadget methods should be called without spinlocks held. Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: dwc3: pci: passing forward the ACPI companionHeikki Krogerus2015-09-27
| | | | | | | | Sharing the ACPI companion with dwc3 core so it has access to the properties defined for DWC3 in ACPI tables. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: dwc3: core: convert to unified device property interfaceHeikki Krogerus2015-09-27
| | | | | | | | | No functional affect on existing platforms, but the driver is now ready to extract the properties also from ACPI tables as well as from DT. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
* usb: common: of_usb_get_dr_mode to usb_get_dr_modeHeikki Krogerus2015-09-27
| | | | | | | | | 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>
* usb: dwc3: st: prepare the driver for generic usb_get_dr_mode functionHeikki Krogerus2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: common: of_usb_get_maximum_speed to usb_get_maximum_speedHeikki Krogerus2015-09-27
| | | | | | | | | 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>
* usb: phy: change some commentsPeter Chen2015-09-27
| | | | | | | | - 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>
* usb: gadget: legacy: tcm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: legacy: dbgp: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: u_serial: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: u_ether: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_uvc: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_uac2: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_uac1: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_subset: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_sourcesink: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_serial: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_rndis: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_printer: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_phonet: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_obex: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_ncm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_midi: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_mass_storage: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_loopback: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_hid: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_eem: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: f_acm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | | 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>
* usb: gadget: f_ecm: eliminate abuse of ep->driver dataRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: introduce 'enabled' flag in struct usb_epRobert Baldyga2015-09-27
| | | | | | | | | | | | | | 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>
* usb: gadget: epautoconf: add usb_ep_autoconfig_release() functionRobert Baldyga2015-09-27
| | | | | | | | | 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>
* usb: gadget: f_ncm: obtain cdev from function instead of driver_dataRobert Baldyga2015-09-27
| | | | | | | | | 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>
* usb: gadget: fix few outdated commentsRobert Baldyga2015-09-27
| | | | | | | | | | | | | 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>
* usb: gadget: dummy_hcd: replace timeval with timespec64WEN Pingbo2015-09-27
| | | | | | | | | | | 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>
* usb: dwc3: support for pinctrl state change during system sleepSekhar Nori2015-09-27
| | | | | | | | | 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>
* tools: usb: testusb: change the default value for length from 512 to 1024Peter Chen2015-09-27
| | | | | | | | | | 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>
* tools: usb: testusb: change the help textPeter Chen2015-09-27
| | | | | | | | | | 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>
* usb: gadget: f_sourcesink: format data pattern according to max packet sizePeter Chen2015-09-27
| | | | | | | | | | 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>
* usb: misc: usbtest: format the data pattern according to max packet sizeAlan Stern2015-09-27
| | | | | | | | | | | | | 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>
* usb: misc: usbtest: using the same data format among write/compare/outputPeter Chen2015-09-27
| | | | | | | | | 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>
* usb: misc: usbtest: delete useless memset for urbs arrayPeter Chen2015-09-27
| | | | | | | | | | | | | 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>
* usb: misc: usbtest: allocate size of urb array according to user parameterPeter Chen2015-09-27
| | | | | | | | | | 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>
* usb: dwc2: Use platform endianness when accessing registersAntti Seppälä2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | 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>
* usb: gadget: ether: Allow jumbo framesMike Looijmans2015-09-27
| | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-15 02:03:27 -0400