From: Johannes Berg <johannes@sipsolutions.net> Date: 2016-01-26 08:42:10
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 <redacted>
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 <redacted>
for the other 3 patches.
Let me know which you prefer.
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2016-02-18 20:05:01
On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote:
On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote:
quoted
Johannes, I assume that you'll want to take this through your tree
because of the dependency? In that case:
Acked-by: Thierry Reding <redacted>
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
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:
quoted
On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote:
quoted
Johannes, I assume that you'll want to take this through your tree
because of the dependency? In that case:
Acked-by: Thierry Reding <redacted>
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 <redacted>
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 <redacted>
On Thursday 18 February 2016 21:04:49 Johannes Berg wrote:
On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote:
quoted
On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote:
quoted
Johannes, I assume that you'll want to take this through your tree
because of the dependency? In that case:
Acked-by: Thierry Reding <redacted>
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 <redacted>
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 <redacted>
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
On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote:
On Thursday 18 February 2016 21:04:49 Johannes Berg wrote:
quoted
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
From: Marc Dietrich <marvin24@gmx.de> Date: 2016-02-23 10:39:13
Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann:
On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote:
quoted
On Thursday 18 February 2016 21:04:49 Johannes Berg wrote:
quoted
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:
quoted
On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote:
quoted
On Thursday 18 February 2016 21:04:49 Johannes Berg wrote:
quoted
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
From: Marc Dietrich <marvin24@gmx.de> Date: 2016-02-23 13:43:08
Am Dienstag, 23. Februar 2016, 14:17:17 CET schrieb Arnd Bergmann:
On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote:
quoted
Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann:
quoted
On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote:
quoted
On Thursday 18 February 2016 21:04:49 Johannes Berg wrote:
quoted
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:
quoted
On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote:
quoted
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