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

On 06/21/2012 06:03 PM, Chen Peter-B29397 wrote:

quoted

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)