On 06/20/2012 07:32 PM, Chen Peter-B29397 wrote: > >> I haven't been following the thread, but just noticed it. Very similar >> things (DT nodes for probed devices) are coming up quite a bit recently, >> for example: >> >> Re: Where to power on the wifi device before loading the driver. >> http://www.spinics.net/lists/arm-kernel/msg180368.html >> >> dt: rfkill-gpio: add bindings documentation >> http://www.spinics.net/lists/linux-tegra/msg03977.html >> >> I wonder if there's any kind of infra-structure or standardized bindings >> that would be useful here? > > Hi Stephen, > For your suggestion: > > sdhci@78000000 { > compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci"; > reg = <0x78000000 0x200>; > interrupts = <0 14 0x04>; > > sdio-device { > reset-gpios = <...>; > enable-gpios = <...>; > }; > }; > > I have a question, if reset-gpio or enable-gpio is not set, how bus (sd or usb) know > it is a sdio device as the wifi is not powered on at the time, it will not response host's > command, the hub at usb bus is the same. 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. -- 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
