Am Donnerstag, 28. November 2013, 12:06:37 schrieb Thierry Reding:
> On Thu, Nov 28, 2013 at 11:20:19AM +0100, Marc Dietrich wrote:
> > Am Donnerstag, 28. November 2013, 10:32:41 schrieb Thierry Reding:
> > > On Thu, Nov 28, 2013 at 10:09:14AM +0100, Marc Dietrich wrote:
> > > > The real problem with the rfkill driver is that it does not support
> > > > DT. A
> > > > naive attempt to convert it was made some year ago, but got rejected
> > > > because rfkill wasn't seen as isolated device which can be represented
> > > > in
> > > > the device- tree. Also it can not be added under some existing device
> > > > node (e.g. the wifi driver) because those devices sit normally on an
> > > > "enumeratable" bus (e.g. usb, pci), which is not listed in the device
> > > > tree at all. This is why it still requires a board file and
> > > > platform_data. I wish we could find a solution for this.
> > >
> > > There is a solution at least for PCI. You can list PCI devices within
> > > the device tree, which is really handy (required even) if for instance
> > > one of the PCI devices is an SPI or I2C controller, each providing a bus
> > > that cannot be probed. What you usually do is describe the PCI hierarchy
> > > at least up to the controller and then list slaves as child nodes.
> > >
> > > I'm not aware of anything similar for USB, but it should certainly be
> > > possible to come up with a standard binding for the USB bus. It has a
> > > topology that's similar enough to that of PCI so that the same general
> > > rules could be applied.
> > >
> > > If that's really the only thing that keeps rfkill from gaining DT
> > > support then it's something worth tackling in my opinion.
> >
> > it's not so simple I fear. The wifi driver needs to learn about the rfkill
> > "device".
>
> Why does the WiFi driver need to know about it? You say below that the
> WiFi driver polls a separate set of GPIO lines (internal to the WiFi
> module I assume?). In that case rfkill is merely a way to export control
> of that functionality so that it can be used from some other part of the
> kernel or from userspace.
You are right. We just need some device to bind this driver to. It doesn't
need to be the wifi driver.
> That's very similar to things such as backlight control or fan control.
> Still we manage to describe those in DT as well.
Yes, rfkill is just an interface for userspace to able to control the gpio.
E.g. backlight of medcom-wide seems to be related to the pwm controller, but
is not a subnode of it. Instead it is a device of its own without parent.
Hence, we may include rfkill in a similar, "free-standing" node. But this
approch was rejected in the past. Maybe this changed now.
> > As mentioned above, it's not really a device so the question is what
> > needs to be added and where? The wifi driver just polls his own gpio lines
> > to check the status of rfkill. Be we want to modify the "other side", so
> > maybe this isn't related to the wifi driver at all. It's more a "virtual
> > rfkill device". No idea if something like this exists already in device
> > tree.
> But it's a part of some other device. Or rather, it's always associated
> with another device, right? So I don't see anything particularily wrong
> with something like this:
>
> usb-controller {
> /* USB hub */
> usb@0,0 {
> ...
>
> /* USB device */
> usb@1,0 {
> ...
>
> rfkill {
> shutdown-gpio = <&gpio ...>;
> reset-gpio = <&gpio ...>;
> };
>
> ...
> };
>
> ...
> };
> };
>
> You said that the main objection was that it needed to be represented as
> a "subdevice" of whatever device it controls. If the only reason is that
> we have no means to represent those devices because they are on a bus
> that can be enumerated and therefore can't be listed in DT, then my
> suggestion is to fix things so that we can describe those devices in DT.
>
> The goal is to get rid of board files, right? board-paz00.c is the only
> one left for Tegra, and rfkill is an actual hardware component, so there
> is no reason why it can't be described in DT.
Thinking a bit more about it, rfkill is neither a hw block nor a function of
the wifi driver, so I guess it cannot be added to the usb controller (or a usb
device).
Anyway, I think this discussion deserves a new mail thread, but I don't have
enough background information to start one. We can bring this topic back when
all turkeys who deserve it, are dead.
Marc
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
