While building allmodconfig on avr32 the build failed with the error:
"at91_pmc_base" [drivers/usb/gadget/udc/atmel_usba_udc.ko] undefined!
On checking the code it turned out that if CONFIG_OF is defined then it
is using at91_pmc_read() which is using at91_pmc_base. And unless
COMMON_CLK_AT91 is defined we donot have at91_pmc_base. And
COMMON_CLK_AT91 is available with AT91 architecture.
Mention the dependency such that this driver builds with avr32 only if
OF is not enabled.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
The condition checking for irq_registered, regs, mem_region and active
are not required as this is the remove function. And we are in the
remove means that probe was successful and they can never be NULL at
this point of code.
It was required in the original code as the remove function was part of
the error handler of probe function.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
We have the function free_dma_pools() which frees all the dma pools. Use
it instead of calling all the functions separately. The if conditions
for data_requests and stp_requests are also not required here as this is
the remove function and we are here means probe has succeeded and dma
has been successfully allocated, so they cannot be NULL here.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: dwc2: gadget: ensure lx_state corresponds to current state
Correctly update lx_state on gadget connection and disconnection.
When usb cable is disconnected, lx_state must be updated to L3 as
controller could be in power off state.
When usb cable is connected, lx_state must be updated to L0 as
controller is powered.
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: kill remaining urbs using -ECONNRESET status
On a disconnect, dwc2 will kill all remaining urbs from qh list.
urbs are given back to hcd with -ETIMEDOUT status.
Some usb device driver, like mass storage, will unlink all urbs
using usb_hcd_unlink_urb when receiving a negative status different
from -ECONNRESET.
The following flow will then happen:
dwc2_hcd_disconnect()
-> dwc2_kill_all_urbs() try to kill first pending urb.
-> dwc2_host_complete(-ETIMEDOUT)
-> usb_hcd_giveback_urb(-ETIMEDOUT)
-> sg_complete()
-> usb_unlink_urb()
-> usb_put_dev(urb->dev)
-> dwc2_kill_all_urbs() try to kill next pending urb.
-> dwc2_host_complete(-ETIMEDOUT)
-> usb_hcd_giveback_urb(-ETIMEDOUT)
-> NULL pointer dereferencing because urb->dev has been freed for all
urbs of this device.
The root cause of this NULL pointer is to call call usb_unlink_urb()
while we are killing all urbs. To avoid this return urb with
-ECONNRESET status
This issue usually happens while removing mass storage device during
transfer.
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: wait 3ms for controller stabilization
Some high speed mass storage devices fail to enumerate with following
error:
Cannot enable port %i. Maybe the USB cable is bad?
This happens only when the device is plugged while the controller
is in hibernation state. After exiting hibernation, the controller
detects the device as a low speed device and fail to enumerate it.
Problem occurs only if HPRT0.PWR bit is programmed in a too short
delay after exiting hibernation. Dumping hprt register in
_dwc2_hcd_resume() directly after dwc2_exit_hibernation() shows that
HPRT0.LNSTS (D+/D- level) becomes valid approximately 2ms after
exiting hibernation.
Since dwc2_exit_hibernation() is called from atomic context, move the
delay out of this function.
Delay value is experimental and not mentioned in Synopsys
documentation. To be on the safe side 3ms delay is used.
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>
If an interrupt rises during hibernation process, dwc2 will assert
interrupt line to interrupt controller. If interrupt is level
sensitive, interrupt handler will be called in a loop because dwc2
will not be able to clear it while controller is hibernated.
Thus, clear all controller interrupts before hibernation entry.
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>
Frame number is reset in hardware after exiting hibernation.
Thus, reset frame_number and ensure qh are queued with correct
sched_frame.
Otherwise, qh->sched_frame may be too high compared to
current frame number (which is 0). This can delay addition of qh in
the list of transfers until frame number reaches qh->sched_frame.
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: enter hibernation during bus suspend
Disable controller power and enter hibernation when usb bus is
suspended. A phy driver is required to disable the power of the
controller and detect remote-wakeup or disconnection since the
controller will not be able to detect these in this state.
Once the phy driver detects bus activity, it must call
usb_hcd_resume_root_hub.
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: create a function to handle port_resume
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 hibernation
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>
Felipe Balbi [Mon, 28 Sep 2015 19:49:02 +0000 (14:49 -0500)]
usb: dwc3: gadget: use update transfer command
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.
Felipe Balbi [Mon, 21 Sep 2015 19:32:00 +0000 (14:32 -0500)]
usb: dwc3: gadget: start transfer on XFER_COMPLETE
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.
Heikki Krogerus [Mon, 21 Sep 2015 08:14:33 +0000 (11:14 +0300)]
usb: dwc3: st: prepare the driver for generic usb_get_dr_mode function
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>
Robert Baldyga [Wed, 16 Sep 2015 10:11:04 +0000 (12:11 +0200)]
usb: gadget: legacy: tcm: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:11:03 +0000 (12:11 +0200)]
usb: gadget: legacy: dbgp: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:11:02 +0000 (12:11 +0200)]
usb: gadget: u_serial: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:11:01 +0000 (12:11 +0200)]
usb: gadget: u_ether: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:11:00 +0000 (12:11 +0200)]
usb: gadget: f_uvc: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:59 +0000 (12:10 +0200)]
usb: gadget: f_uac2: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:58 +0000 (12:10 +0200)]
usb: gadget: f_uac1: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:57 +0000 (12:10 +0200)]
usb: gadget: f_subset: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:56 +0000 (12:10 +0200)]
usb: gadget: f_sourcesink: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:55 +0000 (12:10 +0200)]
usb: gadget: f_serial: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:54 +0000 (12:10 +0200)]
usb: gadget: f_rndis: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:53 +0000 (12:10 +0200)]
usb: gadget: f_printer: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:52 +0000 (12:10 +0200)]
usb: gadget: f_phonet: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:51 +0000 (12:10 +0200)]
usb: gadget: f_obex: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:50 +0000 (12:10 +0200)]
usb: gadget: f_ncm: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:49 +0000 (12:10 +0200)]
usb: gadget: f_midi: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:48 +0000 (12:10 +0200)]
usb: gadget: f_mass_storage: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:47 +0000 (12:10 +0200)]
usb: gadget: f_loopback: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:46 +0000 (12:10 +0200)]
usb: gadget: f_hid: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:45 +0000 (12:10 +0200)]
usb: gadget: f_eem: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:44 +0000 (12:10 +0200)]
usb: gadget: f_acm: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:43 +0000 (12:10 +0200)]
usb: gadget: f_ecm: eliminate abuse of ep->driver data
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 [Wed, 16 Sep 2015 10:10:42 +0000 (12:10 +0200)]
usb: gadget: introduce 'enabled' flag in struct usb_ep
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 [Wed, 16 Sep 2015 10:10:41 +0000 (12:10 +0200)]
usb: gadget: epautoconf: add usb_ep_autoconfig_release() function
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 [Wed, 16 Sep 2015 10:10:40 +0000 (12:10 +0200)]
usb: gadget: f_ncm: obtain cdev from function instead of driver_data
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: dummy_hcd: replace timeval with timespec64
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.
Peter Chen [Tue, 1 Sep 2015 01:48:04 +0000 (09:48 +0800)]
tools: usb: testusb: change the default value for length from 512 to 1024
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 [Tue, 1 Sep 2015 01:48:03 +0000 (09:48 +0800)]
tools: usb: testusb: change the help text
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 [Tue, 1 Sep 2015 01:48:02 +0000 (09:48 +0800)]
usb: gadget: f_sourcesink: format data pattern according to max packet size
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 [Tue, 1 Sep 2015 01:48:01 +0000 (09:48 +0800)]
usb: misc: usbtest: format the data pattern according to max packet size
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>
Antti Seppälä [Thu, 20 Aug 2015 18:41:07 +0000 (21:41 +0300)]
usb: dwc2: Use platform endianness when accessing registers
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 [Wed, 5 Aug 2015 06:54:55 +0000 (08:54 +0200)]
usb: gadget: ether: Allow jumbo frames
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 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>
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: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Tue, 15 Sep 2015 14:39:45 +0000 (09:39 -0500)]
usb: gadget: mass_storage: allow for deeper queue lengths
Instead of allowing a range of 2 to 4 requests,
let's allow the user choose up to 32 requests
as that will give us a better chance of keeping
controller busy.
We still maintain default of 2 so users shouldn't
be affected.
Felipe Balbi [Tue, 15 Sep 2015 14:49:14 +0000 (09:49 -0500)]
usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued
Instead of clearing DWC3_PENDING_REQUEST when
we start transfer, let's do it when the request
is actually queued, that way we know for sure
that we're clearing in the right time.
Felipe Balbi [Mon, 14 Sep 2015 16:27:46 +0000 (11:27 -0500)]
usb: dwc3: gadget: start requests as soon as they come
In an attempt to make dwc3 slightly faster, let's
start usb_requests as soon as they come as that will
let us avoid a XFER_NOT_READY event and save a little
bit of time.
Felipe Balbi [Tue, 1 Sep 2015 14:01:38 +0000 (09:01 -0500)]
usb: dwc3: gadget: move trace_dwc3_ep_queue()
by moving trace_dwc3_ep_queue() from dwc3_gadget_ep_queue()
to __dwc3_gadget_ep_queue() after usb_request is properly
initialized, makes for a better output always showing a
request with 0 actual and -115 (-EINPROGRESS) status.
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"Two bugfixes from Andy addressing at least some of the subtle NMI
related wreckage which has been reported by Sasha Levin"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code
x86/paravirt: Replace the paravirt nop with a bona fide empty function
projects / linux-beck.git / log