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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NPingbo Wen <pingbo.wen@linaro.org>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add support for USB DRVVBUS pinctrl state change during
suspend/resume. This helps is conserving power during
system sleep.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

For ctrl out test, it needs length > vary, so in order to run it with
default parameters, we do this change.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The 'length' is the transfer length, not the packet size, so
change the help text.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NPeter Chen <peter.chen@freescale.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
(Fixed the 'line over 80 characters warning' by Peter Chen)
Tested-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Using the same data format "buf[j] = (u8)(i + j)" among
write, compare buf, and console output stage.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NMike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

struct at91_udc_data is now only used inside the driver, move it to its
include.
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NJohn Youn <johnyoun@synopsys.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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: NNikhil Badola <nikhil.badola@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>