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
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
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.
True, in
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
> > > 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).
> > >
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
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
>
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 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 that
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 think this
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 live in
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
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 |
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 flag
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
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
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 detected, the
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
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
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
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.
+ */
+
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
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
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
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
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 originally designed for.
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 hardware button
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
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
> > > >
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
advocating that
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 hardware button
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 hardware button that
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
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
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
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
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
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
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
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 special
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 control is
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
this
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 radio control
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 button is
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
that
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 from
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 that
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 unless a
[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(>mutex);
> > +
> > + if (rfkill_check_key(rfkill->key, new_status))
> > +
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 =
> +/*
> + * 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 = >type[rfkill->key_type];
> + struct rfkill_key *key;
> + int 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 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 =
[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))
+
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
>
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
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
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
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 will
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
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
index
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 any
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
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
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
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(>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
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
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> +
> + down(>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 me at
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
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
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 me at
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 that the
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.
This
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 2.6.16 or
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 value
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
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
84 matches
Mail list logo
