[U-Boot] [PATCH] ARM: tegra: add Colibri T30 board support

[Stephen Warren <swarren@wwwdotorg.org>]

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.