| Message ID | 1453712629-143317-4-git-send-email-heikki.krogerus@linux.intel.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Mon, Jan 25, 2016 at 12:03:48PM +0300, Heikki Krogerus wrote: > Pass the rfkill name and type to the device with properties > instead of driver specific platform data. > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > CC: Alexandre Courbot <gnurou@gmail.com> > CC: Thierry Reding <thierry.reding@gmail.com> > CC: Stephen Warren <swarren@wwwdotorg.org> > --- > arch/arm/mach-tegra/board-paz00.c | 17 ++++++++++------- > 1 file changed, 10 insertions(+), 7 deletions(-) Looks fine to me. We might want to wait for Marc (Cc'ed) to give this a spin, since I don't have the hardware. For reference, the series can be found here: http://patchwork.ozlabs.org/patch/572640/ http://patchwork.ozlabs.org/patch/572644/ http://patchwork.ozlabs.org/patch/572643/ http://patchwork.ozlabs.org/patch/572642/ Johannes, I assume that you'll want to take this through your tree because of the dependency? In that case: Acked-by: Thierry Reding <treding@nvidia.com>
Am Montag 25 Januar 2016, 13:18:40 schrieb Thierry Reding: > On Mon, Jan 25, 2016 at 12:03:48PM +0300, Heikki Krogerus wrote: > > Pass the rfkill name and type to the device with properties > > instead of driver specific platform data. > > > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > > CC: Alexandre Courbot <gnurou@gmail.com> > > CC: Thierry Reding <thierry.reding@gmail.com> > > CC: Stephen Warren <swarren@wwwdotorg.org> > > --- > > > > arch/arm/mach-tegra/board-paz00.c | 17 ++++++++++------- > > 1 file changed, 10 insertions(+), 7 deletions(-) > > Looks fine to me. We might want to wait for Marc (Cc'ed) to give this a > spin, since I don't have the hardware. For reference, the series can be > found here: > > http://patchwork.ozlabs.org/patch/572640/ > http://patchwork.ozlabs.org/patch/572644/ > http://patchwork.ozlabs.org/patch/572643/ > http://patchwork.ozlabs.org/patch/572642/ > > Johannes, I assume that you'll want to take this through your tree > because of the dependency? In that case: > > Acked-by: Thierry Reding <treding@nvidia.com> seems to work fine. I wish we could instantiate this from device-tree so we can finially get rid of this file. Tested-by: Marc Dietrich <marvin24@gmx.de>
On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > > Johannes, I assume that you'll want to take this through your tree > because of the dependency? In that case: > > Acked-by: Thierry Reding <treding@nvidia.com> I can, but I don't really care - perhaps you'd rather take the entire series through your tree to get it into one place for Marc? In which case, you have my Acked-by: Johannes Berg <johannes@sipsolutions.net> for the other 3 patches. Let me know which you prefer. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote: > > seems to work fine. I wish we could instantiate this from device-tree > so we can finially get rid of this file. That'd be nice - anyone want to propose rfkill DT bindings? :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 26. Januar 2016, 09:46:56 CET schrieb Johannes Berg: > On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote: > > > > > > seems to work fine. I wish we could instantiate this from device-tree > > so we can finially get rid of this file. > > That'd be nice - anyone want to propose rfkill DT bindings? :) There have been at least 5 attempts to do this in the past - all fail. You've been warned :-) Marc
On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > > > > Johannes, I assume that you'll want to take this through your tree > > because of the dependency? In that case: > > > > Acked-by: Thierry Reding <treding@nvidia.com> > > I can, but I don't really care - perhaps you'd rather take the entire > series through your tree to get it into one place for Marc? > > In which case, you have my > > Acked-by: Johannes Berg <johannes@sipsolutions.net> > > for the other 3 patches. > > Let me know which you prefer. > Did these patches get applied anywhere? Otherwise I'm willing to pick them up. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 18, 2016 at 09:04:49PM +0100, Johannes Berg wrote: > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > > > > > > Johannes, I assume that you'll want to take this through your tree > > > because of the dependency? In that case: > > > > > > Acked-by: Thierry Reding <treding@nvidia.com> > > > > I can, but I don't really care - perhaps you'd rather take the entire > > series through your tree to get it into one place for Marc? > > > > In which case, you have my > > > > Acked-by: Johannes Berg <johannes@sipsolutions.net> > > > > for the other 3 patches. > > > > Let me know which you prefer. > > > Did these patches get applied anywhere? Otherwise I'm willing to pick > them up. Might be easier for everyone if you took this one patch. My earlier Acked-by still stands: Acked-by: Thierry Reding <treding@nvidia.com>
On Thursday 18 February 2016 21:04:49 Johannes Berg wrote: > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > > > > > > Johannes, I assume that you'll want to take this through your tree > > > because of the dependency? In that case: > > > > > > Acked-by: Thierry Reding <treding@nvidia.com> > > > > I can, but I don't really care - perhaps you'd rather take the entire > > series through your tree to get it into one place for Marc? > > > > In which case, you have my > > > > Acked-by: Johannes Berg <johannes@sipsolutions.net> > > > > for the other 3 patches. > > > > Let me know which you prefer. > > > Did these patches get applied anywhere? Otherwise I'm willing to pick > them up. > Fine with me too: Acked-by: Arnd Bergmann <arnd@arndb.de> Just for my curiosity: what is the difference between a rfkill-gpio device and a gpio-keys device with a KEY_RFKILL code? arch/arm/boot/dts/bcm4708-netgear-r6250.dts and others seem to do the second approach in DT so they don't need to create the platform device. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2016-02-19 at 19:03 +0100, Thierry Reding wrote: > On Thu, Feb 18, 2016 at 09:04:49PM +0100, Johannes Berg wrote: > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > > On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote: > > > > > > > > Johannes, I assume that you'll want to take this through your > > > > tree > > > > because of the dependency? In that case: > > > > > > > > Acked-by: Thierry Reding <treding@nvidia.com> > > > > > > I can, but I don't really care - perhaps you'd rather take the > > > entire > > > series through your tree to get it into one place for Marc? > > > > > > In which case, you have my > > > > > > Acked-by: Johannes Berg <johannes@sipsolutions.net> > > > > > > for the other 3 patches. > > > > > > Let me know which you prefer. > > > > > Did these patches get applied anywhere? Otherwise I'm willing to > > pick > > them up. > > Might be easier for everyone if you took this one patch. My earlier > Acked-by still stands: > Yep, done. I've applied all 4 patches now. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > On Thursday 18 February 2016 21:04:49 Johannes Berg wrote: > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > Just for my curiosity: what is the difference between a rfkill-gpio > device and a gpio-keys device with a KEY_RFKILL code? > > arch/arm/boot/dts/bcm4708-netgear-r6250.dts and others seem to > do the second approach in DT so they don't need to create the > platform device. I found the answer now (after discussing on IRC): just for reference: KEY_RFKILL is for sending the event to the kernel when a user presses the gpio butting, this rfkill-gpio turns the devices on or off when after an RFKILL event is received. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > > On Thursday 18 February 2016 21:04:49 Johannes Berg wrote: > > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > Just for my curiosity: what is the difference between a rfkill-gpio > > device and a gpio-keys device with a KEY_RFKILL code? > > > > arch/arm/boot/dts/bcm4708-netgear-r6250.dts and others seem to > > do the second approach in DT so they don't need to create the > > platform device. > > I found the answer now (after discussing on IRC): just > for reference: KEY_RFKILL is for sending the event to the kernel > when a user presses the gpio butting, this rfkill-gpio turns > the devices on or off when after an RFKILL event is received. yes, paz00 has no hw key. rfkill is triggered via software (rfkill) only. The problem in the past was how to describe such a device in the device tree. Strictly speaking, there is no rfkill device hardware (just an interface). The only hardware that exists is in our case is connected to a hard wired usb bus (wifi dongle), which makes it complicated to attach a DT property or subdevice to it. And a standalone device-tree entry for a non hardware device was rejected in the past. Marc
On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote: > Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > > > On Thursday 18 February 2016 21:04:49 Johannes Berg wrote: > > > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > > Just for my curiosity: what is the difference between a rfkill-gpio > > > device and a gpio-keys device with a KEY_RFKILL code? > > > > > > arch/arm/boot/dts/bcm4708-netgear-r6250.dts and others seem to > > > do the second approach in DT so they don't need to create the > > > platform device. > > > > I found the answer now (after discussing on IRC): just > > for reference: KEY_RFKILL is for sending the event to the kernel > > when a user presses the gpio butting, this rfkill-gpio turns > > the devices on or off when after an RFKILL event is received. > > yes, paz00 has no hw key. rfkill is triggered via software (rfkill) only. The > problem in the past was how to describe such a device in the device tree. > > Strictly speaking, there is no rfkill device hardware (just an interface). The > only hardware that exists is in our case is connected to a hard wired usb bus > (wifi dongle), which makes it complicated to attach a DT property or subdevice > to it. And a standalone device-tree entry for a non hardware device was > rejected in the past. > Ah, so the problem of attaching DT properties to a USB device has recently been solved, see subject "USB: core: let USB device know device node". Would that work for you? With this, the USB driver can simply look at the optional DT properties of the USB function to implement its rfkill callbacks. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, 23. Februar 2016, 14:17:17 CET schrieb Arnd Bergmann: > On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote: > > Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > > > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote: > > > > On Thursday 18 February 2016 21:04:49 Johannes Berg wrote: > > > > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote: > > > > Just for my curiosity: what is the difference between a rfkill-gpio > > > > device and a gpio-keys device with a KEY_RFKILL code? > > > > > > > > arch/arm/boot/dts/bcm4708-netgear-r6250.dts and others seem to > > > > do the second approach in DT so they don't need to create the > > > > platform device. > > > > > > I found the answer now (after discussing on IRC): just > > > for reference: KEY_RFKILL is for sending the event to the kernel > > > when a user presses the gpio butting, this rfkill-gpio turns > > > the devices on or off when after an RFKILL event is received. > > > > yes, paz00 has no hw key. rfkill is triggered via software (rfkill) only. > > The problem in the past was how to describe such a device in the device > > tree. > > > > Strictly speaking, there is no rfkill device hardware (just an interface). > > The only hardware that exists is in our case is connected to a hard wired > > usb bus (wifi dongle), which makes it complicated to attach a DT property > > or subdevice to it. And a standalone device-tree entry for a non hardware > > device was rejected in the past. > > Ah, so the problem of attaching DT properties to a USB device has recently > been solved, see subject "USB: core: let USB device know device node". > > Would that work for you? With this, the USB driver can simply look at > the optional DT properties of the USB function to implement its rfkill > callbacks. oh, that looks indeed interesting. The question is now if rfkill is a property of a device or a subdevice itself. The latter one would only require addition of device-tree instantiation of rfkill, while with the former one, the (or all) usb driver(s) need to be modified to accept device tree properties, especially gpios. The driver would then be responsible to add an rfkill "device". IMHO (and unfortunately), it's just a property (a way to specify the relevant gpios), making the solution again hard to archive. Marc
On Tuesday 23 February 2016 14:42:55 Marc Dietrich wrote: > Am Dienstag, 23. Februar 2016, 14:17:17 CET schrieb Arnd Bergmann: > > On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote: > > > Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann: > > Ah, so the problem of attaching DT properties to a USB device has recently > > been solved, see subject "USB: core: let USB device know device node". > > > > Would that work for you? With this, the USB driver can simply look at > > the optional DT properties of the USB function to implement its rfkill > > callbacks. > > oh, that looks indeed interesting. The question is now if rfkill is a property > of a device or a subdevice itself. The latter one would only require addition > of device-tree instantiation of rfkill, while with the former one, the (or > all) usb driver(s) need to be modified to accept device tree properties, > especially gpios. The driver would then be responsible to add an rfkill > "device". > > IMHO (and unfortunately), it's just a property (a way to specify the relevant > gpios), making the solution again hard to archive. Does rfkill always have a separate device in the Linux driver model? I would say that if we standardize on the property names, we can have some generic helper code that does everything with one or two function calls, similar to how we can read a mac address from a DT node from ROM-less USB ethernet devices. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2016-02-23 at 16:06 +0100, Arnd Bergmann wrote: > > Does rfkill always have a separate device in the Linux driver model? Yes, the rfkill core code registers and adds one in the rfkill class. > johannes -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-tegra/board-paz00.c b/arch/arm/mach-tegra/board-paz00.c index 49d1110..52db8bf 100644 --- a/arch/arm/mach-tegra/board-paz00.c +++ b/arch/arm/mach-tegra/board-paz00.c @@ -17,23 +17,25 @@ * */ +#include <linux/property.h> #include <linux/gpio/machine.h> #include <linux/platform_device.h> -#include <linux/rfkill-gpio.h> #include "board.h" -static struct rfkill_gpio_platform_data wifi_rfkill_platform_data = { - .name = "wifi_rfkill", - .type = RFKILL_TYPE_WLAN, +static struct property_entry __initdata wifi_rfkill_prop[] = { + PROPERTY_ENTRY_STRING("name", "wifi_rfkill"), + PROPERTY_ENTRY_STRING("type", "wlan"), + { }, +}; + +static struct property_set __initdata wifi_rfkill_pset = { + .properties = wifi_rfkill_prop, }; static struct platform_device wifi_rfkill_device = { .name = "rfkill_gpio", .id = -1, - .dev = { - .platform_data = &wifi_rfkill_platform_data, - }, }; static struct gpiod_lookup_table wifi_gpio_lookup = { @@ -47,6 +49,7 @@ static struct gpiod_lookup_table wifi_gpio_lookup = { void __init tegra_paz00_wifikill_init(void) { + platform_device_add_properties(&wifi_rfkill_device, &wifi_rfkill_pset); gpiod_add_lookup_table(&wifi_gpio_lookup); platform_device_register(&wifi_rfkill_device); }
Pass the rfkill name and type to the device with properties instead of driver specific platform data. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> CC: Alexandre Courbot <gnurou@gmail.com> CC: Thierry Reding <thierry.reding@gmail.com> CC: Stephen Warren <swarren@wwwdotorg.org> --- arch/arm/mach-tegra/board-paz00.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)