[Patch v5 08/13] ARM: imx6q: add config-on-boot gpios

[Stephen Warren]

On 06/21/2012 06:03 PM, Chen Peter-B29397 wrote:
>  
>>
>> That's a good point. We need those properties to be part of the device
>> that controls the port/slot/connector, not the thing that plugs into it.
>> Having each such binding and driver implement this themselves might not
>> be a good idea though. Perhaps we can standardize on a mechanism for
>> this; something vaguely like rfkill, but for arbitrary types of devices
>> connected to ports.
>>
>> For USB at least, where the power/reset/... GPIOs might affect just one
>> port on a hub rather than the root USB host controller, the issue of
>> representing these properties on a dynamically probed device still
>> applies. Something like:
>>
>> ehci {
>>     /* The following node is dynamically detected, although the hub
>>      * IC is physically soldered onto the board
>>      */
>>     hub {
>>         hub { /* also dynamic */
>>             port at 2 {
>>                 child-supply = <&regulator>;
>>                 reset-gpios = <&gpio 0 0>;
>>             };
>>         };
>>     };
>> };
>>
>> But without knowing what might be connected to port at 2, how do we know
>> how to sequence the power supply and reset GPIOs according to its
>> requirements? I guess this is part of the specification of the port
>> itself though, not the attached device, since anything that is allowed
>> to plug in must conform to whatever sequencing the port is designed to
>> give. If the connected device is known, the port at 2 node in DT can encode
>> whatever sequencing requirements are associated with the known connected
>> device.
> 
> In fact, for specific usb/sdio interface device, there should be a specific interface 
> class driver for it, the best place is at that class driver, like wifi or 3g driver,
> as it is chip/device specific.

But like you said, there's no way to tell what's attached to a USB or
SDIO port before probing it, at least if the port is at all
user-accessible. The class driver for the host-side of the port (USB hub
or SDIO controller) would be the one that needs to implement this, not
the class driver for the thing that could be plugged in (WiFi or 3G device).

> But the generic 3G and HUB devices are special, there is only one common driver
> for each of them (drivers/usb/core/hub.c & drivers/serial/option.c)