On Saturday 31 March 2007 08:49, Ivo van Doorn wrote:
>
> Well that would mean rfkill would be ready to applied to one of the kernel
> trees right? :)
Well, that would be up to that particular tree maintainer. I am not sure
who maintains the net/... David Miller maybe? Anyway, below is the same
> > Well in drivers/net are the network drivers but not the irda and bluetooth
> > drivers,
> > those are located in different folders in drivers/ so I think misc would be
> > the most
> > suitable location.
>
> We could also consider the ./net itself. rfkill is not a driver, it is
> a facility.
On 3/30/07, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > >
> > > My only concern is where rfkill code should live. Since it is no
> > > longer dependent on input core (embedded systems might disable
> > > rfkill-input and use bare rfkill and control state from userspace)
> > > it does not need to
> > > There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH
> > > events passing through input system and toggles state of all RF
> > > switches of appropriate type registered with rfkill system (unless
> > > a switch was claimed by userspace in which case it is left alone).
> > > I
On 3/30/07, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
Hi,
> I am very sorry for taking so much time to respond but finally I went
> through the patch and I still have the same objection as before -
> it mixes two logically (and often physically) separated objects into
> a single entity. I think t
Hi,
> I am very sorry for taking so much time to respond but finally I went
> through the patch and I still have the same objection as before -
> it mixes two logically (and often physically) separated objects into
> a single entity. I think that RF switch and button should be separate
> entities,
On Wednesday 31 January 2007 06:20, Ivo van Doorn wrote:
> > Hope you will be resubmitting this.
>
> And here is the new version,
> I didn't make the name const as requested
> that field is being passed to the class_device_create
> method which requires a char* argument.
>
> But I have made the f
Input: polled device skeleton
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile|1
drivers/input/misc/input-polldev.c | 149 +
include/linux/input-polldev.h | 46
> Hope you will be resubmitting this.
And here is the new version,
I didn't make the name const as requested
that field is being passed to the class_device_create
method which requires a char* argument.
But I have made the flag field.
And now this time the patch actually includes the
changes I pr
Hi,
> > + /*
> > +* Pointer to rfkill structure
> > +* that was filled in by key driver.
> > +*/
> > + struct rfkill *rfkill;
>
> Since rfkill is basically a function pointer table,
> can it be made const?
Sounds good to me.
> > + /*
> > +* Once key status change has been
Hope you will be resubmitting this.
> +/*
> + * rfkill key structure.
> + */
> +struct rfkill_key {
> + /*
> + * For sysfs representation.
> + */
> + struct class_device *cdev;
> +
> + /*
> + * Pointer to rfkill structure
> + * that was filled in by key driver.
> +
Well it's been a while, but here is an updated version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
Move to the new Workqueue API
The open_count has
This is the latest version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
The open_count has been completely removed, decision making on which action
s
Hi,
> > > > > 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
Hi Ivo,
On Thursday 07 December 2006 16:53, Ivo van Doorn wrote:
> Hi,
>
> > > > > 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 ori
Hi,
> > > > 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 ha
Hi,
> > > > 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
On Wed, 2006-12-06 at 22:41 +0100, Ivo van Doorn wrote:
> Hi,
>
> > > > That is my point. Given the fact that there are keys that are not
> > > > directly connected with the radio switch userspace will have to handle
> > > > them (wait for events then turn off radios somehow). You are
> > > > advo
On 12/6/06, Jiri Benc <[EMAIL PROTECTED]> wrote:
On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote:
> On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > Ok, so input device opening should not block the rfkill signal and the
rfkill handler
> > should still go through with its work un
On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote:
> On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > Ok, so input device opening should not block the rfkill signal and the
> > rfkill handler
> > should still go through with its work unless a different config option
> > indicates t
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> 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 f
Hi,
> > > That is my point. Given the fact that there are keys that are not
> > > directly connected with the radio switch userspace will have to handle
> > > them (wait for events then turn off radios somehow). You are
> > > advocating that userspace should also implement 2nd method for buttons
>
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote:
> On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > > I am still not sure that tight coupling of input device with rfkill
> > > structure is such a good idea. Quite often the bu
On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote:
> On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > > I am still not sure that tight coupling of input device with rfkill
> > > structure is such a good idea. Quite often the button is separated
> > > from the device itself and radi
On 12/6/06, Dan Williams <[EMAIL PROTECTED]> wrote:
On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote:
>
> Fans of the 3rd method, speak up ;)
I think I brought up the 3rd method initially in this thread. I'm not
necessarily advocating it, but I wanted to be sure people realized that
thi
On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote:
> On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > > I am still not sure that tight coupling of input device with rfkill
> > > structure is such a good idea. Quite often the button is separated
> > > from the device itself and radio
On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> I am still not sure that tight coupling of input device with rfkill
> structure is such a good idea. Quite often the button is separated
> from the device itself and radio control is done via BIOS SMM (see
> wistron driver) or there is no spe
On Tuesday 05 December 2006 11:32, Christoph Hellwig wrote:
> > +/*
> > + * Function called by the key driver when the rfkill structure
> > + * needs to be registered.
> > + */
> > +int rfkill_register_key(struct rfkill *rfkill, int init_status)
> > +{
> > + struct rfkill_type *type = &master->ty
[snip]
> > +/*
> > + * Function called by the key driver to report the new status
> > + * of the key.
> > + */
> > +void rfkill_report_event(struct rfkill *rfkill, int new_status)
> > +{
> > + mutex_lock(&master->mutex);
> > +
> > + if (rfkill_check_key(rfkill->key, new_status))
> > +
> +/*
> + * Function called by the key driver when the rfkill structure
> + * needs to be registered.
> + */
> +int rfkill_register_key(struct rfkill *rfkill, int init_status)
> +{
> + struct rfkill_type *type = &master->type[rfkill->key_type];
> + struct rfkill_key *key;
> + int status
On Sun, 3 Dec 2006 23:28:11 +0100 Ivo van Doorn wrote:
> rfkill with the fixes as suggested by Arjan.
> - instead of a semaphore a mutex is now being used.
> - open_count changing is now locked by the mutex.
>
> ---
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> ind
Hi,
> > This patch is a resend of a patch I has been send to the linux kernel
> > and netdev list earlier. The most recent version of a few weeks back
> > didn't compile since I missed 1 line in my patch that changed
> > include/linux/input.h.
> >
> > This patch will offer the handling of radiokey
On 12/3/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
Hi,
This patch is a resend of a patch I has been send to the linux kernel
and netdev list earlier. The most recent version of a few weeks back
didn't compile since I missed 1 line in my patch that changed
include/linux/input.h.
This patch wil
Hi Dan,
> 3) How does this interact with HAL? What's the userspace interface that
> HAL will listen to to receive the signals? NetworkManager will need to
> listen to HAL for these, as rfkill switches are one big thing that NM
> does not handle now due to lack of a standard mechanism.
>
> In an
rfkill with the fixes as suggested by Arjan.
- instead of a semaphore a mutex is now being used.
- open_count changing is now locked by the mutex.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100
Hi,
> > This patch is a resend of a patch I has been send to the linux kernel
> > and netdev list earlier. The most recent version of a few weeks back
> > didn't compile since I missed 1 line in my patch that changed
> > include/linux/input.h.
> >
> > This patch will offer the handling of radioke
On Sunday 03 December 2006 20:20, Arjan van de Ven wrote:
> this open_count thing smells fishy to me; what are the locking rules for
> it? What guarantees that the readers of it don't get the value changed
> underneath them between looking at the value and doing whatever action
> depends on it's va
On Sunday 03 December 2006 20:18, Arjan van de Ven wrote:
> On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> > +
> > + down(&master->key_sem);
> > +
>
> Hi,
>
> this one seems to be used as a mutex only, please consider using a mutex
> instead, as is the default for new code since
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> Hi,
>
> This patch is a resend of a patch I has been send to the linux kernel
> and netdev list earlier. The most recent version of a few weeks back
> didn't compile since I missed 1 line in my patch that changed
> include/linux/input.h.
>
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> +static int rfkill_open(struct input_dev *dev)
> +{
> + ((struct rfkill_key*)(dev->private))->open_count++;
> + return 0;
> +}
Hi,
this open_count thing smells fishy to me; what are the locking rules for
it? What guarantees th
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> +
> + down(&master->key_sem);
> +
Hi,
this one seems to be used as a mutex only, please consider using a mutex
instead, as is the default for new code since 2.6.16 or so
Greetings,
Arjan van de Ven
--
if you want to mail m
Hi,
This patch is a resend of a patch I has been send to the linux kernel
and netdev list earlier. The most recent version of a few weeks back
didn't compile since I missed 1 line in my patch that changed
include/linux/input.h.
This patch will offer the handling of radiokeys on a laptop.
Such key
42 matches
Mail list logo
