On 07/31/2014 03:55 PM, Simon Glass wrote:
On 31 July 2014 19:00, Stefan Agner stefan@agner.ch wrote:
Am 2014-07-31 19:41, schrieb Simon Glass:
On 31 July 2014 18:36, Stefan Agner stefan@agner.ch wrote:
This adds board support for the Toradex Colibri T30 module.
+/*
- Enable AX88772B USB to LAN controller
- */
+void pin_mux_usb(void) +{
/* Enable LAN_VBUS */gpio_request(GPIO_PDD2, NULL);gpio_direction_output(GPIO_PDD2, 1);/* Reset ASIX using LAN_RESET */gpio_request(GPIO_PDD0, NULL);gpio_direction_output(GPIO_PDD0, 0);udelay(5);gpio_set_value(GPIO_PDD0, 1);You are using device tree for sdhci - shouldn't we use it for USB also?
The Colibri T30 has a ASIX USB to Ethernet chip on its board. We reset/power the ASIX here. It is a very board specific reset/powering, hence I put it in here.
In my initial patches I had it in the nvidia,phy-reset-gpio and nvidia,vbus-gpio properties. Technically, it would work to have this GPIOs in the device tree as USB properties, but I think this would be logically wrong...
For VBUS I think it would be correct to put it in the USB. For the reset, I'm not sure - it looks like a separate pin so putting it in the device tree for USB would be wrong I think.
What does the kernel do for these?
The kernel doesn't yet have a good answer to things like this, i.e. data that's not directly driven by the requirements of a controller or protocol, but rather the custom/out-of-band aspects of the device that's connected to the controller.
So, a GPIO for VBUS is something very closely tied to the USB specification, and basically any USB controller needs to represent and handle it in the same way.
However, a GPIO to reset/enable a USB device is something completely outside the scope of the USB specification, and is very device specific, and there's currently no good answer re: how to handle it.
There have been various attempts to solve it such as a generic "power sequences" DT binding, various proposals for a "slot" or "connector" or "target device" binding, or even explicitly defining the attached device in DT (even though it can be probed) and having the driver for that handle all the HW-specific details. However these threads have unfortunately all languished.