Message-ID: <1441981.OvF23sGttd@fb07-iapwap2>
Date:	Thu, 28 Nov 2013 13:54:10 +0100
From:	Marc Dietrich <marvin24@....de>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Rhyland Klein <rklein@...dia.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linus Walleij <linus.walleij@...aro.org>,
	Chris Ball <cjb@...top.org>,
	Johannes Berg <johannes@...solutions.net>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Alex Courbot <acourbot@...dia.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Rob Landley <rob@...dley.net>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Stephen Warren <swarren@...dotorg.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Devicetree List <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 1/6] ARM: tegra: add gpiod_lookup table for paz00

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists