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

[Chen Peter-B29397]

> 
> 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 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)