summaryrefslogtreecommitdiff
path: root/include/linux/ulpi
AgeCommit message (Collapse)Author
2016-09-14Merge tag 'usb-for-v4.9' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Felipe writes: usb: patches for v4.9 merge window This time around we have 92 non-merge commits. Most of the changes are in drivers/usb/gadget (40.3%) with drivers/usb/gadget/function being the most active directory (27.2%). As for UDC drivers, only dwc3 (26.5%) and dwc2 (12.7%) have really been active. The most important changes for dwc3 are better support for scatterlist and, again, throughput improvements. While on dwc2 got some minor stability fixes related to soft reset and FIFO usage. Felipe Tonello has done some good work fixing up our f_midi gadget and Tal Shorer has implemented a nice API change for our ULPI bus. Apart from these, we have our usual set of non-critical fixes, spelling fixes, build warning fixes, etc.
2016-09-06usb: ulpi: make ops struct constantTal Shorer
None of the core ulpi functions perform any changes to the operations struct, and logically as a struct that contains function pointers there's no reason it shouldn't be constant. Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Tal Shorer <tal.shorer@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-09-06usb: ulpi: remove "dev" field from struct ulpi_opsTal Shorer
Operations now use ulpi->dev.parent directly instead of via the ulpi_ops struct, making this field unused. Remove it. Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Tal Shorer <tal.shorer@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-09-06usb: ulpi: rename operations {read|write}_dev to simply {read|write}Tal Shorer
With the removal of the old {read|write} operations, we can now safely rename the new api operations {read|write}_dev to use the shorter and clearer names {read|write}, respectively. Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Tal Shorer <tal.shorer@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-09-06usb: ulpi: remove calls to old api callbacksTal Shorer
Now that all users use the new api callbacks, remove the old api callbacks and force new interface drivers to use the new api. Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Tal Shorer <tal.shorer@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-09-06usb: ulpi: add new api functions, {read|write}_dev()Tal Shorer
Add these two new api callbacks to struct ulpi_ops. These are different than read, write in that they pass the parent device directly instead of via the ops argument. They are intended to replace the old api functions. If the new api callbacks are missing, revert to calling the old ones as before. Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Tal Shorer <tal.shorer@gmail.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2016-08-09usb: ulpi: Automatically set driver::owner with ulpi_driver_register()Stephen Boyd
Let's follow other driver registration functions and automatically set the driver's owner member to THIS_MODULE when ulpi_driver_register() is called. This allows ulpi driver writers to forget about this boiler plate detail and avoids common bugs in the process. Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-13usb: add bus type for USB ULPIHeikki Krogerus
UTMI+ Low Pin Interface (ULPI) is a commonly used PHY interface for USB 2.0. The ULPI specification describes a standard set of registers which the vendors can extend for their specific needs. ULPI PHYs provide often functions such as charger detection and ADP sensing and probing. There are two major issues that the bus type is meant to tackle: Firstly, ULPI registers are accessed from the controller. The bus provides convenient method for the controller drivers to share that access with the actual PHY drivers. Secondly, there are already platforms that assume ULPI PHYs are runtime detected, such as many Intel Baytrail based platforms. They do not provide any kind of hardware description for the ULPI PHYs like separate ACPI device object that could be used to enumerate a device from. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: David Cohen <david.a.cohen@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>