>
> 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@2 {
> child-supply = <®ulator>;
> reset-gpios = <&gpio 0 0>;
> };
> };
> };
> };
>
> But without knowing what might be connected to port@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@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)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
