netdev - Re: [RFC] rfkill - Add support for input key to control wireless radio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Dec 2006 17:04:56 -0500
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Ivo van Doorn" <ivdoorn@...il.com>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	"John Linville" <linville@...driver.com>,
	"Jiri Benc" <jbenc@...e.cz>,
	"Lennart Poettering" <lennart@...ttering.net>,
	"Johannes Berg" <johannes@...solutions.net>,
	"Larry Finger" <Larry.Finger@...inger.net>
Subject: Re: [RFC] rfkill - Add support for input key to control wireless radio

On 12/6/06, Ivo van Doorn <ivdoorn@...il.com> wrote:
>
> > >  2 - Hardware key that does not control the hardware radio and does not report anything to userspace
> >
> > Kind of uninteresting button ;)
>
> And this is the button that rfkill was originally designed for.
> Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to
> userspace (unless the ACPI event is read) and does not directly control the radio itself.
>

So what does such a button do? I am confused here...

...
>
> And this event should be reported by a generic approach right? So it should
> be similar as with your point 2 below. But this would mean that the driver
> should create the input device. Or can a driver send the KEY_WIFI event
> over a main layer without the need of a personal input device?
> I am not that familiar with the input device layer in the kernel, and this is
> my first attempt on creating something for it, so I might have missed something. ;)

Yes, I think the driver should just create an input device. You may
provide a generic implementation for a polled button and have driver
instantiate it but I do not think that a single RFkill button device
is needed - you won't have too many of them in a single system anyway
(I think you will normally have 1, 2 at the most).

...
> > 3. A device without transmitter but with a button - just register with
> > input core. Userspace will have to manage state of other devices with
> > transmitters in response to button presses.
>
> This is clear too. Rfkill is only intended for drivers that control a device with
> a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to
> do something with the radio/transmitter.
>
> > Does this make sense?
>
> Yes, this was what I intended to do with rfkill, so at that point we have
> the same goal.
>

I think it is almost the same. I also want support RF devices that can
control radio state but lack a button. This is covered by mixing 2)
and 3) in kernel and for userspace looks exactly like 2) with a
button.

...
> >
> > I don't think a config option is a good idea unless by config option
> > you mean a sysfs attribute.
>
> I indeed meant a sysfs attribute. I should have been more clear on this. :)
>

OK :)

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html