summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2015-10-01usb: dwc2: host: correctly dump urb isochronous descriptorsGregory Herrero1-5/+6
Print urb->iso_frame_desc.status after it has been updated using dwc2_hcd_urb_get_iso_desc_status(). 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>
2015-10-01usb: dwc2: host: wait 3ms for controller stabilizationGregory Herrero1-1/+4
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>
2015-10-01usb: dwc2: host: clear pending interrupts prior hibernationGregory Herrero1-0/+6
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>
2015-10-01usb: dwc2: host: disable interrupt during stopGregory Herrero1-0/+3
Disable host interrupts before synchronising dwc2 irq. So that interrupts are not generated once controller is stopped. 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>
2015-10-01usb: dwc2: host: add disconnect interrupt to host only interruptsMian Yousaf Kaukab1-2/+3
GINTSTS.DisconnInt is host only interrupt and should be disable after dwc2_disable_host_interrupts is called. 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>
2015-10-01usb: dwc2: host: disconnect hcd prior stopping itGregory Herrero1-0/+5
In case controller is asked to stop while devices are connected, disconnect all devices and clean up before stopping. 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>
2015-10-01usb: dwc2: host: reset frame number after suspendGregory Herrero2-0/+9
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>
2015-10-01usb: dwc2: host: resume only if bus is suspendedGregory Herrero1-1/+2
Port can be resumed in bus_resume callback. In this case, there is no need to drive resume a second time when hcd ask for it. 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>
2015-10-01usb: dwc2: host: ignore wakeup interrupt if hibernation supportedGregory Herrero1-0/+4
If hibernation is supported, resume of devices will be handled in bus_resume callback. 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>
2015-10-01usb: dwc2: host: avoid resetting lx_state to L3 during disconnectGregory Herrero1-3/+0
When a device is disconnected, lx_state must not be changed since the device may be disconnected whereas controller is still 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>
2015-10-01usb: dwc2: host: update hcd and lx_state during start/stop callbacksGregory Herrero1-1/+5
During hcd initialization, hardware accessible flag and lx_state must be reset to the working state since controller is powered at this stage. Same logic applied for stop callback. 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>
2015-10-01usb: dwc2: host: enter hibernation during bus suspendGregory Herrero1-12/+128
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>
2015-10-01usb: dwc2: host: add flag to reflect bus stateGregory Herrero2-2/+4
lx_state must be used to reflect controller power state only and not bus state. Thus add a flag to track state during bus suspend. 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>
2015-10-01usb: dwc2: host: create a function to handle port_resumeGregory Herrero1-10/+30
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>
2015-10-01usb: dwc2: host: don't clear hprt0 status bits when exiting hibernationGregory Herrero1-1/+1
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>
2015-09-28usb: dwc3: gadget: remove unnecessary _irqsave()Felipe Balbi1-3/+2
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>
2015-09-28usb: dwc3: gadget: use Update Transfer from Xfer In ProgressFelipe Balbi1-2/+2
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>
2015-09-28usb: dwc3: gadget: use update transfer commandFelipe Balbi1-4/+5
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>
2015-09-28usb: dwc3: gadget: start transfer on XFER_COMPLETEFelipe Balbi1-0/+8
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>
2015-09-28usb: gadget: pch-udc: fix lockFelipe Balbi1-4/+4
gadget methods should be called without spinlocks held. Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-09-27usb: dwc3: pci: passing forward the ACPI companionHeikki Krogerus1-0/+1
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>
2015-09-27usb: dwc3: core: convert to unified device property interfaceHeikki Krogerus1-26/+24
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>
2015-09-27usb: common: of_usb_get_dr_mode to usb_get_dr_modeHeikki Krogerus9-19/+12
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>
2015-09-27usb: dwc3: st: prepare the driver for generic usb_get_dr_mode functionHeikki Krogerus1-2/+10
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>
2015-09-27usb: common: of_usb_get_maximum_speed to usb_get_maximum_speedHeikki Krogerus4-29/+22
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>
2015-09-27usb: gadget: legacy: tcm: eliminate abuse of ep->driver dataRobert Baldyga1-18/+0
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>
2015-09-27usb: gadget: legacy: dbgp: eliminate abuse of ep->driver dataRobert Baldyga1-16/+2
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>
2015-09-27usb: gadget: u_serial: eliminate abuse of ep->driver dataRobert Baldyga1-5/+0
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>
2015-09-27usb: gadget: u_ether: eliminate abuse of ep->driver dataRobert Baldyga1-2/+0
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>
2015-09-27usb: gadget: f_uvc: eliminate abuse of ep->driver dataRobert Baldyga1-34/+8
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>
2015-09-27usb: gadget: f_uac2: eliminate abuse of ep->driver dataRobert Baldyga1-11/+0
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>
2015-09-27usb: gadget: f_uac1: eliminate abuse of ep->driver dataRobert Baldyga1-4/+0
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>
2015-09-27usb: gadget: f_subset: eliminate abuse of ep->driver dataRobert Baldyga1-9/+1
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>
2015-09-27usb: gadget: f_sourcesink: eliminate abuse of ep->driver dataRobert Baldyga1-22/+7
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>
2015-09-27usb: gadget: f_serial: eliminate abuse of ep->driver dataRobert Baldyga1-9/+1
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>
2015-09-27usb: gadget: f_rndis: eliminate abuse of ep->driver dataRobert Baldyga1-19/+5
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>
2015-09-27usb: gadget: f_printer: eliminate abuse of ep->driver dataRobert Baldyga1-2/+0
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>
2015-09-27usb: gadget: f_phonet: eliminate abuse of ep->driver dataRobert Baldyga1-7/+1
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>
2015-09-27usb: gadget: f_obex: eliminate abuse of ep->driver dataRobert Baldyga1-9/+1
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>
2015-09-27usb: gadget: f_ncm: eliminate abuse of ep->driver dataRobert Baldyga1-21/+6
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>
2015-09-27usb: gadget: f_midi: eliminate abuse of ep->driver dataRobert Baldyga1-12/+2
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>
2015-09-27usb: gadget: f_mass_storage: eliminate abuse of ep->driver dataRobert Baldyga1-4/+0
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>
2015-09-27usb: gadget: f_loopback: eliminate abuse of ep->driver dataRobert Baldyga1-4/+1
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>
2015-09-27usb: gadget: f_hid: eliminate abuse of ep->driver dataRobert Baldyga1-10/+2
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>
2015-09-27usb: gadget: f_eem: eliminate abuse of ep->driver dataRobert Baldyga1-13/+3
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>
2015-09-27usb: gadget: f_acm: eliminate abuse of ep->driver dataRobert Baldyga1-19/+4
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>
2015-09-27usb: gadget: f_ecm: eliminate abuse of ep->driver dataRobert Baldyga1-24/+7
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>
2015-09-27usb: gadget: epautoconf: add usb_ep_autoconfig_release() functionRobert Baldyga1-0/+17
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>
2015-09-27usb: gadget: f_ncm: obtain cdev from function instead of driver_dataRobert Baldyga1-1/+1
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>
2015-09-27usb: gadget: fix few outdated commentsRobert Baldyga2-7/+5
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>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-22 11:13:07 +0300