Re: [PATCH 17/86] drivers/net/wireless/rt2x00: remove depends on CONFIG_EXPERIMENTAL

[Ivo Van Doorn]

On Thu, Jan 17, 2013 at 3:53 AM, Kees Cook  wrote:
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
>
> CC: Ivo van Doorn 
> CC: Gertjan van Wingerde 
> CC: Helmut Schaa 
> CC: "John W. Linville" 
> Cc: "David S. Miller" 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Kees Cook 

Acked-by: Ivo van Doorn 

> ---
>  drivers/net/wireless/rt2x00/Kconfig |5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/Kconfig 
> b/drivers/net/wireless/rt2x00/Kconfig
> index c7548da..44d6ead 100644
> --- a/drivers/net/wireless/rt2x00/Kconfig
> +++ b/drivers/net/wireless/rt2x00/Kconfig
> @@ -82,7 +82,6 @@ config RT2800PCI_RT33XX
>
>  config RT2800PCI_RT35XX
> bool "rt2800pci - Include support for rt35xx devices (EXPERIMENTAL)"
> -   depends on EXPERIMENTAL
> default y
> ---help---
>   This adds support for rt35xx wireless chipset family to the
> @@ -92,7 +91,6 @@ config RT2800PCI_RT35XX
>
>  config RT2800PCI_RT53XX
> bool "rt2800pci - Include support for rt53xx devices (EXPERIMENTAL)"
> -   depends on EXPERIMENTAL
> default y
> ---help---
>   This adds support for rt53xx wireless chipset family to the
> @@ -101,7 +99,6 @@ config RT2800PCI_RT53XX
>
>  config RT2800PCI_RT3290
> bool "rt2800pci - Include support for rt3290 devices (EXPERIMENTAL)"
> -   depends on EXPERIMENTAL
> default y
> ---help---
>   This adds support for rt3290 wireless chipset family to the
> @@ -159,7 +156,6 @@ config RT2800USB_RT33XX
>
>  config RT2800USB_RT35XX
> bool "rt2800usb - Include support for rt35xx devices (EXPERIMENTAL)"
> -   depends on EXPERIMENTAL
> default y
> ---help---
>   This adds support for rt35xx wireless chipset family to the
> @@ -168,7 +164,6 @@ config RT2800USB_RT35XX
>
>  config RT2800USB_RT53XX
> bool "rt2800usb - Include support for rt53xx devices (EXPERIMENTAL)"
> -   depends on EXPERIMENTAL
> ---help---
>   This adds support for rt53xx wireless chipset family to the
>   rt2800usb driver.
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/86] drivers/net/wireless/rt2x00: remove depends on CONFIG_EXPERIMENTAL

[Ivo Van Doorn]

On Thu, Jan 17, 2013 at 3:53 AM, Kees Cook keesc...@chromium.org wrote:
 The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
 while now and is almost always enabled by default. As agreed during the
 Linux kernel summit, remove it from any depends on lines in Kconfigs.

 CC: Ivo van Doorn ivdo...@gmail.com
 CC: Gertjan van Wingerde gwinge...@gmail.com
 CC: Helmut Schaa helmut.sc...@googlemail.com
 CC: John W. Linville linvi...@tuxdriver.com
 Cc: David S. Miller da...@davemloft.net
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Signed-off-by: Kees Cook keesc...@chromium.org

Acked-by: Ivo van Doorn ivdo...@gmail.com

 ---
  drivers/net/wireless/rt2x00/Kconfig |5 -
  1 file changed, 5 deletions(-)

 diff --git a/drivers/net/wireless/rt2x00/Kconfig 
 b/drivers/net/wireless/rt2x00/Kconfig
 index c7548da..44d6ead 100644
 --- a/drivers/net/wireless/rt2x00/Kconfig
 +++ b/drivers/net/wireless/rt2x00/Kconfig
 @@ -82,7 +82,6 @@ config RT2800PCI_RT33XX

  config RT2800PCI_RT35XX
 bool rt2800pci - Include support for rt35xx devices (EXPERIMENTAL)
 -   depends on EXPERIMENTAL
 default y
 ---help---
   This adds support for rt35xx wireless chipset family to the
 @@ -92,7 +91,6 @@ config RT2800PCI_RT35XX

  config RT2800PCI_RT53XX
 bool rt2800pci - Include support for rt53xx devices (EXPERIMENTAL)
 -   depends on EXPERIMENTAL
 default y
 ---help---
   This adds support for rt53xx wireless chipset family to the
 @@ -101,7 +99,6 @@ config RT2800PCI_RT53XX

  config RT2800PCI_RT3290
 bool rt2800pci - Include support for rt3290 devices (EXPERIMENTAL)
 -   depends on EXPERIMENTAL
 default y
 ---help---
   This adds support for rt3290 wireless chipset family to the
 @@ -159,7 +156,6 @@ config RT2800USB_RT33XX

  config RT2800USB_RT35XX
 bool rt2800usb - Include support for rt35xx devices (EXPERIMENTAL)
 -   depends on EXPERIMENTAL
 default y
 ---help---
   This adds support for rt35xx wireless chipset family to the
 @@ -168,7 +164,6 @@ config RT2800USB_RT35XX

  config RT2800USB_RT53XX
 bool rt2800usb - Include support for rt53xx devices (EXPERIMENTAL)
 -   depends on EXPERIMENTAL
 ---help---
   This adds support for rt53xx wireless chipset family to the
   rt2800usb driver.
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo Van Doorn]

Hi,

>  > > >  Checking those out is simply a matter of:
>  > > >  git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
>  > > >  git checkout 2.0.11
>  > >
>  > > OK, we seem to be struggling a little, so I've built an installed git
>  > > and cloned Linus' 2.6 tree. My wireless network dies after a few pings
>  > > with rt2x00 2.0.11.
>  > >
>  > > >  No further bisecting is needed, but with above tests I can at least
>  > > >  narrow it down to find the cause of this issue.
>  > >
>  > > If you need me to bisect, just shout. Please be patient though, I'm
>  > > exploring new territory here :-)
>  >
>  > I don't think bisecting this will help a lot, the rt2x00 2.0.11 release
>  > introduced software diversity. And that is already something I suspect
>  > of being broken.
>  >
>   I've bisected anyway and although the results are not absolutely conclusive,
>  as I neared the end of the process, I was amongst a bunch of mac80211
>  patches. This set me on a path that resulted in me discovering that with the
>  rt61pci driver, I can freeze my wireless network connection almost at will if
>  I set mac82011's ieee80211_default_rc_algo parameter to 'pid'. if the
>  parametre is set to 'simple', the network seems to be reliable. I've just let
>  the ping application run on and ping another box on my network almost 1500
>  times whilst repeatedly transferring a kernel source tarball by ftp from
>  another box and the network connection was mantained That's with the
>  parameter set to 'simple', if \I set it to 'pid' the connection rarely
>  survives more than 40 pings even without the ftp activity.
>
>  If I replace my wireless card with one that uses the rtl8180 driver, the
>  network connection seems to be reliable regardless of how I set the
>  parameter, although I admit that i have not tested this extensively yet. I'll
>  do that now and report later.

I'm about to send 4 patches to this (linux-wireless) list with patches
for rt2x00,
most of them you already tested individually, but several people reported
success after those patches.

Hopefully it will be working for you as well. :)

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo Van Doorn]

Hi,

  Checking those out is simply a matter of:
  git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
  git checkout 2.0.11
   
OK, we seem to be struggling a little, so I've built an installed git
and cloned Linus' 2.6 tree. My wireless network dies after a few pings
with rt2x00 2.0.11.
   
  No further bisecting is needed, but with above tests I can at least
  narrow it down to find the cause of this issue.
   
If you need me to bisect, just shout. Please be patient though, I'm
exploring new territory here :-)
  
   I don't think bisecting this will help a lot, the rt2x00 2.0.11 release
   introduced software diversity. And that is already something I suspect
   of being broken.
  
   I've bisected anyway and although the results are not absolutely conclusive,
  as I neared the end of the process, I was amongst a bunch of mac80211
  patches. This set me on a path that resulted in me discovering that with the
  rt61pci driver, I can freeze my wireless network connection almost at will if
  I set mac82011's ieee80211_default_rc_algo parameter to 'pid'. if the
  parametre is set to 'simple', the network seems to be reliable. I've just let
  the ping application run on and ping another box on my network almost 1500
  times whilst repeatedly transferring a kernel source tarball by ftp from
  another box and the network connection was mantained That's with the
  parameter set to 'simple', if \I set it to 'pid' the connection rarely
  survives more than 40 pings even without the ftp activity.

  If I replace my wireless card with one that uses the rtl8180 driver, the
  network connection seems to be reliable regardless of how I set the
  parameter, although I admit that i have not tested this extensively yet. I'll
  do that now and report later.

I'm about to send 4 patches to this (linux-wireless) list with patches
for rt2x00,
most of them you already tested individually, but several people reported
success after those patches.

Hopefully it will be working for you as well. :)

Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Friday 22 February 2008, Chris Clayton wrote:
> Hi Ivo,
> 
> On 18/02/2008, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> 
> [...]
> 
> > Above traces should be enough, but to determine where rt2x00 broke
> >  down approximatly I need to have a few test result on specific moments.
> >  Could you test the kernel with the following versions:
> >
> >  rt2x00 2.0.11   2d68de3efa62655d551092f5c787505735d561ad
> >  rt2x00 2.0.12   a3c7aa58df7df80aa05f166fe3e42482247164cf
> >  rt2x00 2.0.13   5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc
> >
> >  Checking those out is simply a matter of:
> >  git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
> >  git checkout 2.0.11
> >
> 
> OK, we seem to be struggling a little, so I've built an installed git
> and cloned Linus' 2.6 tree. My wireless network dies after a few pings
> with rt2x00 2.0.11.
> 
> >  No further bisecting is needed, but with above tests I can at least
> >  narrow it down to find the cause of this issue.
> >
> 
> If you need me to bisect, just shout. Please be patient though, I'm
> exploring new territory here :-)

I don't think bisecting this will help a lot, the rt2x00 2.0.11 release
introduced software diversity. And that is already something I suspect
of being broken.

Unfortunately software diversity was a bugfix and fix in one,
the previous setup was broken for some hardware since the
lack of software diversity caused problems.

Could you check if below patch helps in any way?

Ivo

---

diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c 
b/drivers/net/wireless/rt2x00/rt2x00config.c
index a1d8e33..6995912 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -122,6 +122,10 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
libconf.ant.rx = rx;
libconf.ant.tx = tx;
 
+   if (rx == rt2x00dev->link.ant.active.rx &&
+   tx == rt2x00dev->link.ant.active.tx)
+   return;
+
/*
 * Antenna setup changes require the RX to be disabled,
 * else the changes will be ignored by the device.
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 65a512f..4325c08 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -191,16 +191,16 @@ static void rt2x00lib_evaluate_antenna_sample(struct 
rt2x00_dev *rt2x00dev)
return;
 
if (rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) {
-   if (sample_a > sample_b && rx == ANTENNA_B)
+   if (sample_a > sample_b)
rx = ANTENNA_A;
-   else if (rx == ANTENNA_A)
+   else
rx = ANTENNA_B;
}
 
if (rt2x00dev->link.ant.flags & ANTENNA_TX_DIVERSITY) {
-   if (sample_a > sample_b && tx == ANTENNA_B)
+   if (sample_a > sample_b)
tx = ANTENNA_A;
-   else if (tx == ANTENNA_A)
+   else
tx = ANTENNA_B;
}
 
@@ -257,7 +257,7 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev 
*rt2x00dev)
 
if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) &&
!(rt2x00dev->link.ant.flags & ANTENNA_TX_DIVERSITY)) {
-   rt2x00dev->link.ant.flags &= ~ANTENNA_MODE_SAMPLE;
+   rt2x00dev->link.ant.flags = 0;
return;
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Friday 22 February 2008, Chris Clayton wrote:
> On Thursday 21 February 2008, Chris Vine wrote:
> > On Thu, 2008-02-21 at 23:04 +, Chris Clayton wrote:
> > > On Thursday 21 February 2008, Ivo van Doorn wrote:
> > > > On Thursday 21 February 2008, Chris Vine wrote:
> > [snip]
> > > > > This probably explains the problem another user reported with rt61.
> > > > 
> > > > Perhaps something similar like:
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=10058
> > > > in there a reference is made to the following patch:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/broken-out/revert-send-a-single-notification-on-device-state-changes.patch
> > > > 
> > > > Does applying that help?
> > > 
> > > I'm afraid not, Ivo. The test I ran last night was against 
> > > 2.6.25.-rc2-git4 and
> > > that already has this patch applied. Furthermore, I have another card 
> > > that uses
> > > the rtl8180 driver and that works reliably. I, therefore, suspect that my 
> > > problem
> > > lies within the rt61pci driver or the rt2x00 infrastructure.
> > 
> > Does the same happen with 2.0.14 under kernel 2.6.24?
> 
> Unfortunately, a 2.6.24.2 tree with the drivers/net/wireless/rt2x00 directory 
> replaced with that from 2.6.25-rc2-git4 doesn't build:

You need the mac80211 compat  module from Intel. That allows new mac80211 
versions to run
on older kernels. When you use that you need to grab the rt2x00 cvs tarball 
from:
http://rt2x00.serialmonkey.com/wiki/index.php/Downloads

which allows rt2x00 to be compiled outside of the kernel.

> In file included from drivers/net/wireless/rt2x00/rt2x00dev.c:29:
> drivers/net/wireless/rt2x00/rt2x00.h:942: warning: `struct 
> ieee80211_bss_conf' declared inside parameter list
> drivers/net/wireless/rt2x00/rt2x00.h:942: warning: its scope is only this 
> definition or declaration, which is probably not what you want
> 
> [...]
> 
> drivers/net/wireless/rt2x00/rt2x00dev.c: In function 
> `rt2x00lib_configuration_scheduled':
> drivers/net/wireless/rt2x00/rt2x00dev.c:484: error: storage size of 
> `bss_conf' isn't known
> drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: 
> `BSS_CHANGED_ERP_PREAMBLE' undeclared (first use in this function)
> drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: (Each undeclared 
> identifier is reported only once
> drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: for each function it 
> appears in.)
> drivers/net/wireless/rt2x00/rt2x00dev.c:484: warning: unused variable 
> `bss_conf'
> drivers/net/wireless/rt2x00/rt2x00dev.c: In function 
> `rt2x00lib_beacondone_scheduled':
> drivers/net/wireless/rt2x00/rt2x00dev.c:511: warning: passing arg 2 of 
> `ieee80211_beacon_get' makes integer from pointer without a cast

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Friday 22 February 2008, Chris Clayton wrote:
 On Thursday 21 February 2008, Chris Vine wrote:
  On Thu, 2008-02-21 at 23:04 +, Chris Clayton wrote:
   On Thursday 21 February 2008, Ivo van Doorn wrote:
On Thursday 21 February 2008, Chris Vine wrote:
  [snip]
 This probably explains the problem another user reported with rt61.

Perhaps something similar like:
http://bugzilla.kernel.org/show_bug.cgi?id=10058
in there a reference is made to the following patch:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/broken-out/revert-send-a-single-notification-on-device-state-changes.patch

Does applying that help?
   
   I'm afraid not, Ivo. The test I ran last night was against 
   2.6.25.-rc2-git4 and
   that already has this patch applied. Furthermore, I have another card 
   that uses
   the rtl8180 driver and that works reliably. I, therefore, suspect that my 
   problem
   lies within the rt61pci driver or the rt2x00 infrastructure.
  
  Does the same happen with 2.0.14 under kernel 2.6.24?
 
 Unfortunately, a 2.6.24.2 tree with the drivers/net/wireless/rt2x00 directory 
 replaced with that from 2.6.25-rc2-git4 doesn't build:

You need the mac80211 compat  module from Intel. That allows new mac80211 
versions to run
on older kernels. When you use that you need to grab the rt2x00 cvs tarball 
from:
http://rt2x00.serialmonkey.com/wiki/index.php/Downloads

which allows rt2x00 to be compiled outside of the kernel.

 In file included from drivers/net/wireless/rt2x00/rt2x00dev.c:29:
 drivers/net/wireless/rt2x00/rt2x00.h:942: warning: `struct 
 ieee80211_bss_conf' declared inside parameter list
 drivers/net/wireless/rt2x00/rt2x00.h:942: warning: its scope is only this 
 definition or declaration, which is probably not what you want
 
 [...]
 
 drivers/net/wireless/rt2x00/rt2x00dev.c: In function 
 `rt2x00lib_configuration_scheduled':
 drivers/net/wireless/rt2x00/rt2x00dev.c:484: error: storage size of 
 `bss_conf' isn't known
 drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: 
 `BSS_CHANGED_ERP_PREAMBLE' undeclared (first use in this function)
 drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: (Each undeclared 
 identifier is reported only once
 drivers/net/wireless/rt2x00/rt2x00dev.c:494: error: for each function it 
 appears in.)
 drivers/net/wireless/rt2x00/rt2x00dev.c:484: warning: unused variable 
 `bss_conf'
 drivers/net/wireless/rt2x00/rt2x00dev.c: In function 
 `rt2x00lib_beacondone_scheduled':
 drivers/net/wireless/rt2x00/rt2x00dev.c:511: warning: passing arg 2 of 
 `ieee80211_beacon_get' makes integer from pointer without a cast

Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Friday 22 February 2008, Chris Clayton wrote:
 Hi Ivo,
 
 On 18/02/2008, Ivo van Doorn [EMAIL PROTECTED] wrote:
  Hi,
 
 
 [...]
 
  Above traces should be enough, but to determine where rt2x00 broke
   down approximatly I need to have a few test result on specific moments.
   Could you test the kernel with the following versions:
 
   rt2x00 2.0.11   2d68de3efa62655d551092f5c787505735d561ad
   rt2x00 2.0.12   a3c7aa58df7df80aa05f166fe3e42482247164cf
   rt2x00 2.0.13   5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc
 
   Checking those out is simply a matter of:
   git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
   git checkout 2.0.11
 
 
 OK, we seem to be struggling a little, so I've built an installed git
 and cloned Linus' 2.6 tree. My wireless network dies after a few pings
 with rt2x00 2.0.11.
 
   No further bisecting is needed, but with above tests I can at least
   narrow it down to find the cause of this issue.
 
 
 If you need me to bisect, just shout. Please be patient though, I'm
 exploring new territory here :-)

I don't think bisecting this will help a lot, the rt2x00 2.0.11 release
introduced software diversity. And that is already something I suspect
of being broken.

Unfortunately software diversity was a bugfix and fix in one,
the previous setup was broken for some hardware since the
lack of software diversity caused problems.

Could you check if below patch helps in any way?

Ivo

---

diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c 
b/drivers/net/wireless/rt2x00/rt2x00config.c
index a1d8e33..6995912 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -122,6 +122,10 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
libconf.ant.rx = rx;
libconf.ant.tx = tx;
 
+   if (rx == rt2x00dev-link.ant.active.rx 
+   tx == rt2x00dev-link.ant.active.tx)
+   return;
+
/*
 * Antenna setup changes require the RX to be disabled,
 * else the changes will be ignored by the device.
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 65a512f..4325c08 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -191,16 +191,16 @@ static void rt2x00lib_evaluate_antenna_sample(struct 
rt2x00_dev *rt2x00dev)
return;
 
if (rt2x00dev-link.ant.flags  ANTENNA_RX_DIVERSITY) {
-   if (sample_a  sample_b  rx == ANTENNA_B)
+   if (sample_a  sample_b)
rx = ANTENNA_A;
-   else if (rx == ANTENNA_A)
+   else
rx = ANTENNA_B;
}
 
if (rt2x00dev-link.ant.flags  ANTENNA_TX_DIVERSITY) {
-   if (sample_a  sample_b  tx == ANTENNA_B)
+   if (sample_a  sample_b)
tx = ANTENNA_A;
-   else if (tx == ANTENNA_A)
+   else
tx = ANTENNA_B;
}
 
@@ -257,7 +257,7 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev 
*rt2x00dev)
 
if (!(rt2x00dev-link.ant.flags  ANTENNA_RX_DIVERSITY) 
!(rt2x00dev-link.ant.flags  ANTENNA_TX_DIVERSITY)) {
-   rt2x00dev-link.ant.flags = ~ANTENNA_MODE_SAMPLE;
+   rt2x00dev-link.ant.flags = 0;
return;
}
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Thursday 21 February 2008, Chris Vine wrote:
> On Wed, 2008-02-20 at 21:16 +, Chris Vine wrote: 
> > On Wed, 2008-02-20 at 21:50 +0100, Ivo van Doorn wrote:
> > [snip]
> > > On Wednesday 20 February 2008, Chris Vine wrote:
> > > > I did that yesterday and it just reported a kernel panic on the terminal
> > > > with the message:
> > > > 
> > > >   Kernel panic - not syncing: Aiee, killing interrupt handler!
> > > 
> > > I have an idea, could you try below patch?
> > > Note that while applying it will mention something about a line offset, 
> > > but that can be ignored.
> > > 
> > > This could perhaps also fix the TX/RX issue mentioned earlier in the 
> > > thread, but I am not
> > > quite sure about that.
> > 
> > The patch applied OK (with some offsets as you say) but it doesn't help.
> > The kernel panic still occurs when association is attempted.
> 
> Here's some further information.
> 
> I have a fully functioning version of rt2x00-2.0.14 and mac80211 from
> wireless-2.6/compat-wireless-2.6 of mid January which works fine on
> kernel 2.6.24.  On doing a comparison with the rt2x00 in vanilla kernel
> 2.6.25-rc2, there are no material differences.  (There was a slight
> change in the declaration a variable in rt2x00usb.c but it is
> immaterial.)
> 
> I compiled up the working mid-January version of rt2x00 and mac80211
> under kernel 2.6.25-rc2 and I get exactly the same result as I reported
> earlier, namely I get a kernel panic as soon as I try to associate.  It
> looks therefore as if something has changed within the remainder of the
> kernel which has caused rt2x00 (and possibly mac80211?) to break.
> 
> This probably explains the problem another user reported with rt61.

Perhaps something similar like:
http://bugzilla.kernel.org/show_bug.cgi?id=10058
in there a reference is made to the following patch:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/broken-out/revert-send-a-single-notification-on-device-state-changes.patch

Does applying that help?

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Thursday 21 February 2008, Chris Vine wrote:
 On Wed, 2008-02-20 at 21:16 +, Chris Vine wrote: 
  On Wed, 2008-02-20 at 21:50 +0100, Ivo van Doorn wrote:
  [snip]
   On Wednesday 20 February 2008, Chris Vine wrote:
I did that yesterday and it just reported a kernel panic on the terminal
with the message:

  Kernel panic - not syncing: Aiee, killing interrupt handler!
   
   I have an idea, could you try below patch?
   Note that while applying it will mention something about a line offset, 
   but that can be ignored.
   
   This could perhaps also fix the TX/RX issue mentioned earlier in the 
   thread, but I am not
   quite sure about that.
  
  The patch applied OK (with some offsets as you say) but it doesn't help.
  The kernel panic still occurs when association is attempted.
 
 Here's some further information.
 
 I have a fully functioning version of rt2x00-2.0.14 and mac80211 from
 wireless-2.6/compat-wireless-2.6 of mid January which works fine on
 kernel 2.6.24.  On doing a comparison with the rt2x00 in vanilla kernel
 2.6.25-rc2, there are no material differences.  (There was a slight
 change in the declaration a variable in rt2x00usb.c but it is
 immaterial.)
 
 I compiled up the working mid-January version of rt2x00 and mac80211
 under kernel 2.6.25-rc2 and I get exactly the same result as I reported
 earlier, namely I get a kernel panic as soon as I try to associate.  It
 looks therefore as if something has changed within the remainder of the
 kernel which has caused rt2x00 (and possibly mac80211?) to break.
 
 This probably explains the problem another user reported with rt61.

Perhaps something similar like:
http://bugzilla.kernel.org/show_bug.cgi?id=10058
in there a reference is made to the following patch:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/broken-out/revert-send-a-single-notification-on-device-state-changes.patch

Does applying that help?

Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Wednesday 20 February 2008, Chris Vine wrote:
> 
> On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: 
> > On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote:
> > > On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote:
> > > > Hi,
> > > > 
> > > > [added rt2400-devel (rt2x00 development mailinglist) to the CC list.]
> > > > 
> > > > > > > > I have a series of tests I would like to request from you,
> > > > > > > > you mentioned you already enabled debugfs, and that is just 
> > > > > > > > what we need. ;)
> > > > > > > > Please use attached script to create dumps of the hardware 
> > > > > > > > register contents.
> > > > > > > > 
> > > > > > > > There are specific moments that should be dumped:
> > > > > > > > - kernel 2.6.24 (last known working version for you).
> > > > > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies)
> > > > > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies)
> > > > > > > >  
> > > > > > > 
> > > > > > > These diagnostics are attached, with obvious filenames.
> > > > > > 
> > > > > > Thanks. I think I found something, please test below patch:
> > > > > > 
> > > > > 
> > > > > I've tried the patch but, unfortunately, my wireless LAN still dies 
> > > > > after a few pings.
> > > 
> > > rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2
> > > kernel (not wireless-2.6/rt2x00 git).  The modules load when I plug the
> > > stick in but I then get a complete kernel lock up with two flashing
> > > leds.  Nothing is recorded to system logs.  The last logged messages are
> > > that usbcore has registered new interface driver rt73usb, and that the
> > > rate control algorithm has been selected on phy0.  This happens whether
> > > the simple or pid mac80211 rate control algorithms have been chosen.
> > > 
> > > This is a shame because 2.0.14 was working really well for me until the
> > > mac80211 changes 2 or 3 weeks ago broke it.  (Shortly followed by the
> > > release of 2.1.*).
> > 
> > Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a
> > picture of the panic if one shows up.  _Something_ should show up on the
> > VT.
> 
> I did that yesterday and it just reported a kernel panic on the terminal
> with the message:
> 
>   Kernel panic - not syncing: Aiee, killing interrupt handler!

I have an idea, could you try below patch?
Note that while applying it will mention something about a line offset, but 
that can be ignored.

This could perhaps also fix the TX/RX issue mentioned earlier in the thread, 
but I am not
quite sure about that.

---
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c 
b/drivers/net/wireless/rt2x00/rt2400pci.c
index b63bc66..460ef2f 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -953,8 +953,12 @@ static int rt2400pci_set_device_state(struct rt2x00_dev 
*rt2x00dev,
rt2400pci_disable_radio(rt2x00dev);
break;
case STATE_RADIO_RX_ON:
+   case STATE_RADIO_RX_ON_LINK:
+   rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON);
+   break;
case STATE_RADIO_RX_OFF:
-   rt2400pci_toggle_rx(rt2x00dev, state);
+   case STATE_RADIO_RX_OFF_LINK:
+   rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF);
break;
case STATE_DEEP_SLEEP:
case STATE_SLEEP:
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c 
b/drivers/net/wireless/rt2x00/rt2500pci.c
index add8aff..ffcd996 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1106,8 +1106,12 @@ static int rt2500pci_set_device_state(struct rt2x00_dev 
*rt2x00dev,
rt2500pci_disable_radio(rt2x00dev);
break;
case STATE_RADIO_RX_ON:
+   case STATE_RADIO_RX_ON_LINK:
+   rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON);
+   break;
case STATE_RADIO_RX_OFF:
-   rt2500pci_toggle_rx(rt2x00dev, state);
+   case STATE_RADIO_RX_OFF_LINK:
+   rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF);
break;
case STATE_DEEP_SLEEP:
case STATE_SLEEP:
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c 
b/drivers/net/wireless/rt2x00/rt2500usb.c
index d9643c5..9f59db9 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/dri

Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

On Wednesday 20 February 2008, Chris Vine wrote:
 
 On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: 
  On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote:
   On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote:
Hi,

[added rt2400-devel (rt2x00 development mailinglist) to the CC list.]

I have a series of tests I would like to request from you,
you mentioned you already enabled debugfs, and that is just 
what we need. ;)
Please use attached script to create dumps of the hardware 
register contents.

There are specific moments that should be dumped:
- kernel 2.6.24 (last known working version for you).
- kernel 2.6.25-rc2 (after ifup, before TX dies)
- kernel 2.6.25-rc2 (after ifup, after TX dies)
 
   
   These diagnostics are attached, with obvious filenames.
  
  Thanks. I think I found something, please test below patch:
  
 
 I've tried the patch but, unfortunately, my wireless LAN still dies 
 after a few pings.
   
   rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2
   kernel (not wireless-2.6/rt2x00 git).  The modules load when I plug the
   stick in but I then get a complete kernel lock up with two flashing
   leds.  Nothing is recorded to system logs.  The last logged messages are
   that usbcore has registered new interface driver rt73usb, and that the
   rate control algorithm has been selected on phy0.  This happens whether
   the simple or pid mac80211 rate control algorithms have been chosen.
   
   This is a shame because 2.0.14 was working really well for me until the
   mac80211 changes 2 or 3 weeks ago broke it.  (Shortly followed by the
   release of 2.1.*).
  
  Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a
  picture of the panic if one shows up.  _Something_ should show up on the
  VT.
 
 I did that yesterday and it just reported a kernel panic on the terminal
 with the message:
 
   Kernel panic - not syncing: Aiee, killing interrupt handler!

I have an idea, could you try below patch?
Note that while applying it will mention something about a line offset, but 
that can be ignored.

This could perhaps also fix the TX/RX issue mentioned earlier in the thread, 
but I am not
quite sure about that.

---
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c 
b/drivers/net/wireless/rt2x00/rt2400pci.c
index b63bc66..460ef2f 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -953,8 +953,12 @@ static int rt2400pci_set_device_state(struct rt2x00_dev 
*rt2x00dev,
rt2400pci_disable_radio(rt2x00dev);
break;
case STATE_RADIO_RX_ON:
+   case STATE_RADIO_RX_ON_LINK:
+   rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON);
+   break;
case STATE_RADIO_RX_OFF:
-   rt2400pci_toggle_rx(rt2x00dev, state);
+   case STATE_RADIO_RX_OFF_LINK:
+   rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF);
break;
case STATE_DEEP_SLEEP:
case STATE_SLEEP:
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c 
b/drivers/net/wireless/rt2x00/rt2500pci.c
index add8aff..ffcd996 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1106,8 +1106,12 @@ static int rt2500pci_set_device_state(struct rt2x00_dev 
*rt2x00dev,
rt2500pci_disable_radio(rt2x00dev);
break;
case STATE_RADIO_RX_ON:
+   case STATE_RADIO_RX_ON_LINK:
+   rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON);
+   break;
case STATE_RADIO_RX_OFF:
-   rt2500pci_toggle_rx(rt2x00dev, state);
+   case STATE_RADIO_RX_OFF_LINK:
+   rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF);
break;
case STATE_DEEP_SLEEP:
case STATE_SLEEP:
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c 
b/drivers/net/wireless/rt2x00/rt2500usb.c
index d9643c5..9f59db9 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -996,8 +996,12 @@ static int rt2500usb_set_device_state(struct rt2x00_dev 
*rt2x00dev,
rt2500usb_disable_radio(rt2x00dev);
break;
case STATE_RADIO_RX_ON:
+   case STATE_RADIO_RX_ON_LINK:
+   rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON);
+   break;
case STATE_RADIO_RX_OFF:
-   rt2500usb_toggle_rx(rt2x00dev, state);
+   case STATE_RADIO_RX_OFF_LINK:
+   rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF);
break;
case STATE_DEEP_SLEEP:
case STATE_SLEEP:
diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c 
b/drivers/net/wireless/rt2x00/rt2x00config.c
index 46888f9..a1d8e33 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

> > > I've tried the patch but, unfortunately, my wireless LAN still dies after 
> > > a few pings.
> > 
> > Could you use below patch instead, and make a new dump of the register?
> > I'm still convinced the breakage occurs in the antenna diversity (or 
> > rather, I believe
> > it attempts a software diversity for your card while in fact it shouldn't).
> > 
> 
> Sorry, I've applied that patch and the LAN still dies after a few pings. BTW,

> this and the earlier patch both apply without error, but give warnings of 70
> line offsets. Were you expecting them to apply completely cleanly? I'm just
> wondering if there might be some code that you are expecting to be running (or
> not running) that is (or is not) present in the driver at 2.6.25-rc2.

Well to be honest I based the patch on rt2x00.git and not 2.6.25-rc2.
I know the patch would apply safely because the function that were changed
in that patch haven't changed between them. But some other functions were
moved. So that offset is correct. ;)

> The register dumps before and after are attached.

Thanks. I hope to have a new patch ready soon.

Ivo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

[added rt2400-devel (rt2x00 development mailinglist) to the CC list.]

> > > > I have a series of tests I would like to request from you,
> > > > you mentioned you already enabled debugfs, and that is just what we 
> > > > need. ;)
> > > > Please use attached script to create dumps of the hardware register 
> > > > contents.
> > > > 
> > > > There are specific moments that should be dumped:
> > > > - kernel 2.6.24 (last known working version for you).
> > > > - kernel 2.6.25-rc2 (after ifup, before TX dies)
> > > > - kernel 2.6.25-rc2 (after ifup, after TX dies)
> > > >  
> > > 
> > > These diagnostics are attached, with obvious filenames.
> > 
> > Thanks. I think I found something, please test below patch:
> > 
> 
> I've tried the patch but, unfortunately, my wireless LAN still dies after a 
> few pings.

Could you use below patch instead, and make a new dump of the register?
I'm still convinced the breakage occurs in the antenna diversity (or rather, I 
believe
it attempts a software diversity for your card while in fact it shouldn't).

> The frame dump diagnostics you asked for are attached. This is a fresh dump 
> taken
> tonight running the driver with your patch applied.

Thanks, I think I miss some information in that dump,
but that is okay for now.

Ivo

---

diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 015738a..65a512f 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -223,7 +223,7 @@ static void rt2x00lib_evaluate_antenna_eval(struct 
rt2x00_dev *rt2x00dev)
 * sample the rssi from the other antenna to make a valid
 * comparison between the 2 antennas.
 */
-   if ((rssi_curr - rssi_old) > -5 || (rssi_curr - rssi_old) < 5)
+   if (abs(rssi_curr - rssi_old) < 5)
return;
 
rt2x00dev->link.ant.flags |= ANTENNA_MODE_SAMPLE;
@@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev 
*rt2x00dev)
rt2x00dev->link.ant.flags &= ~ANTENNA_TX_DIVERSITY;
 
if (rt2x00dev->hw->conf.antenna_sel_rx == 0 &&
-   rt2x00dev->default_ant.rx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev->default_ant.rx == ANTENNA_SW_DIVERSITY)
rt2x00dev->link.ant.flags |= ANTENNA_RX_DIVERSITY;
if (rt2x00dev->hw->conf.antenna_sel_tx == 0 &&
-   rt2x00dev->default_ant.tx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev->default_ant.tx == ANTENNA_SW_DIVERSITY)
rt2x00dev->link.ant.flags |= ANTENNA_TX_DIVERSITY;
 
if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) &&

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

> > I have a series of tests I would like to request from you,
> > you mentioned you already enabled debugfs, and that is just what we need. ;)
> > Please use attached script to create dumps of the hardware register 
> > contents.
> > 
> > There are specific moments that should be dumped:
> > - kernel 2.6.24 (last known working version for you).
> > - kernel 2.6.25-rc2 (after ifup, before TX dies)
> > - kernel 2.6.25-rc2 (after ifup, after TX dies)
> >  
> 
> These diagnostics are attached, with obvious filenames.

Thanks. I think I found something, please test below patch:

---
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 015738a..8df1991 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev 
*rt2x00dev)
rt2x00dev->link.ant.flags &= ~ANTENNA_TX_DIVERSITY;
 
if (rt2x00dev->hw->conf.antenna_sel_rx == 0 &&
-   rt2x00dev->default_ant.rx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev->default_ant.rx == ANTENNA_SW_DIVERSITY)
rt2x00dev->link.ant.flags |= ANTENNA_RX_DIVERSITY;
if (rt2x00dev->hw->conf.antenna_sel_tx == 0 &&
-   rt2x00dev->default_ant.tx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev->default_ant.tx == ANTENNA_SW_DIVERSITY)
rt2x00dev->link.ant.flags |= ANTENNA_TX_DIVERSITY;
 
if (!(rt2x00dev->link.ant.flags & ANTENNA_RX_DIVERSITY) &&



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

  I have a series of tests I would like to request from you,
  you mentioned you already enabled debugfs, and that is just what we need. ;)
  Please use attached script to create dumps of the hardware register 
  contents.
  
  There are specific moments that should be dumped:
  - kernel 2.6.24 (last known working version for you).
  - kernel 2.6.25-rc2 (after ifup, before TX dies)
  - kernel 2.6.25-rc2 (after ifup, after TX dies)
   
 
 These diagnostics are attached, with obvious filenames.

Thanks. I think I found something, please test below patch:

---
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 015738a..8df1991 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev 
*rt2x00dev)
rt2x00dev-link.ant.flags = ~ANTENNA_TX_DIVERSITY;
 
if (rt2x00dev-hw-conf.antenna_sel_rx == 0 
-   rt2x00dev-default_ant.rx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev-default_ant.rx == ANTENNA_SW_DIVERSITY)
rt2x00dev-link.ant.flags |= ANTENNA_RX_DIVERSITY;
if (rt2x00dev-hw-conf.antenna_sel_tx == 0 
-   rt2x00dev-default_ant.tx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev-default_ant.tx == ANTENNA_SW_DIVERSITY)
rt2x00dev-link.ant.flags |= ANTENNA_TX_DIVERSITY;
 
if (!(rt2x00dev-link.ant.flags  ANTENNA_RX_DIVERSITY) 



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

[added rt2400-devel (rt2x00 development mailinglist) to the CC list.]

I have a series of tests I would like to request from you,
you mentioned you already enabled debugfs, and that is just what we 
need. ;)
Please use attached script to create dumps of the hardware register 
contents.

There are specific moments that should be dumped:
- kernel 2.6.24 (last known working version for you).
- kernel 2.6.25-rc2 (after ifup, before TX dies)
- kernel 2.6.25-rc2 (after ifup, after TX dies)
 
   
   These diagnostics are attached, with obvious filenames.
  
  Thanks. I think I found something, please test below patch:
  
 
 I've tried the patch but, unfortunately, my wireless LAN still dies after a 
 few pings.

Could you use below patch instead, and make a new dump of the register?
I'm still convinced the breakage occurs in the antenna diversity (or rather, I 
believe
it attempts a software diversity for your card while in fact it shouldn't).

 The frame dump diagnostics you asked for are attached. This is a fresh dump 
 taken
 tonight running the driver with your patch applied.

Thanks, I think I miss some information in that dump,
but that is okay for now.

Ivo

---

diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 015738a..65a512f 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -223,7 +223,7 @@ static void rt2x00lib_evaluate_antenna_eval(struct 
rt2x00_dev *rt2x00dev)
 * sample the rssi from the other antenna to make a valid
 * comparison between the 2 antennas.
 */
-   if ((rssi_curr - rssi_old)  -5 || (rssi_curr - rssi_old)  5)
+   if (abs(rssi_curr - rssi_old)  5)
return;
 
rt2x00dev-link.ant.flags |= ANTENNA_MODE_SAMPLE;
@@ -249,10 +249,10 @@ static void rt2x00lib_evaluate_antenna(struct rt2x00_dev 
*rt2x00dev)
rt2x00dev-link.ant.flags = ~ANTENNA_TX_DIVERSITY;
 
if (rt2x00dev-hw-conf.antenna_sel_rx == 0 
-   rt2x00dev-default_ant.rx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev-default_ant.rx == ANTENNA_SW_DIVERSITY)
rt2x00dev-link.ant.flags |= ANTENNA_RX_DIVERSITY;
if (rt2x00dev-hw-conf.antenna_sel_tx == 0 
-   rt2x00dev-default_ant.tx != ANTENNA_SW_DIVERSITY)
+   rt2x00dev-default_ant.tx == ANTENNA_SW_DIVERSITY)
rt2x00dev-link.ant.flags |= ANTENNA_TX_DIVERSITY;
 
if (!(rt2x00dev-link.ant.flags  ANTENNA_RX_DIVERSITY) 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

   I've tried the patch but, unfortunately, my wireless LAN still dies after 
   a few pings.
  
  Could you use below patch instead, and make a new dump of the register?
  I'm still convinced the breakage occurs in the antenna diversity (or 
  rather, I believe
  it attempts a software diversity for your card while in fact it shouldn't).
  
 
 Sorry, I've applied that patch and the LAN still dies after a few pings. BTW,

 this and the earlier patch both apply without error, but give warnings of 70
 line offsets. Were you expecting them to apply completely cleanly? I'm just
 wondering if there might be some code that you are expecting to be running (or
 not running) that is (or is not) present in the driver at 2.6.25-rc2.

Well to be honest I based the patch on rt2x00.git and not 2.6.25-rc2.
I know the patch would apply safely because the function that were changed
in that patch haven't changed between them. But some other functions were
moved. So that offset is correct. ;)

 The register dumps before and after are attached.

Thanks. I hope to have a new patch ready soon.

Ivo

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Almost forgot:

> > In 2.6.25 kernels, my wireless LAN dies after even the smallest amount
> > of network activity. The following screen cut shows what I typically
> > see:
> 
> How complete is this failure? Just TX or also RX?
> 
> Could you use the tools found here:
> http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html
> 
> and capture all TX/RX frames going through the hardware?
> Note that after the failure, this dumping facitilty should still report
> any ping request you might send to the interface.

Note that this feature is only present in 2.6.25.

> I have a series of tests I would like to request from you,
> you mentioned you already enabled debugfs, and that is just what we need. ;)
> Please use attached script to create dumps of the hardware register contents.

The debugfs register files were moved into a seperate folder somewhere between
2.6.24 and 2.6.25. This means you might have to edit the file slightly to make 
it
point to the correct location of the chipset file.

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

> In 2.6.25 kernels, my wireless LAN dies after even the smallest amount
> of network activity. The following screen cut shows what I typically
> see:

How complete is this failure? Just TX or also RX?

Could you use the tools found here:
http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html

and capture all TX/RX frames going through the hardware?
Note that after the failure, this dumping facitilty should still report
any ping request you might send to the interface.

> [chris:~]$ uname -a
> Linux laptop 2.6.25-rc2 #10 PREEMPT Sat Feb 16 09:53:04 UTC 2008 i686
> GNU/Linux
> [chris:~]$ ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) from 192.168.1.30 : 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=9.837 msec
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.148 msec
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=2.205 msec

I have a series of tests I would like to request from you,
you mentioned you already enabled debugfs, and that is just what we need. ;)
Please use attached script to create dumps of the hardware register contents.

There are specific moments that should be dumped:
- kernel 2.6.24 (last known working version for you).
- kernel 2.6.25-rc2 (after ifup, before TX dies)
- kernel 2.6.25-rc2 (after ifup, after TX dies)
 
> I will be more than happy to provide additional diagnostics, but
> please bear in mind that I am not a git user, so cannot do bisects. I
> am, however, perfectly capable of applying or reverting patches,
> rebuilding and re-testing, so I am quite happy to do that.

Above traces should be enough, but to determine where rt2x00 broke
down approximatly I need to have a few test result on specific moments.
Could you test the kernel with the following versions:

rt2x00 2.0.11   2d68de3efa62655d551092f5c787505735d561ad
rt2x00 2.0.12   a3c7aa58df7df80aa05f166fe3e42482247164cf
rt2x00 2.0.13   5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc

Checking those out is simply a matter of:
git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
git checkout 2.0.11

No further bisecting is needed, but with above tests I can at least
narrow it down to find the cause of this issue.

Thanks.

Ivo


debugfsdump.sh
Description: application/shellscript

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Hi,

 In 2.6.25 kernels, my wireless LAN dies after even the smallest amount
 of network activity. The following screen cut shows what I typically
 see:

How complete is this failure? Just TX or also RX?

Could you use the tools found here:
http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html

and capture all TX/RX frames going through the hardware?
Note that after the failure, this dumping facitilty should still report
any ping request you might send to the interface.

 [chris:~]$ uname -a
 Linux laptop 2.6.25-rc2 #10 PREEMPT Sat Feb 16 09:53:04 UTC 2008 i686
 GNU/Linux
 [chris:~]$ ping 192.168.1.1
 PING 192.168.1.1 (192.168.1.1) from 192.168.1.30 : 56(84) bytes of data.
 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=9.837 msec
 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.148 msec
 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=2.205 msec

I have a series of tests I would like to request from you,
you mentioned you already enabled debugfs, and that is just what we need. ;)
Please use attached script to create dumps of the hardware register contents.

There are specific moments that should be dumped:
- kernel 2.6.24 (last known working version for you).
- kernel 2.6.25-rc2 (after ifup, before TX dies)
- kernel 2.6.25-rc2 (after ifup, after TX dies)
 
 I will be more than happy to provide additional diagnostics, but
 please bear in mind that I am not a git user, so cannot do bisects. I
 am, however, perfectly capable of applying or reverting patches,
 rebuilding and re-testing, so I am quite happy to do that.

Above traces should be enough, but to determine where rt2x00 broke
down approximatly I need to have a few test result on specific moments.
Could you test the kernel with the following versions:

rt2x00 2.0.11   2d68de3efa62655d551092f5c787505735d561ad
rt2x00 2.0.12   a3c7aa58df7df80aa05f166fe3e42482247164cf
rt2x00 2.0.13   5a6012e105ae1664cd2841c33bf59fbdd8d4dbcc

Checking those out is simply a matter of:
git branch 2.0.11 2d68de3efa62655d551092f5c787505735d561ad
git checkout 2.0.11

No further bisecting is needed, but with above tests I can at least
narrow it down to find the cause of this issue.

Thanks.

Ivo


debugfsdump.sh
Description: application/shellscript

Re: 2.6.25-rc2 regression in rt61pci wireless driver

[Ivo van Doorn]

Almost forgot:

  In 2.6.25 kernels, my wireless LAN dies after even the smallest amount
  of network activity. The following screen cut shows what I typically
  see:
 
 How complete is this failure? Just TX or also RX?
 
 Could you use the tools found here:
 http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html
 
 and capture all TX/RX frames going through the hardware?
 Note that after the failure, this dumping facitilty should still report
 any ping request you might send to the interface.

Note that this feature is only present in 2.6.25.

 I have a series of tests I would like to request from you,
 you mentioned you already enabled debugfs, and that is just what we need. ;)
 Please use attached script to create dumps of the hardware register contents.

The debugfs register files were moved into a seperate folder somewhere between
2.6.24 and 2.6.25. This means you might have to edit the file slightly to make 
it
point to the correct location of the chipset file.

Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] wireless: rt2x00: fix driver menu indenting

[Ivo van Doorn]

On Sunday 10 February 2008, Randy Dunlap wrote:
> On Sat, 9 Feb 2008 16:23:06 +0100 Michael Büker wrote:
> 
> > 2) When selecting "Ralink driver support" (CONFIG_RT2X00), the accompanying 
> > drivers (CONFIG_RT2400PCI, CONFIG_RT61PC, ...) appear unindented. They 
> > should 
> > be indented by four spaces.
> 
> Yes, patch is below.
> 
> ---
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Michael Büker <[EMAIL PROTECTED]> reports that the RT2x00 drivers
> are not indented as they should be, so use proper dependencies to make
> them be indented as expected.
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

Ack-by: Ivo van Doorn <[EMAIL PROTECTED]>

---
John,
Could you push this directly into wireless-2.6 and probably upstream as well.

Thanks.

Ivo

> ---
>  drivers/net/wireless/rt2x00/Kconfig |   16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> --- linux-2.6.24-git21.orig/drivers/net/wireless/rt2x00/Kconfig
> +++ linux-2.6.24-git21/drivers/net/wireless/rt2x00/Kconfig
> @@ -11,18 +11,17 @@ config RT2X00
> will also be created. That library (when the driver is built as
> a module) will be called "rt2x00lib.ko".
>  
> +if RT2X00
> +
>  config RT2X00_LIB
>   tristate
> - depends on RT2X00
>  
>  config RT2X00_LIB_PCI
>   tristate
> - depends on RT2X00
>   select RT2X00_LIB
>  
>  config RT2X00_LIB_USB
>   tristate
> - depends on RT2X00
>   select RT2X00_LIB
>  
>  config RT2X00_LIB_FIRMWARE
> @@ -39,7 +38,7 @@ config RT2X00_LIB_RFKILL
>  
>  config RT2400PCI
>   tristate "Ralink rt2400 pci/pcmcia support"
> - depends on RT2X00 && PCI
> + depends on PCI
>   select RT2X00_LIB_PCI
>   select EEPROM_93CX6
>   ---help---
> @@ -58,7 +57,7 @@ config RT2400PCI_RFKILL
>  
>  config RT2500PCI
>   tristate "Ralink rt2500 pci/pcmcia support"
> - depends on RT2X00 && PCI
> + depends on PCI
>   select RT2X00_LIB_PCI
>   select EEPROM_93CX6
>   ---help---
> @@ -77,7 +76,7 @@ config RT2500PCI_RFKILL
>  
>  config RT61PCI
>   tristate "Ralink rt61 pci/pcmcia support"
> - depends on RT2X00 && PCI
> + depends on PCI
>   select RT2X00_LIB_PCI
>   select RT2X00_LIB_FIRMWARE
>   select EEPROM_93CX6
> @@ -97,7 +96,7 @@ config RT61PCI_RFKILL
>  
>  config RT2500USB
>   tristate "Ralink rt2500 usb support"
> - depends on RT2X00 && USB
> + depends on USB
>   select RT2X00_LIB_USB
>   ---help---
> This is an experimental driver for the Ralink rt2500 wireless chip.
> @@ -106,7 +105,7 @@ config RT2500USB
>  
>  config RT73USB
>   tristate "Ralink rt73 usb support"
> - depends on RT2X00 && USB
> + depends on USB
>   select RT2X00_LIB_USB
>   select RT2X00_LIB_FIRMWARE
>   ---help---
> @@ -128,3 +127,4 @@ config RT2X00_DEBUG
>   ---help---
> Enable debugging output for all rt2x00 modules
>  
> +endif
> 
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Rt2400-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/rt2400-devel
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] wireless: rt2x00: fix driver menu indenting

[Ivo van Doorn]

On Sunday 10 February 2008, Randy Dunlap wrote:
 On Sat, 9 Feb 2008 16:23:06 +0100 Michael Büker wrote:
 
  2) When selecting Ralink driver support (CONFIG_RT2X00), the accompanying 
  drivers (CONFIG_RT2400PCI, CONFIG_RT61PC, ...) appear unindented. They 
  should 
  be indented by four spaces.
 
 Yes, patch is below.
 
 ---
 From: Randy Dunlap [EMAIL PROTECTED]
 
 Michael Büker [EMAIL PROTECTED] reports that the RT2x00 drivers
 are not indented as they should be, so use proper dependencies to make
 them be indented as expected.
 
 Signed-off-by: Randy Dunlap [EMAIL PROTECTED]

Ack-by: Ivo van Doorn [EMAIL PROTECTED]

---
John,
Could you push this directly into wireless-2.6 and probably upstream as well.

Thanks.

Ivo

 ---
  drivers/net/wireless/rt2x00/Kconfig |   16 
  1 file changed, 8 insertions(+), 8 deletions(-)
 
 --- linux-2.6.24-git21.orig/drivers/net/wireless/rt2x00/Kconfig
 +++ linux-2.6.24-git21/drivers/net/wireless/rt2x00/Kconfig
 @@ -11,18 +11,17 @@ config RT2X00
 will also be created. That library (when the driver is built as
 a module) will be called rt2x00lib.ko.
  
 +if RT2X00
 +
  config RT2X00_LIB
   tristate
 - depends on RT2X00
  
  config RT2X00_LIB_PCI
   tristate
 - depends on RT2X00
   select RT2X00_LIB
  
  config RT2X00_LIB_USB
   tristate
 - depends on RT2X00
   select RT2X00_LIB
  
  config RT2X00_LIB_FIRMWARE
 @@ -39,7 +38,7 @@ config RT2X00_LIB_RFKILL
  
  config RT2400PCI
   tristate Ralink rt2400 pci/pcmcia support
 - depends on RT2X00  PCI
 + depends on PCI
   select RT2X00_LIB_PCI
   select EEPROM_93CX6
   ---help---
 @@ -58,7 +57,7 @@ config RT2400PCI_RFKILL
  
  config RT2500PCI
   tristate Ralink rt2500 pci/pcmcia support
 - depends on RT2X00  PCI
 + depends on PCI
   select RT2X00_LIB_PCI
   select EEPROM_93CX6
   ---help---
 @@ -77,7 +76,7 @@ config RT2500PCI_RFKILL
  
  config RT61PCI
   tristate Ralink rt61 pci/pcmcia support
 - depends on RT2X00  PCI
 + depends on PCI
   select RT2X00_LIB_PCI
   select RT2X00_LIB_FIRMWARE
   select EEPROM_93CX6
 @@ -97,7 +96,7 @@ config RT61PCI_RFKILL
  
  config RT2500USB
   tristate Ralink rt2500 usb support
 - depends on RT2X00  USB
 + depends on USB
   select RT2X00_LIB_USB
   ---help---
 This is an experimental driver for the Ralink rt2500 wireless chip.
 @@ -106,7 +105,7 @@ config RT2500USB
  
  config RT73USB
   tristate Ralink rt73 usb support
 - depends on RT2X00  USB
 + depends on USB
   select RT2X00_LIB_USB
   select RT2X00_LIB_FIRMWARE
   ---help---
 @@ -128,3 +127,4 @@ config RT2X00_DEBUG
   ---help---
 Enable debugging output for all rt2x00 modules
  
 +endif
 
 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 Rt2400-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/rt2400-devel
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

[Ivo van Doorn]

On Friday 26 October 2007, Roland Dreier wrote:
>  > The function that is returning ENODEV is the driver probe function. 
> According 
>  > to Documentation/DocBook/writing_usb_driver/ch03.html when that function 
> is 
>  > called 
>  > 
>  > "The driver now needs to verify that this device is actually one that it 
> can 
>  > accept. If so, it returns 0. If not, or if any error occurs during 
>  > initialization, an errorcode (such as -ENOMEM or -ENODEV) is returned from 
>  > the probe function."
>  > 
>  > It isn't a device the driver can accept so it returns -ENODEV
> 
> That's all true but irrelevant.  That error return isn't propagated
> back to userspace when it runs modprobe (and in fact it *can't* be
> sanely returned to userspace -- what do you do if the probe function
> succeeds for two devices and fails for a third?).  So there's not
> really any way for userspace to loop through a list of modules until
> one succeeds.

We are mixing 2 things up I think.

We have module loading, which is called when the module is loaded and
will register what PCI or USB devices it supports.
And we have hardware probing, which results in the kernel calling the probe()
function of the usb_driver or pci_driver structure.

The the return value of the module loading is not an issue, since indeed that 
is called
while the hardware might not be present.
The hardware probing _is_ called when the hardware is present, reason is simple,
hotplugging detects the new card and checks all registered USB/PCI ID's for a 
driver
that matches the device. If it matches the probe() function is called.
And that is where the ENODEV error could be checked, if the driver decides that 
the
plugged in device it was offere by the kernel is not a device it supports it 
needs
to tell that to the kernel. In turn the kernel can continue looking into the 
registered
USB/PCI ID lists to find a different driver that does support the hardware.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

[Ivo van Doorn]

On Friday 26 October 2007, Parag Warudkar wrote:
> 
> Hi Ivo
> 
> On Thu, 25 Oct 2007, Ivo van Doorn wrote:
> 
> > I awknowledge the problem, but the solution cannot be found in the USB ID's
> > listed in the driver. The bug is the manufacturer who changed chipset while
> > keeping the USB ID the same.
> > There are 2 possible ways around this: hacking the module loader so
> > it continues searching for a different driver when the first driver 
> > indicates
> > that it cannot control the device.
> > Or the easiest way, just blacklist rt2500usb if you are sure you need the 
> > rt73 driver.
> 
> Thanks for the heads up - I think you have a good idea - there should be 
> an interface between the loader and module to specify conditions like this.
> 
> I will see if I can generate interest in that idea and hack up something 
> along the lines of your suggestion.

Well it could be something quite simple, in the module loader it is looping
through all modules to look for a device with the correct USB/PCI ID.
Currently, after the first occurence it loads the module and doesn't continue,
it should perhaps be relatively easy that it checks if the driver returned 
-ENODEV
and continues looping to search for another driver.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

[Ivo van Doorn]

On Friday 26 October 2007, Parag Warudkar wrote:
 
 Hi Ivo
 
 On Thu, 25 Oct 2007, Ivo van Doorn wrote:
 
  I awknowledge the problem, but the solution cannot be found in the USB ID's
  listed in the driver. The bug is the manufacturer who changed chipset while
  keeping the USB ID the same.
  There are 2 possible ways around this: hacking the module loader so
  it continues searching for a different driver when the first driver 
  indicates
  that it cannot control the device.
  Or the easiest way, just blacklist rt2500usb if you are sure you need the 
  rt73 driver.
 
 Thanks for the heads up - I think you have a good idea - there should be 
 an interface between the loader and module to specify conditions like this.
 
 I will see if I can generate interest in that idea and hack up something 
 along the lines of your suggestion.

Well it could be something quite simple, in the module loader it is looping
through all modules to look for a device with the correct USB/PCI ID.
Currently, after the first occurence it loads the module and doesn't continue,
it should perhaps be relatively easy that it checks if the driver returned 
-ENODEV
and continues looping to search for another driver.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

[Ivo van Doorn]

On Friday 26 October 2007, Roland Dreier wrote:
   The function that is returning ENODEV is the driver probe function. 
 According 
   to Documentation/DocBook/writing_usb_driver/ch03.html when that function 
 is 
   called 
   
   The driver now needs to verify that this device is actually one that it 
 can 
   accept. If so, it returns 0. If not, or if any error occurs during 
   initialization, an errorcode (such as -ENOMEM or -ENODEV) is returned from 
   the probe function.
   
   It isn't a device the driver can accept so it returns -ENODEV
 
 That's all true but irrelevant.  That error return isn't propagated
 back to userspace when it runs modprobe (and in fact it *can't* be
 sanely returned to userspace -- what do you do if the probe function
 succeeds for two devices and fails for a third?).  So there's not
 really any way for userspace to loop through a list of modules until
 one succeeds.

We are mixing 2 things up I think.

We have module loading, which is called when the module is loaded and
will register what PCI or USB devices it supports.
And we have hardware probing, which results in the kernel calling the probe()
function of the usb_driver or pci_driver structure.

The the return value of the module loading is not an issue, since indeed that 
is called
while the hardware might not be present.
The hardware probing _is_ called when the hardware is present, reason is simple,
hotplugging detects the new card and checks all registered USB/PCI ID's for a 
driver
that matches the device. If it matches the probe() function is called.
And that is where the ENODEV error could be checked, if the driver decides that 
the
plugged in device it was offere by the kernel is not a device it supports it 
needs
to tell that to the kernel. In turn the kernel can continue looking into the 
registered
USB/PCI ID lists to find a different driver that does support the hardware.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

[Ivo van Doorn]

Hi,

> I have a Belkin USB Wireless adapter with ID 050d:705a.
> Both rt2500usb.c and rt73usb.c claim that they can drive the device with 
> this ID.
> 
> When using the distro kernel as well as custom 2.4.24-rc1 both rt73usb and 
> rt2500usb get loaded and fight for the register writes and fail. rt2500usb 
> is not able to drive my device. So I have to manually rmmod/modprobe or 
> delete rt2500usb.ko and depmod every time I get a new kernel.
> 
> If only rt73usb is loaded everything works well. To me it 
> sounds like rt2500usb should not be driving 050d:705a.
> 
> There is another ID 050d:7050 which is also claimed to be handled by both 
> rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no 
> way to be sure as I don't have device with this ID) the following patch 
> makes sure only rt73usb claims the 2 devices.

I awknowledge the problem, but the solution cannot be found in the USB ID's
listed in the driver. The bug is the manufacturer who changed chipset while
keeping the USB ID the same.
There are 2 possible ways around this: hacking the module loader so
it continues searching for a different driver when the first driver indicates
that it cannot control the device.
Or the easiest way, just blacklist rt2500usb if you are sure you need the rt73 
driver.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}

[Ivo van Doorn]

Hi,

 I have a Belkin USB Wireless adapter with ID 050d:705a.
 Both rt2500usb.c and rt73usb.c claim that they can drive the device with 
 this ID.
 
 When using the distro kernel as well as custom 2.4.24-rc1 both rt73usb and 
 rt2500usb get loaded and fight for the register writes and fail. rt2500usb 
 is not able to drive my device. So I have to manually rmmod/modprobe or 
 delete rt2500usb.ko and depmod every time I get a new kernel.
 
 If only rt73usb is loaded everything works well. To me it 
 sounds like rt2500usb should not be driving 050d:705a.
 
 There is another ID 050d:7050 which is also claimed to be handled by both 
 rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no 
 way to be sure as I don't have device with this ID) the following patch 
 makes sure only rt73usb claims the 2 devices.

I awknowledge the problem, but the solution cannot be found in the USB ID's
listed in the driver. The bug is the manufacturer who changed chipset while
keeping the USB ID the same.
There are 2 possible ways around this: hacking the module loader so
it continues searching for a different driver when the first driver indicates
that it cannot control the device.
Or the easiest way, just blacklist rt2500usb if you are sure you need the rt73 
driver.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers/net/wireless/rt2x00/: struct data_desc strangeness

[Ivo van Doorn]

Hi,

> > > I haven't checked whether it might work in all cases, but passing 
> > > non-zero values as second parameter to rt2x00_desc_{read,write}()
> > > (as is done in many cases) is even in the best case bad coding style.
> > 
> > Access to the array is correct, even with non-zero values the code that is
> > reading/writing to the array knows the exact size of the descriptor. Within
> > rt2x00 are however 5 drivers who have different descriptor sizes. That means
> > I can't create a structure which has the correct array length.
> > 
> > The structure itself is just a simple map over preallocated memory
> > (skb->data in case of USB or dma in case of PCI).
> > 
> > So possible solutions would be:
> >  - remove struct data_desc and make it a void* or __le32*
> >This is at the cost of code readibility since the above pointers
> >have less meaning then a pointer to a structure which can be nicely
> >documented.
> >...
> 
> The worst is a wrong meaning.
> __le32 word[1] is an array with _one_ element.
> 
> And an __le32* can be used as an array.

Ok. I'll fix this in 1 or 2 days.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers/net/wireless/rt2x00/: struct data_desc strangeness

[Ivo van Doorn]

Hi,

   I haven't checked whether it might work in all cases, but passing 
   non-zero values as second parameter to rt2x00_desc_{read,write}()
   (as is done in many cases) is even in the best case bad coding style.
  
  Access to the array is correct, even with non-zero values the code that is
  reading/writing to the array knows the exact size of the descriptor. Within
  rt2x00 are however 5 drivers who have different descriptor sizes. That means
  I can't create a structure which has the correct array length.
  
  The structure itself is just a simple map over preallocated memory
  (skb-data in case of USB or dma in case of PCI).
  
  So possible solutions would be:
   - remove struct data_desc and make it a void* or __le32*
 This is at the cost of code readibility since the above pointers
 have less meaning then a pointer to a structure which can be nicely
 documented.
 ...
 
 The worst is a wrong meaning.
 __le32 word[1] is an array with _one_ element.
 
 And an __le32* can be used as an array.

Ok. I'll fix this in 1 or 2 days.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

On Monday 22 October 2007, Pavel Machek wrote:
> Hi!
> 
> > > > This device is NOT a Ralink USB wifi adapter!
> > > > 
> > > > Get the windows driver in this link and see for yourself.
> > > > http://www.conitech.it/conitech/ita/risorse.asp?cod=CN402USB
> > > > (ISSC W89C35 802.11bg WLAN USB Adapters (Native Wifi driver))
> > > 
> > > Thanks a lot. With some patches, I got driver from conitech.it to
> > > compile and partly work on 2.6.23. I can now transmit packets but not
> > > yet receive them.
> > > 
> > > (use Makefile.26 instead of Makefile)
> > 
> > I couldn't find any license info immediately visible; are you sure it's
> > GPL?
> 
> Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.

That doesn't say much, some manufacturers add that line to their driver
 just to prevent the module loader complaining about a non-GPL driver...

There should be a copyright notice or a license file accompanied with
the driver that clearly states the license of the driver.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

On Monday 22 October 2007, Pavel Machek wrote:
 Hi!
 
This device is NOT a Ralink USB wifi adapter!

Get the windows driver in this link and see for yourself.
http://www.conitech.it/conitech/ita/risorse.asp?cod=CN402USB
(ISSC W89C35 802.11bg WLAN USB Adapters (Native Wifi driver))
   
   Thanks a lot. With some patches, I got driver from conitech.it to
   compile and partly work on 2.6.23. I can now transmit packets but not
   yet receive them.
   
   (use Makefile.26 instead of Makefile)
  
  I couldn't find any license info immediately visible; are you sure it's
  GPL?
 
 Yes, I'm quite sure. There's MODULE_LICENCE(GPL), IIRC.

That doesn't say much, some manufacturers add that line to their driver
 just to prevent the module loader complaining about a non-GPL driver...

There should be a copyright notice or a license file accompanied with
the driver that clearly states the license of the driver.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

On Sunday 21 October 2007, Pavel Machek wrote:
> On Sun 2007-10-21 15:49:44, Ivo van Doorn wrote:
> > On Sunday 21 October 2007, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
> > > > > 0x6206... I hope that to be compatible with
> > > > > net/wireless/rt2x00/rt73usb.c .
> > > > 
> > > > Is there any reason you assume it is a rt73usb device,
> > > > or are you just making wild guesses about what the chipset is?
> > > 
> > > Wild guess. I've seen 18e8:6XXX being handled by rt73usb, so..
> > 
> > Thats an incorrect assumption. USB ID's listed in rt73usb don't even
> > guarentee that the device contains a rt73usb chipset since some 
> > manufacturers
> > produce cards with different chipsets while keeping the USB ID the same.
> > So the case that the card false in the 6xxx range says absolutely _nothing_.
> 
> Well, see the other mail, it seems like rt73usb partially communicates
> with the card.

If you add a USB ID to the driver, then you are telling it to communciate to
the device. It doesn't suddenly make the driver compatible with the device.

> What info would be useful in determining what is this card similar to?
> Boot windows and look for driver name?

Looking at the name of the windows driver is indeed usually a good start,
but you don't need to boot to windows to check that. How about looking
at the driver name on the driver CD, or on the support website of the
manufacturer.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

Hi,

> > If rt2x00 is loaded and detected the device, it should print out a debug 
> > message that starts with:
> > "Chipset detected - " What is in your case the complete line?
> 
> Ok, I guess I should include more complete debug output.
> 
> phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x09 failed for 
> offset 0x with error -32

- Vendor requests error with the -32 errors often indicate the incorrect device.

> phy0 -> rt73usb_validate_eeprom: EEPROM recover - MAC: 66:76:2b:e8:68:e7

- Incorrect MAC address read from the device. Another hint that the device is 
not rt73.

> phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for 
> offset 0x3000 with error -32
> phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 1300, rf: , rev: 
> c03c0ae0

- A incorrect RF chipset. (valid values are: 1, 2, 3 or 4). Another indication 
of a incorrect device.
- A completely bogus chipset revision. A valid rt73 device has the revision 
"2573X" Where only the
  X is a variable.

> phy0 -> rt73usb_init_eeprom: Error - Invalid RF chipset detected
> 
> ...so, I think hardware is indeed quite similar to what rt73usb driver
> expects...?

No. You can assume you are forcing rt73 to control a non-rt73 device.
The fact that you had to hack to bypass the RT and RF chipset validation also 
confirms that,
those checks were there for a reason. Namely to make sure the corect driver was 
being used for the device.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

On Sunday 21 October 2007, Pavel Machek wrote:
> Hi!
> 
> > > Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
> > > 0x6206... I hope that to be compatible with
> > > net/wireless/rt2x00/rt73usb.c .
> > 
> > Is there any reason you assume it is a rt73usb device,
> > or are you just making wild guesses about what the chipset is?
> 
> Wild guess. I've seen 18e8:6XXX being handled by rt73usb, so..

Thats an incorrect assumption. USB ID's listed in rt73usb don't even
guarentee that the device contains a rt73usb chipset since some manufacturers
produce cards with different chipsets while keeping the USB ID the same.
So the case that the card false in the 6xxx range says absolutely _nothing_.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

On Sunday 21 October 2007, Pavel Machek wrote:
 Hi!
 
   Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
   0x6206... I hope that to be compatible with
   net/wireless/rt2x00/rt73usb.c .
  
  Is there any reason you assume it is a rt73usb device,
  or are you just making wild guesses about what the chipset is?
 
 Wild guess. I've seen 18e8:6XXX being handled by rt73usb, so..

Thats an incorrect assumption. USB ID's listed in rt73usb don't even
guarentee that the device contains a rt73usb chipset since some manufacturers
produce cards with different chipsets while keeping the USB ID the same.
So the case that the card false in the 6xxx range says absolutely _nothing_.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

Hi,

  If rt2x00 is loaded and detected the device, it should print out a debug 
  message that starts with:
  Chipset detected -  What is in your case the complete line?
 
 Ok, I guess I should include more complete debug output.
 
 phy0 - rt2x00usb_vendor_request: Error - Vendor Request 0x09 failed for 
 offset 0x with error -32

- Vendor requests error with the -32 errors often indicate the incorrect device.

 phy0 - rt73usb_validate_eeprom: EEPROM recover - MAC: 66:76:2b:e8:68:e7

- Incorrect MAC address read from the device. Another hint that the device is 
not rt73.

 phy0 - rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for 
 offset 0x3000 with error -32
 phy0 - rt2x00_set_chip: Info - Chipset detected - rt: 1300, rf: , rev: 
 c03c0ae0

- A incorrect RF chipset. (valid values are: 1, 2, 3 or 4). Another indication 
of a incorrect device.
- A completely bogus chipset revision. A valid rt73 device has the revision 
2573X Where only the
  X is a variable.

 phy0 - rt73usb_init_eeprom: Error - Invalid RF chipset detected
 
 ...so, I think hardware is indeed quite similar to what rt73usb driver
 expects...?

No. You can assume you are forcing rt73 to control a non-rt73 device.
The fact that you had to hack to bypass the RT and RF chipset validation also 
confirms that,
those checks were there for a reason. Namely to make sure the corect driver was 
being used for the device.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

On Sunday 21 October 2007, Pavel Machek wrote:
 On Sun 2007-10-21 15:49:44, Ivo van Doorn wrote:
  On Sunday 21 October 2007, Pavel Machek wrote:
   Hi!
   
 Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
 0x6206... I hope that to be compatible with
 net/wireless/rt2x00/rt73usb.c .

Is there any reason you assume it is a rt73usb device,
or are you just making wild guesses about what the chipset is?
   
   Wild guess. I've seen 18e8:6XXX being handled by rt73usb, so..
  
  Thats an incorrect assumption. USB ID's listed in rt73usb don't even
  guarentee that the device contains a rt73usb chipset since some 
  manufacturers
  produce cards with different chipsets while keeping the USB ID the same.
  So the case that the card false in the 6xxx range says absolutely _nothing_.
 
 Well, see the other mail, it seems like rt73usb partially communicates
 with the card.

If you add a USB ID to the driver, then you are telling it to communciate to
the device. It doesn't suddenly make the driver compatible with the device.

 What info would be useful in determining what is this card similar to?
 Boot windows and look for driver name?

Looking at the name of the windows driver is indeed usually a good start,
but you don't need to boot to windows to check that. How about looking
at the driver name on the driver CD, or on the support website of the
manufacturer.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

Hi,

> Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
> 0x6206... I hope that to be compatible with
> net/wireless/rt2x00/rt73usb.c .

Is there any reason you assume it is a rt73usb device,
or are you just making wild guesses about what the chipset is?

> [Sidenote: could we add some real author info into rt73usb.c?]

You mean expanding the project name to the full list of developers in
the project? I don't see any need for that.

> I did this on 2.6.23-rc8-mm1 kernel (The RT hack may not be
> neccessary), but then it oopses somewhere in softmac layer. I'll try
> to play with it some more.
> 
> If you have any ideas, let me know.
>   Pavel
> 
> --- clean-mm/drivers/net/wireless/rt2x00/rt73usb.c2007-10-09 
> 09:32:08.0 +0200
> +++ linux-mm/drivers/net/wireless/rt2x00/rt73usb.c2007-10-19 
> 22:19:45.0 +0200
> @@ -1580,7 +1580,6 @@
>  
>   if (!rt2x00_rev(>chip, 0x25730)) {
>   ERROR(rt2x00dev, "Invalid RT chipset detected.\n");
> - return -ENODEV;
>   }
>  
>   if (!rt2x00_rf(>chip, RF5226) &&
> @@ -1588,7 +1587,6 @@
>   !rt2x00_rf(>chip, RF5225) &&
>   !rt2x00_rf(>chip, RF2527)) {
>   ERROR(rt2x00dev, "Invalid RF chipset detected.\n");
> - return -ENODEV;
>   }

Both removals of -ENODEV are completely wrong. If the device does not pass the 
above
2 checks it is _not_ a rt73usb device. And forcing the driver to work with the 
device will
result in all kinds of problems.

If rt2x00 is loaded and detected the device, it should print out a debug 
message that starts with:
"Chipset detected - " What is in your case the complete line?

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook

[Ivo van Doorn]

Hi,

 Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
 0x6206... I hope that to be compatible with
 net/wireless/rt2x00/rt73usb.c .

Is there any reason you assume it is a rt73usb device,
or are you just making wild guesses about what the chipset is?

 [Sidenote: could we add some real author info into rt73usb.c?]

You mean expanding the project name to the full list of developers in
the project? I don't see any need for that.

 I did this on 2.6.23-rc8-mm1 kernel (The RT hack may not be
 neccessary), but then it oopses somewhere in softmac layer. I'll try
 to play with it some more.
 
 If you have any ideas, let me know.
   Pavel
 
 --- clean-mm/drivers/net/wireless/rt2x00/rt73usb.c2007-10-09 
 09:32:08.0 +0200
 +++ linux-mm/drivers/net/wireless/rt2x00/rt73usb.c2007-10-19 
 22:19:45.0 +0200
 @@ -1580,7 +1580,6 @@
  
   if (!rt2x00_rev(rt2x00dev-chip, 0x25730)) {
   ERROR(rt2x00dev, Invalid RT chipset detected.\n);
 - return -ENODEV;
   }
  
   if (!rt2x00_rf(rt2x00dev-chip, RF5226) 
 @@ -1588,7 +1587,6 @@
   !rt2x00_rf(rt2x00dev-chip, RF5225) 
   !rt2x00_rf(rt2x00dev-chip, RF2527)) {
   ERROR(rt2x00dev, Invalid RF chipset detected.\n);
 - return -ENODEV;
   }

Both removals of -ENODEV are completely wrong. If the device does not pass the 
above
2 checks it is _not_ a rt73usb device. And forcing the driver to work with the 
device will
result in all kinds of problems.

If rt2x00 is loaded and detected the device, it should print out a debug 
message that starts with:
Chipset detected -  What is in your case the complete line?

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] jiffies_round -> jiffies_round_relative conversion - rt2x00

[Ivo van Doorn]

On Monday 15 October 2007, Anton Blanchard wrote:
> 
> When rounding a relative timeout we need to use round_jiffies_relative(). 
> 
> Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
Acked-by: Ivo van Doorn <[EMAIL PROTECTED]>

> ---
> 
> diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h 
> b/drivers/net/wireless/rt2x00/rt2x00lib.h
> index 298faa9..06d9bc0 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00lib.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
> @@ -30,7 +30,7 @@
>   * Interval defines
>   * Both the link tuner as the rfkill will be called once per second.
>   */
> -#define LINK_TUNE_INTERVAL   ( round_jiffies(HZ) )
> +#define LINK_TUNE_INTERVAL   ( round_jiffies_relative(HZ) )
>  #define RFKILL_POLL_INTERVAL ( 1000 )
>  
>  /*
> 
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> Rt2400-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/rt2400-devel
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Rt2400-devel] [PATCH] jiffies_round - jiffies_round_relative conversion - rt2x00

[Ivo van Doorn]

On Monday 15 October 2007, Anton Blanchard wrote:
 
 When rounding a relative timeout we need to use round_jiffies_relative(). 
 
 Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
Acked-by: Ivo van Doorn [EMAIL PROTECTED]

 ---
 
 diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h 
 b/drivers/net/wireless/rt2x00/rt2x00lib.h
 index 298faa9..06d9bc0 100644
 --- a/drivers/net/wireless/rt2x00/rt2x00lib.h
 +++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
 @@ -30,7 +30,7 @@
   * Interval defines
   * Both the link tuner as the rfkill will be called once per second.
   */
 -#define LINK_TUNE_INTERVAL   ( round_jiffies(HZ) )
 +#define LINK_TUNE_INTERVAL   ( round_jiffies_relative(HZ) )
  #define RFKILL_POLL_INTERVAL ( 1000 )
  
  /*
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Rt2400-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/rt2400-devel
 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers/net/wireless/rt2x00/: struct data_desc strangeness

[Ivo van Doorn]

On Sunday 14 October 2007, Adrian Bunk wrote:
> drivers/net/wireless/rt2x00/rt2x00ring.h contains the following:
> 
> <--  snip  -->
> 
> ...
> /*
>  * data_desc
>  * Each data entry also contains a descriptor which is used by the
>  * device to determine what should be done with the packet and
>  * what the current status is.
>  * This structure is greatly simplified, but the descriptors
>  * are basically a list of little endian 32 bit values.
>  * Make the array by default 1 word big, this will allow us
>  * to use sizeof() correctly.
>  */
> struct data_desc {
> __le32 word[1];
> };
> ...
> /*
>  * TX/RX Descriptor access functions.
>  */
> static inline void rt2x00_desc_read(struct data_desc *desc,
> const u8 word, u32 *value)
> {
> *value = le32_to_cpu(desc->word[word]);
> }
> 
> static inline void rt2x00_desc_write(struct data_desc *desc,
>  const u8 word, const u32 value)
> {
> desc->word[word] = cpu_to_le32(value);
> }
> ...
> 
> <--  snip  -->
> 
> I haven't checked whether it might work in all cases, but passing 
> non-zero values as second parameter to rt2x00_desc_{read,write}()
> (as is done in many cases) is even in the best case bad coding style.

Access to the array is correct, even with non-zero values the code that is
reading/writing to the array knows the exact size of the descriptor. Within
rt2x00 are however 5 drivers who have different descriptor sizes. That means
I can't create a structure which has the correct array length.

The structure itself is just a simple map over preallocated memory
(skb->data in case of USB or dma in case of PCI).

So possible solutions would be:
 - remove struct data_desc and make it a void* or __le32*
   This is at the cost of code readibility since the above pointers
   have less meaning then a pointer to a structure which can be nicely
   documented.
 - increase the word[] array to something that fits all (+/- 20 entries)
   This wouldn't really be a problem, all it requires is fixing the sizeof() 
   statements. But then the code should contain a big note about that it
   is not allowed to read/write _all_ words in the entry since it depends on
   the driver that uses it.

What would in this case be the best solution for good coding style?

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: drivers/net/wireless/rt2x00/: struct data_desc strangeness

[Ivo van Doorn]

On Sunday 14 October 2007, Adrian Bunk wrote:
 drivers/net/wireless/rt2x00/rt2x00ring.h contains the following:
 
 --  snip  --
 
 ...
 /*
  * data_desc
  * Each data entry also contains a descriptor which is used by the
  * device to determine what should be done with the packet and
  * what the current status is.
  * This structure is greatly simplified, but the descriptors
  * are basically a list of little endian 32 bit values.
  * Make the array by default 1 word big, this will allow us
  * to use sizeof() correctly.
  */
 struct data_desc {
 __le32 word[1];
 };
 ...
 /*
  * TX/RX Descriptor access functions.
  */
 static inline void rt2x00_desc_read(struct data_desc *desc,
 const u8 word, u32 *value)
 {
 *value = le32_to_cpu(desc-word[word]);
 }
 
 static inline void rt2x00_desc_write(struct data_desc *desc,
  const u8 word, const u32 value)
 {
 desc-word[word] = cpu_to_le32(value);
 }
 ...
 
 --  snip  --
 
 I haven't checked whether it might work in all cases, but passing 
 non-zero values as second parameter to rt2x00_desc_{read,write}()
 (as is done in many cases) is even in the best case bad coding style.

Access to the array is correct, even with non-zero values the code that is
reading/writing to the array knows the exact size of the descriptor. Within
rt2x00 are however 5 drivers who have different descriptor sizes. That means
I can't create a structure which has the correct array length.

The structure itself is just a simple map over preallocated memory
(skb-data in case of USB or dma in case of PCI).

So possible solutions would be:
 - remove struct data_desc and make it a void* or __le32*
   This is at the cost of code readibility since the above pointers
   have less meaning then a pointer to a structure which can be nicely
   documented.
 - increase the word[] array to something that fits all (+/- 20 entries)
   This wouldn't really be a problem, all it requires is fixing the sizeof() 
   statements. But then the code should contain a big note about that it
   is not allowed to read/write _all_ words in the entry since it depends on
   the driver that uses it.

What would in this case be the best solution for good coding style?

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc3-mm1: net/wireless/rt2x00mac.c build failure

[Ivo van Doorn]

Hi,

>   CC [M]  drivers/net/wireless/zd1211rw-mac80211/zd_mac.o
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: In function 
> `zd_op_erp_ie_changed':
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: 
> `IEEE80211_ERP_CHANGE_PREAMBLE' undeclared (first use in this function)
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: (Each undeclared 
> identifier is reported only once
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: for each function 
> it appears in.)
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: At top level:
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: error: unknown field 
> `erp_ie_changed' specified in initializer
> drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: warning: initialization 
> from incompatible pointer type
> make[4]: *** [drivers/net/wireless/zd1211rw-mac80211/zd_mac.o] Error 1
> make[3]: *** [drivers/net/wireless/zd1211rw-mac80211] Error 2
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2

I'm not a zd1211rw developer, but a quick look into the patch series it seems
that the mac80211 version in -mm1 does not contain the patch
[PATCH 4/4] mac80211: implement ERP info change notifications
But it does contain the zd1211rw patch:
[PATCH] zd1211rw-mac80211: use correct preambles for RTS/CTS frames
Which depended on the above mentioned mac80211 patch.

Just had a second thought about those rt2x00 compilation errors you reported,
the error is not caused by rt2x00 lagging behind mac80211 api changes but
that rt2x00 patches to follow the api changes are going upstream but
the mac80211 api changes it depends on are not going anywhere.

It seems that mac80211 has not been updated in the -mm tree while the
drivers have been updated. This is causing the compilation errors for both
rt2x00 as zd1211rw.
I'll bet that if you try any other mac80211 driver similar issues will arise.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc3-mm1: net/wireless/rt2x00mac.c build failure

[Ivo van Doorn]

Hi,

>   CC [M]  drivers/net/wireless/rt2x00mac.o
> drivers/net/wireless/rt2x00mac.c: In function `rt2x00mac_tx_rts_cts':
> drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 2 of 
> `ieee80211_ctstoself_get' makes pointer from integer without a cast
> drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 3 of 
> `ieee80211_ctstoself_get' makes integer from pointer without a cast
> drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 4 of 
> `ieee80211_ctstoself_get' makes pointer from integer without a cast
> drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 5 of 
> `ieee80211_ctstoself_get' from incompatible pointer type
> drivers/net/wireless/rt2x00mac.c:61: error: too many arguments to function 
> `ieee80211_ctstoself_get'
> drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 2 of 
> `ieee80211_rts_get' makes pointer from integer without a cast
> drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 3 of 
> `ieee80211_rts_get' makes integer from pointer without a cast
> drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 4 of 
> `ieee80211_rts_get' makes pointer from integer without a cast
> drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 5 of 
> `ieee80211_rts_get' from incompatible pointer type
> drivers/net/wireless/rt2x00mac.c:65: error: too many arguments to function 
> `ieee80211_rts_get'
> make[3]: *** [drivers/net/wireless/rt2x00mac.o] Error 1
> make[2]: *** [drivers/net/wireless] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2

This has been fixed for quite some time already.
John, I can't check this myself now, but which rt2x00
patches have gone into the -mm tree? Since I believe
the patch that changed ieee80211_ctstoself_get was
followed by a patch to fix rt2x00 within the same series...

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc3-mm1: net/wireless/rt2x00mac.c build failure

[Ivo van Doorn]

Hi,

   CC [M]  drivers/net/wireless/rt2x00mac.o
 drivers/net/wireless/rt2x00mac.c: In function `rt2x00mac_tx_rts_cts':
 drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 2 of 
 `ieee80211_ctstoself_get' makes pointer from integer without a cast
 drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 3 of 
 `ieee80211_ctstoself_get' makes integer from pointer without a cast
 drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 4 of 
 `ieee80211_ctstoself_get' makes pointer from integer without a cast
 drivers/net/wireless/rt2x00mac.c:61: warning: passing arg 5 of 
 `ieee80211_ctstoself_get' from incompatible pointer type
 drivers/net/wireless/rt2x00mac.c:61: error: too many arguments to function 
 `ieee80211_ctstoself_get'
 drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 2 of 
 `ieee80211_rts_get' makes pointer from integer without a cast
 drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 3 of 
 `ieee80211_rts_get' makes integer from pointer without a cast
 drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 4 of 
 `ieee80211_rts_get' makes pointer from integer without a cast
 drivers/net/wireless/rt2x00mac.c:65: warning: passing arg 5 of 
 `ieee80211_rts_get' from incompatible pointer type
 drivers/net/wireless/rt2x00mac.c:65: error: too many arguments to function 
 `ieee80211_rts_get'
 make[3]: *** [drivers/net/wireless/rt2x00mac.o] Error 1
 make[2]: *** [drivers/net/wireless] Error 2
 make[1]: *** [drivers/net] Error 2
 make: *** [drivers] Error 2

This has been fixed for quite some time already.
John, I can't check this myself now, but which rt2x00
patches have gone into the -mm tree? Since I believe
the patch that changed ieee80211_ctstoself_get was
followed by a patch to fix rt2x00 within the same series...

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc3-mm1: net/wireless/rt2x00mac.c build failure

[Ivo van Doorn]

Hi,

   CC [M]  drivers/net/wireless/zd1211rw-mac80211/zd_mac.o
 drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: In function 
 `zd_op_erp_ie_changed':
 drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: 
 `IEEE80211_ERP_CHANGE_PREAMBLE' undeclared (first use in this function)
 drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: (Each undeclared 
 identifier is reported only once
 drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:822: error: for each function 
 it appears in.)
 drivers/net/wireless/zd1211rw-mac80211/zd_mac.c: At top level:
 drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: error: unknown field 
 `erp_ie_changed' specified in initializer
 drivers/net/wireless/zd1211rw-mac80211/zd_mac.c:844: warning: initialization 
 from incompatible pointer type
 make[4]: *** [drivers/net/wireless/zd1211rw-mac80211/zd_mac.o] Error 1
 make[3]: *** [drivers/net/wireless/zd1211rw-mac80211] Error 2
 make[2]: *** [drivers/net/wireless] Error 2
 make[1]: *** [drivers/net] Error 2
 make: *** [drivers] Error 2

I'm not a zd1211rw developer, but a quick look into the patch series it seems
that the mac80211 version in -mm1 does not contain the patch
[PATCH 4/4] mac80211: implement ERP info change notifications
But it does contain the zd1211rw patch:
[PATCH] zd1211rw-mac80211: use correct preambles for RTS/CTS frames
Which depended on the above mentioned mac80211 patch.

Just had a second thought about those rt2x00 compilation errors you reported,
the error is not caused by rt2x00 lagging behind mac80211 api changes but
that rt2x00 patches to follow the api changes are going upstream but
the mac80211 api changes it depends on are not going anywhere.

It seems that mac80211 has not been updated in the -mm tree while the
drivers have been updated. This is causing the compilation errors for both
rt2x00 as zd1211rw.
I'll bet that if you try any other mac80211 driver similar issues will arise.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

> > 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 that case ./net would be good.

> > > Does this make sense?
> >
> > Yes, but what if the user loads both modules or has them both compiled in?
> > Shouldn't there be some protection against that, since both handlers should 
> > not
> > be active at the same time.
> 
> Why not? evdev is just a delivery transport for input events to
> userspace. Even if user wants the kernel to control state of RF
> switches (which I expect most users woudl want) there still could be
> applications interested in knowing that used turned off wireless. And
> if userspace really wishes to control switch all by itself it can
> "claim" it.

Right, I forgot about that user_claim thingy. ;)

> I guess what you are missing is that input event generated by a device
> is pushed through every handler bound to the device so there is no way
> for a "wrong" handler to "steals" an event from "right" handler. They
> all work simultaneously.
> 
> > > > personally I would prefer enforcing drivers to call
> > > > allocate()
> > > > register()
> > > > unregister()
> > > > free()
> > > >
> > > > Especially with unregister() doing the same steps as free() (put_device)
> > > > might be somwhat confusing. But might be just me. ;)
> > > >
> > >
> > > I know but for refcounted objects you can't really tell when they will
> > > actually be freed. It depends when their last user drops off.
> >
> > Then perhaps rfkill_register could call put_device() when it fails, and 
> > free()
> > can be removed entirely. That way it would we prevent some driver
> > to call free() anyway.
> >
> 
> That would make error handling in ->probe() methods a bit unwieldy I
> think - if you are using the standard "goto err_xxx; goto err_yyy;"
> technique then you have to conditionally call rfkill_free(). Hovewer
> if register simply fails and does not free anything and you call
> rfkill_register() last (which you need to do because driver has to be
> almost fully functional to be able to serve toggle_radio calls) you
> can always call rfkill_free() if something fails.

Ok.

Well that would mean rfkill would be ready to applied to one of the kernel 
trees right? :)
The first user of rfkill would be rt2x00, which is in wireless-dev as well as 
-mm.
The second user could be the driver from Lennart, but I haven't heard from him 
quite a while
(although he is on the CC list) so I am not sure if his MSI driver can be fixed 
to use rfkill. His MSI
driver is already in the linus' tree.
A third user could be bcm43xx but I don't know how far they are with hardware 
key detection and
status reading (to make it work with rfkill), perhaps Larry could give more 
information about that.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

  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 that case ./net would be good.

   Does this make sense?
 
  Yes, but what if the user loads both modules or has them both compiled in?
  Shouldn't there be some protection against that, since both handlers should 
  not
  be active at the same time.
 
 Why not? evdev is just a delivery transport for input events to
 userspace. Even if user wants the kernel to control state of RF
 switches (which I expect most users woudl want) there still could be
 applications interested in knowing that used turned off wireless. And
 if userspace really wishes to control switch all by itself it can
 claim it.

Right, I forgot about that user_claim thingy. ;)

 I guess what you are missing is that input event generated by a device
 is pushed through every handler bound to the device so there is no way
 for a wrong handler to steals an event from right handler. They
 all work simultaneously.
 
personally I would prefer enforcing drivers to call
allocate()
register()
unregister()
free()
   
Especially with unregister() doing the same steps as free() (put_device)
might be somwhat confusing. But might be just me. ;)
   
  
   I know but for refcounted objects you can't really tell when they will
   actually be freed. It depends when their last user drops off.
 
  Then perhaps rfkill_register could call put_device() when it fails, and 
  free()
  can be removed entirely. That way it would we prevent some driver
  to call free() anyway.
 
 
 That would make error handling in -probe() methods a bit unwieldy I
 think - if you are using the standard goto err_xxx; goto err_yyy;
 technique then you have to conditionally call rfkill_free(). Hovewer
 if register simply fails and does not free anything and you call
 rfkill_register() last (which you need to do because driver has to be
 almost fully functional to be able to serve toggle_radio calls) you
 can always call rfkill_free() if something fails.

Ok.

Well that would mean rfkill would be ready to applied to one of the kernel 
trees right? :)
The first user of rfkill would be rt2x00, which is in wireless-dev as well as 
-mm.
The second user could be the driver from Lennart, but I haven't heard from him 
quite a while
(although he is on the CC list) so I am not sure if his MSI driver can be fixed 
to use rfkill. His MSI
driver is already in the linus' tree.
A third user could be bcm43xx but I don't know how far they are with hardware 
key detection and
status reading (to make it work with rfkill), perhaps Larry could give more 
information about that.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

> > > 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 provides basic functionality that most of the users need
> > > and any advanced control will have to be done from userspace.
> >
> > Shouldn't a KEY_IRDA be added as well?
> > It isn't currently defined in input.h yet, but perhaps it actually should?
> > Or is IRDA treated differently for a specific reason?
> 
> Do we actually have cards with IRDA switches? We are kind of tight in
> input KEY_ namespace so I am hesitant to add defines before there
> actual users.

Ah ok. Well that shouldn't be a problem, IRDA could be added once there
are users for it. I am not sure if there are any devices with IRDA switches,
so it shouldn't be a big problem.

> > > In a followup patch there is a skeleton code for creating polled
> > > input devices. For cards that have button physically connected
> > > their drivers will have to register a separate input device and
> > > let either input handler or userspace application take care of
> > > switching RF state appropriately.
> > >
> > > 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 drivers/input.
> >
> > How about:
> > rfkill -> drivers/misc
> 
> Not in net?

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.

> > rfkill_input -> input/misc
> 
> I can go both ways on this one as it crosses line between input and
> rfkill. I think from user/Kconfig point of view it is better to keep
> it together with rfkill: user woudl select rfkill option and right
> then and there decide if he wants to give the kernel ability to
> automatically control RF switche

Makes sense.

> > input_polldev -> lib/ (perhaps small namechange to rfkill_polldev?)
> 
> No, I do not want to change name - I have bunch of drivers that can me
> converted to use this skeleton - wistron, aaedkbd, hdaps, ams,
> cobalt_btns. It is also pure input-related function so it is the only
> module that definitely belongs to drivers/input/misc.

Ok. :)

> > It would scatter the components a bit, but since each of those modules
> > has its own specific task this would make the most sense.
> > And by setting the depends and select fields for the menu entries correctly
> > it shouldn't be too big of a problem.
> >
> > > Please let me know what you think.
> >
> > Just to get it straight on how these 3 modules would cooperate (before I 
> > start mixing things up) ;)
> >
> >  - rfkill
> >- Drivers register to the rfkill module, rfkill
> >- Provides the sysfs interface
> >- Drivers that don't require polling should report the events to 
> > this module
> 
> Not quite. Drivers that have buttons do not require polling still
> should create an input device and register it with input layer. Except
> that with interrupt-driven devices there is not much you can stub out
> so you just have to do input_allocate_device/input_register_device.
> 
> >
> >  - rfkill_input
> >- Provides input device visible to userspace
> >
> 
> No, rfkill-input is not an input device but input handler (or input
> interface). It routes input events from buttons into switches (see
> below).
> 
> >  - input_polldev
> >- Handlers polling, where the driver should check what the previous 
> > state was and the driver
> >  should send the event to rfkill.
> 
> This is the input device visible to userspace and kernel. It polls
> state of the button and sends KEY_WLAN/KEY_BLUETOOTH events through
> input layer. They get distributed through various input handlers such
> as evdev and rfkill-input. Evdev provides route for events to
> userspace where application can listen to events and then toggle RF
> switches according to the current policy via
> /sys/class/rfkill/rfkillXXX/state. Rfkill-input provides in-kernel
> route for events into rfkill system. If rfkill-input is loaded
> switches that are not claimed by userspace will be toggled
> automatically.
> 
> Does this make sense?

Yes, but what if the user loads both modules or has them both compiled in?
Shouldn't there be some protection against that, since both handlers should not
be active at the same time.

> Note that we don't start polling the state of button until tare are
> users of that input device. If rfkill-input is loaded then there is a
> user right away. Otherwise we wait for userspace to open evdev node.

Sounds good.

> > personally I would prefer enforcing drivers to call
> > allocate()
> > register()
> > unregister()

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

[Ivo van Doorn]

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, created and destroyed independently of each other. This way
> everything handled uniformly by the kernel.

ok. Sounds good as well. :)

> I attempted to rework the rfkill core supprt and simplify it and
> came up with the patch below. Network card drivers that are able
> to control state of their RF transmitters allocate and register
> rfkill structures. Every rfkill structure belongs to one of
> RF classes (WLAN, Bluetooth or IRDA) and exports its name, type,
> state and "user_claim" through sysfs.
> 
> 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 provides basic functionality that most of the users need
> and any advanced control will have to be done from userspace.

Shouldn't a KEY_IRDA be added as well?
It isn't currently defined in input.h yet, but perhaps it actually should?
Or is IRDA treated differently for a specific reason?

> In a followup patch there is a skeleton code for creating polled
> input devices. For cards that have button physically connected
> their drivers will have to register a separate input device and
> let either input handler or userspace application take care of
> switching RF state appropriately.
>
> 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 drivers/input.

How about:
rfkill -> drivers/misc
rfkill_input -> input/misc
input_polldev -> lib/ (perhaps small namechange to rfkill_polldev?)
It would scatter the components a bit, but since each of those modules
has its own specific task this would make the most sense.
And by setting the depends and select fields for the menu entries correctly
it shouldn't be too big of a problem.

> Please let me know what you think.

Just to get it straight on how these 3 modules would cooperate (before I start 
mixing things up) ;)

 - rfkill
- Drivers register to the rfkill module, rfkill 
- Provides the sysfs interface
- Drivers that don't require polling should report the events to this 
module

 - rfkill_input
- Provides input device visible to userspace

 - input_polldev
- Handlers polling, where the driver should check what the previous 
state was and the driver
  should send the event to rfkill.

Could input_polldev perhaps not be setup to poll, and keep track of the current 
button status
and send the signal directly to rfkill?

What I am also not sure of is that input_polldev and rfkill_input both register 
a input device.
Instead of starting and stopping the polling through the input device it would 
perhaps make more
sense to either use the input device from rfkill_input and/or make use of a 
sysfs attribute.

> +/**
> + * rfkill_unregister - Uegister a rfkill structure.
> + * @rfkill: rfkill structure to be unregistered
> + *
> + * This function should be called by the network driver during device
> + * teardown to destroy rfkill structure. Note that rfkill_free() should
> + * _not_ be called after rfkill_unregister().
> + */
> +void rfkill_unregister(struct rfkill *rfkill)
> +{
> +   device_del(>dev);
> +   rfkill_remove_switch(rfkill);
> +   put_device(>dev);
> +}
> +EXPORT_SYMBOL(rfkill_unregister);

personally I would prefer enforcing drivers to call
allocate()
register()
unregister()
free()

Especially with unregister() doing the same steps as free() (put_device)
might be somwhat confusing. But might be just me. ;)

The remainder looks good, unfortunately I can't test it since the laptop with 
an rfkill button I have
requires isn't in a state for testing at this moment, and I would need to 
figure out how button status
reading happens in bcm43xx.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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, created and destroyed independently of each other. This way
 everything handled uniformly by the kernel.

ok. Sounds good as well. :)

 I attempted to rework the rfkill core supprt and simplify it and
 came up with the patch below. Network card drivers that are able
 to control state of their RF transmitters allocate and register
 rfkill structures. Every rfkill structure belongs to one of
 RF classes (WLAN, Bluetooth or IRDA) and exports its name, type,
 state and user_claim through sysfs.
 
 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 provides basic functionality that most of the users need
 and any advanced control will have to be done from userspace.

Shouldn't a KEY_IRDA be added as well?
It isn't currently defined in input.h yet, but perhaps it actually should?
Or is IRDA treated differently for a specific reason?

 In a followup patch there is a skeleton code for creating polled
 input devices. For cards that have button physically connected
 their drivers will have to register a separate input device and
 let either input handler or userspace application take care of
 switching RF state appropriately.

 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 drivers/input.

How about:
rfkill - drivers/misc
rfkill_input - input/misc
input_polldev - lib/ (perhaps small namechange to rfkill_polldev?)
It would scatter the components a bit, but since each of those modules
has its own specific task this would make the most sense.
And by setting the depends and select fields for the menu entries correctly
it shouldn't be too big of a problem.

 Please let me know what you think.

Just to get it straight on how these 3 modules would cooperate (before I start 
mixing things up) ;)

 - rfkill
- Drivers register to the rfkill module, rfkill 
- Provides the sysfs interface
- Drivers that don't require polling should report the events to this 
module

 - rfkill_input
- Provides input device visible to userspace

 - input_polldev
- Handlers polling, where the driver should check what the previous 
state was and the driver
  should send the event to rfkill.

Could input_polldev perhaps not be setup to poll, and keep track of the current 
button status
and send the signal directly to rfkill?

What I am also not sure of is that input_polldev and rfkill_input both register 
a input device.
Instead of starting and stopping the polling through the input device it would 
perhaps make more
sense to either use the input device from rfkill_input and/or make use of a 
sysfs attribute.

 +/**
 + * rfkill_unregister - Uegister a rfkill structure.
 + * @rfkill: rfkill structure to be unregistered
 + *
 + * This function should be called by the network driver during device
 + * teardown to destroy rfkill structure. Note that rfkill_free() should
 + * _not_ be called after rfkill_unregister().
 + */
 +void rfkill_unregister(struct rfkill *rfkill)
 +{
 +   device_del(rfkill-dev);
 +   rfkill_remove_switch(rfkill);
 +   put_device(rfkill-dev);
 +}
 +EXPORT_SYMBOL(rfkill_unregister);

personally I would prefer enforcing drivers to call
allocate()
register()
unregister()
free()

Especially with unregister() doing the same steps as free() (put_device)
might be somwhat confusing. But might be just me. ;)

The remainder looks good, unfortunately I can't test it since the laptop with 
an rfkill button I have
requires isn't in a state for testing at this moment, and I would need to 
figure out how button status
reading happens in bcm43xx.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

   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 provides basic functionality that most of the users need
   and any advanced control will have to be done from userspace.
 
  Shouldn't a KEY_IRDA be added as well?
  It isn't currently defined in input.h yet, but perhaps it actually should?
  Or is IRDA treated differently for a specific reason?
 
 Do we actually have cards with IRDA switches? We are kind of tight in
 input KEY_ namespace so I am hesitant to add defines before there
 actual users.

Ah ok. Well that shouldn't be a problem, IRDA could be added once there
are users for it. I am not sure if there are any devices with IRDA switches,
so it shouldn't be a big problem.

   In a followup patch there is a skeleton code for creating polled
   input devices. For cards that have button physically connected
   their drivers will have to register a separate input device and
   let either input handler or userspace application take care of
   switching RF state appropriately.
  
   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 drivers/input.
 
  How about:
  rfkill - drivers/misc
 
 Not in net?

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.

  rfkill_input - input/misc
 
 I can go both ways on this one as it crosses line between input and
 rfkill. I think from user/Kconfig point of view it is better to keep
 it together with rfkill: user woudl select rfkill option and right
 then and there decide if he wants to give the kernel ability to
 automatically control RF switche

Makes sense.

  input_polldev - lib/ (perhaps small namechange to rfkill_polldev?)
 
 No, I do not want to change name - I have bunch of drivers that can me
 converted to use this skeleton - wistron, aaedkbd, hdaps, ams,
 cobalt_btns. It is also pure input-related function so it is the only
 module that definitely belongs to drivers/input/misc.

Ok. :)

  It would scatter the components a bit, but since each of those modules
  has its own specific task this would make the most sense.
  And by setting the depends and select fields for the menu entries correctly
  it shouldn't be too big of a problem.
 
   Please let me know what you think.
 
  Just to get it straight on how these 3 modules would cooperate (before I 
  start mixing things up) ;)
 
   - rfkill
 - Drivers register to the rfkill module, rfkill
 - Provides the sysfs interface
 - Drivers that don't require polling should report the events to 
  this module
 
 Not quite. Drivers that have buttons do not require polling still
 should create an input device and register it with input layer. Except
 that with interrupt-driven devices there is not much you can stub out
 so you just have to do input_allocate_device/input_register_device.
 
 
   - rfkill_input
 - Provides input device visible to userspace
 
 
 No, rfkill-input is not an input device but input handler (or input
 interface). It routes input events from buttons into switches (see
 below).
 
   - input_polldev
 - Handlers polling, where the driver should check what the previous 
  state was and the driver
   should send the event to rfkill.
 
 This is the input device visible to userspace and kernel. It polls
 state of the button and sends KEY_WLAN/KEY_BLUETOOTH events through
 input layer. They get distributed through various input handlers such
 as evdev and rfkill-input. Evdev provides route for events to
 userspace where application can listen to events and then toggle RF
 switches according to the current policy via
 /sys/class/rfkill/rfkillXXX/state. Rfkill-input provides in-kernel
 route for events into rfkill system. If rfkill-input is loaded
 switches that are not claimed by userspace will be toggled
 automatically.
 
 Does this make sense?

Yes, but what if the user loads both modules or has them both compiled in?
Shouldn't there be some protection against that, since both handlers should not
be active at the same time.

 Note that we don't start polling the state of button until tare are
 users of that input device. If rfkill-input is loaded then there is a
 user right away. Otherwise we wait for userspace to open evdev node.

Sounds good.

  personally I would prefer enforcing drivers to call
  allocate()
  register()
  unregister()
  free()
 
  Especially with unregister() doing the same steps as free() (put_device)
  might be somwhat confusing. But might be just me. ;)
 
 
 I know but for 

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

[Ivo van Doorn]

> 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 promised in last mail.
(mutex, workqueue api, etc)

Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>



diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate "RF button support"
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..d8fda73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,999 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("Ivo van Doorn <[EMAIL PROTECTED]>");
+MODULE_VERSION("1.0");
+MODULE_DESCRIPTION("RF key support");
+MODULE_LICENSE("GPL");
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   const struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+*/
+#define RFKILL_KEY_RADIO_STATUS1
+
+   unsigned long flags;
+
+   /*
+* Input device for this key.
+*/
+   struct input_dev *input;
+
+   /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+   struct list_head entry;
+};
+
+/*
+ * rfkill type structure.
+ */
+struct rfkill_type {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* All access to the type structure and its
+* children (the keys) are protected by this mutex.
+*/
+   struct mutex mutex;
+
+   /*
+* Name of this radio type.
+*/
+   char *name;
+
+   /*
+* Key type identification. Value must be any
+* in the key_type enum.
+*/
+   unsigned int key_type;
+
+   /*
+* List of rfkill_key structures.
+*/
+   struct list_head key_list;
+
+   /*
+* Number of registered keys of this type.
+*/
+   unsigned int key_count;
+
+   /*
+* The claim the user has over the toggling of the radi

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

[Ivo van Doorn]

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 toggled
> > +* field should be set to indicate a notification to
> > +* user or driver should be performed.
> > +*/
> > +   int toggled;
> > +
> > +   /*
> > +* Current state of the device radio, this state will
> > +* change after the radio has actually been toggled since
> > +* receiving the radio key event.
> > +*/
> > +   int radio_status;
> > +
> > +   /*
> > +* Current status of the key which controls the radio,
> > +* this value will change after the key state has changed
> > +* after polling, or the key driver has send the new state
> > +* manually.
> > +*/
> > +   int key_status;
> 
> 
> Maybe turn these bits into a bit values (set_bit/clear_bit) in an unsigned 
> long.

Will do.

> > +   /*
> > +* Input device for this key,
> > +* we also keep track of the number of
> > +* times this input device is open. This
> > +* is important for determining to whom we
> > +* should report key events.
> > +*/
> > +   struct input_dev *input;
> > +   unsigned int open_count;
> 
> atomic on open_count?

There seems to have gone something wrong with the patch,
latest version should have had this field removed.

> > +   /*
> > +* Name of this radio type.
> > +*/
> > +   char *name;
> 
> const?

Will do.

> > +   /*
> > +* All access to the master structure
> > +* and its children (the keys) are protected
> > +* by this key lock.
> > +*/
> > +   struct semaphore key_sem;
> 
> mutex instead of semaphort

Strange, this should have already be fixed. :S

> > +   /*
> > +* Work structures for periodic polling,
> > +* as well as the scheduled radio toggling.
> > +*/
> > +   struct work_struct toggle_work;
> > +   struct work_struct poll_work;
> 
> delayed_rearming_work instead?

Same here, rfkill should already have the new workqueue api...

I'll resubmit this within a few moments.

Thanks

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 toggled
  +* field should be set to indicate a notification to
  +* user or driver should be performed.
  +*/
  +   int toggled;
  +
  +   /*
  +* Current state of the device radio, this state will
  +* change after the radio has actually been toggled since
  +* receiving the radio key event.
  +*/
  +   int radio_status;
  +
  +   /*
  +* Current status of the key which controls the radio,
  +* this value will change after the key state has changed
  +* after polling, or the key driver has send the new state
  +* manually.
  +*/
  +   int key_status;
 
 
 Maybe turn these bits into a bit values (set_bit/clear_bit) in an unsigned 
 long.

Will do.

  +   /*
  +* Input device for this key,
  +* we also keep track of the number of
  +* times this input device is open. This
  +* is important for determining to whom we
  +* should report key events.
  +*/
  +   struct input_dev *input;
  +   unsigned int open_count;
 
 atomic on open_count?

There seems to have gone something wrong with the patch,
latest version should have had this field removed.

  +   /*
  +* Name of this radio type.
  +*/
  +   char *name;
 
 const?

Will do.

  +   /*
  +* All access to the master structure
  +* and its children (the keys) are protected
  +* by this key lock.
  +*/
  +   struct semaphore key_sem;
 
 mutex instead of semaphort

Strange, this should have already be fixed. :S

  +   /*
  +* Work structures for periodic polling,
  +* as well as the scheduled radio toggling.
  +*/
  +   struct work_struct toggle_work;
  +   struct work_struct poll_work;
 
 delayed_rearming_work instead?

Same here, rfkill should already have the new workqueue api...

I'll resubmit this within a few moments.

Thanks

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

 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 promised in last mail.
(mutex, workqueue api, etc)

Signed-off-by Ivo van Doorn [EMAIL PROTECTED]



diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate RF button support
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..d8fda73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,999 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   const struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+*/
+#define RFKILL_KEY_RADIO_STATUS1
+
+   unsigned long flags;
+
+   /*
+* Input device for this key.
+*/
+   struct input_dev *input;
+
+   /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+   struct list_head entry;
+};
+
+/*
+ * rfkill type structure.
+ */
+struct rfkill_type {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* All access to the type structure and its
+* children (the keys) are protected by this mutex.
+*/
+   struct mutex mutex;
+
+   /*
+* Name of this radio type.
+*/
+   char *name;
+
+   /*
+* Key type identification. Value must be any
+* in the key_type enum.
+*/
+   unsigned int key_type;
+
+   /*
+* List of rfkill_key structures.
+*/
+   struct list_head key_list;
+
+   /*
+* Number of registered keys of this type.
+*/
+   unsigned int key_count;
+
+   /*
+* The claim the user has

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

[Ivo van Doorn]

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 been completely removed, decision making on which action 
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
 1 - let rfkill handle everything without bothering the user
 2 - let rfkill handle everything but send a notification to the user
 3 - let rfkill send a notification only

The toggling of the keys is now type based, this means that if 1 key is being 
toggled
all keys of the same type will be toggled.

As optimization and clearly seperate the keys per type, the rfkill_type 
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.

sysfs will hold the following entries:

- The main folder: "rfkill"
- The main folder contains the type folders "wlan", "bluetooth" and "irda".
- Each type folder contains the files
- "claim" where the user claim can be read/written
- "status" The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- "status" The status of this key
- "idev" The symlink to the input device entry in sysfs
        - "dev" The symlink to the drivers device entry in sysfs

Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>

---

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate "RF button support"
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..6719962
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,988 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("Ivo van Doorn <[EMAIL PROTECTED]>");
+MODULE_VERSION("1.0");
+MODULE_DESCRIPTION("RF key support");
+MODULE_LICENSE("GPL");
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change af

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

[Ivo van Doorn]

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 been completely removed, decision making on which action 
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
 1 - let rfkill handle everything without bothering the user
 2 - let rfkill handle everything but send a notification to the user
 3 - let rfkill send a notification only

The toggling of the keys is now type based, this means that if 1 key is being 
toggled
all keys of the same type will be toggled.

As optimization and clearly seperate the keys per type, the rfkill_type 
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.

sysfs will hold the following entries:

- The main folder: rfkill
- The main folder contains the type folders wlan, bluetooth and irda.
- Each type folder contains the files
- claim where the user claim can be read/written
- status The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- status The status of this key
- idev The symlink to the input device entry in sysfs
- dev The symlink to the drivers device entry in sysfs

Signed-off-by Ivo van Doorn [EMAIL PROTECTED]

---

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate RF button support
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..6719962
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,988 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send

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

[Ivo van Doorn]

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 
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
 1 - let rfkill handle everything without bothering the user
 2 - let rfkill handle everything but send a notification to the user
 3 - let rfkill send a notification only

The toggling of the keys is now type based, this means that if 1 key is being 
toggled
all keys of the same type will be toggled.

As optimization and clearly seperate the keys per type, the rfkill_type 
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.

sysfs will hold the following entries:

- The main folder: "rfkill"
- The main folder contains the type folders "wlan", "bluetooth" and "irda".
- Each type folder contains the files
- "claim" where the user claim can be read/written
- "status" The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- "status" The status of this key
- "idev" The symlink to the input device entry in sysfs
        - "dev" The symlink to the drivers device entry in sysfs

Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>

---

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..e58c0bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,20 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate "RF button support"
+   depends on SYSFS
+   help
+ If you say yes here, the rfkill driver will be built
+ which allows network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..065ff56
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,986 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("Ivo van Doorn <[EMAIL PROTECTED]>");
+MODULE_VERSION("1.0");
+MODULE_DESCRIPTION("RF key support");
+MODULE_LICENSE("GPL");
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+   

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

[Ivo van Doorn]

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 
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
 1 - let rfkill handle everything without bothering the user
 2 - let rfkill handle everything but send a notification to the user
 3 - let rfkill send a notification only

The toggling of the keys is now type based, this means that if 1 key is being 
toggled
all keys of the same type will be toggled.

As optimization and clearly seperate the keys per type, the rfkill_type 
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.

sysfs will hold the following entries:

- The main folder: rfkill
- The main folder contains the type folders wlan, bluetooth and irda.
- Each type folder contains the files
- claim where the user claim can be read/written
- status The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- status The status of this key
- idev The symlink to the input device entry in sysfs
- dev The symlink to the drivers device entry in sysfs

Signed-off-by Ivo van Doorn [EMAIL PROTECTED]

---

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..e58c0bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,20 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate RF button support
+   depends on SYSFS
+   help
+ If you say yes here, the rfkill driver will be built
+ which allows network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..065ff56
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,986 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually

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

[Ivo Van Doorn]

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 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...
>
> Without a handler like rfkill, it does nothing besides toggling a bit in a 
register.
> The Ralink chipsets have a couple of registers that represent the state of 
that key.
> Besides that, there are no notifications to the userspace nor does it 
directly control the
> radio.
> That is where rfkill came in with the toggle handler that will listen to the 
register
> to check if the key has been pressed and properly process the key event.

In this case the driver can make the button state available to userspace so
thsi is really type 2) driver as far as I can see. The fact that the button
is not reported to userspace yet should not get into our way of classifying
it.


I was indeed considering it as a type 2) device.
I am currently working on revising the rfkill driver to work as you suggested,
so I hope to have a new patch ready for you soon.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo Van Doorn]

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 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...

 Without a handler like rfkill, it does nothing besides toggling a bit in a 
register.
 The Ralink chipsets have a couple of registers that represent the state of 
that key.
 Besides that, there are no notifications to the userspace nor does it 
directly control the
 radio.
 That is where rfkill came in with the toggle handler that will listen to the 
register
 to check if the key has been pressed and properly process the key event.

In this case the driver can make the button state available to userspace so
thsi is really type 2) driver as far as I can see. The fact that the button
is not reported to userspace yet should not get into our way of classifying
it.


I was indeed considering it as a type 2) device.
I am currently working on revising the rfkill driver to work as you suggested,
so I hope to have a new patch ready for you soon.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 
> > 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...

Without a handler like rfkill, it does nothing besides toggling a bit in a 
register.
The Ralink chipsets have a couple of registers that represent the state of that 
key.
Besides that, there are no notifications to the userspace nor does it directly 
control the
radio.
That is where rfkill came in with the toggle handler that will listen to the 
register
to check if the key has been pressed and properly process the key event.

> > 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).

Ok, this is something that can be added as notice in the rfkill description
to make sure drivers which supports keys that handle the radio event themselves
should handle everything themselves and just use the KEY_RFKILL event for the
input device.

> > > 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.

Ok, this means making the change in rfkill to instead support 1) and 2)
and change it into 2) and 3) that would be possible and would make it possible
again to change the radio state to something different then the key indicates.
That was previously removed because of support for 1) devices.

> ...
> > >
> > > 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 :)
> 

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 
> > don't send anything to
> > userspace (unless the ACPI event is read) and does not directly control the 
> > radio itself.
> 
> My take: if there is a button on your keyboard or laptop labeled "Kill
> my radio now", it _NEEDS_ to be somehow communicated to userspace what
> happened when the user just pressed it a second ago.  Personally, I
> don't particularly care how that happens, and I don't particularly care
> what the driver does.  But if the driver, or the hardware, decides that
> the button press means turning off the transmitter on whatever device
> that button is for, a tool like NetworkManager needs to know this
> somehow.  Ideally, this would be a HAL event, and HAL would get it from
> somewhere.
>
> The current situation with NM is unacceptable, and I can't do anything
> about it because there is no standard interface for determining whether
> the wireless card was disabled/enabled via rfkill.  I simply refuse to
> code solutions to every vendor's rfkill mechanism (for ipw, reading
> iwpriv or sysfs, for example).  I don't care how HAL gets the event, but
> when HAL gets the event, it needs to broadcast it and NM needs to tear
> down the connection and release the device.
> 
> That means (a) an event gets sent to userspace in some way that HAL can
> read it, and (b) the event is clearly associated with specific piece[s]
> of hardware on your system.  If HAL can't easily figure out what device
> the event is for, then the event is also useless to both HAL and
> NetworkManager and whatever else might use it.

This would be possible with rfkill and the ideas from Dmitry.
The vendors that have a button that directly toggle the radio, should
create an input device themselves and just send the KEY_RFKILL event when 
toggled.

All other types should use rfkill for the toggling handling, that way HAL only 
needs to
listen to KEY_RFKILL coming from the input devices that are associated to the 
keys.

> Again, I don't care how that happens, but I like the fact that there's
> renewed interest in getting this fixed.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 
  don't send anything to
  userspace (unless the ACPI event is read) and does not directly control the 
  radio itself.
 
 My take: if there is a button on your keyboard or laptop labeled Kill
 my radio now, it _NEEDS_ to be somehow communicated to userspace what
 happened when the user just pressed it a second ago.  Personally, I
 don't particularly care how that happens, and I don't particularly care
 what the driver does.  But if the driver, or the hardware, decides that
 the button press means turning off the transmitter on whatever device
 that button is for, a tool like NetworkManager needs to know this
 somehow.  Ideally, this would be a HAL event, and HAL would get it from
 somewhere.

 The current situation with NM is unacceptable, and I can't do anything
 about it because there is no standard interface for determining whether
 the wireless card was disabled/enabled via rfkill.  I simply refuse to
 code solutions to every vendor's rfkill mechanism (for ipw, reading
 iwpriv or sysfs, for example).  I don't care how HAL gets the event, but
 when HAL gets the event, it needs to broadcast it and NM needs to tear
 down the connection and release the device.
 
 That means (a) an event gets sent to userspace in some way that HAL can
 read it, and (b) the event is clearly associated with specific piece[s]
 of hardware on your system.  If HAL can't easily figure out what device
 the event is for, then the event is also useless to both HAL and
 NetworkManager and whatever else might use it.

This would be possible with rfkill and the ideas from Dmitry.
The vendors that have a button that directly toggle the radio, should
create an input device themselves and just send the KEY_RFKILL event when 
toggled.

All other types should use rfkill for the toggling handling, that way HAL only 
needs to
listen to KEY_RFKILL coming from the input devices that are associated to the 
keys.

 Again, I don't care how that happens, but I like the fact that there's
 renewed interest in getting this fixed.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 
  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...

Without a handler like rfkill, it does nothing besides toggling a bit in a 
register.
The Ralink chipsets have a couple of registers that represent the state of that 
key.
Besides that, there are no notifications to the userspace nor does it directly 
control the
radio.
That is where rfkill came in with the toggle handler that will listen to the 
register
to check if the key has been pressed and properly process the key event.

  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).

Ok, this is something that can be added as notice in the rfkill description
to make sure drivers which supports keys that handle the radio event themselves
should handle everything themselves and just use the KEY_RFKILL event for the
input device.

   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.

Ok, this means making the change in rfkill to instead support 1) and 2)
and change it into 2) and 3) that would be possible and would make it possible
again to change the radio state to something different then the key indicates.
That was previously removed because of support for 1) devices.

 ...
  
   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 :)
 

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 belong to rfkill interface. I do not understand the need for 2nd
> > > interface. If you separate radio switch from button code then
> > > userspace only need to implement 1st interface and be done with it.
> > > You will have set of cards that provide interface to enable/disable
> > > their transmitters and set of buttons that signal userspace desired
> > > state change. If both switch and button is implemented by the same
> > > driver then the driver can implement automatic button handling.
> > > Otherwise userspace help is necessary.
> >
> > Well there are 3 possible hardware key approaches:
> >
> >  1 - Hardware key that controls the hardware radio, and does not report 
> > anything to userspace
> 
> Can't do anything here so just ignore it.

Ok.

> >  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.

> >  3 - Hardware key that does not control the hardware radio and reports the 
> > key to userspace
> >
> > So rfkill should not be used in the case of (1) and (3), but we still need 
> > something to support (2)
> > or should the keys not be handled by userspace and always by the driver?
> > This is making rfkill moving slowly away from the generic approach for all 
> > rfkill keys as the initial
> > intention was.
> >
> 
> I my "vision" rfkill would represent userspace namageable radio
> switch. We have the followng possible configurations:
> 
> 1. A device that does not allow controlling its transmitter from
> userspace. The driver should not use/register with rfkill subsystem as
> userspace can't do anyhting with it. If device has a button killing
> the transmitter the driver can still signal userspace appropriate
> event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was
> presssed so userspace can monitor state of the transmitter and
> probably shut down other transmitters to keep everything in sync.

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. ;)

Because it could still register with rfkill, only not give the callback 
functions
for changing the radio or polling. Then the driver can use the send_event 
function
to inform rfkill of the event and process it further. The sysfs attributes could
even be reduced to only add the change_status attribute when the radio_enable
and radio_disable callback functions are implemented.

> 2. A device that does allow controlling its transmitter. The driver
> may (should) register with rfkill subsystem. Additionally, if there is
> a button, the driver should register it with input subsystem. Driver
> should manage transmitter state in response to button presses unless
> userspace takes over the process.

This is indeed the main goal of rfkill. :)

> 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.

> > > > > attribute should be a tri-state on/off/auto, "auto" meaning the driver
> > > > > itself manages radio state. This would avoid another tacky IMHO point
> > > > > that in your implementation mere opening of an input device takes over
> > > > > RF driver. Explicit control allow applications "snoop" RF state
> > > > > without disturbing it.
> > > >
> > > > Currently userspace can always check the state of the button whenever
> > > > they like by checking the sysfs entry.
> > > >
> > >
> > > Unless the key is not directly connected to the driver (so there is no
> > > sysfs entry). Again you force 2 different interfaces.
> >
> > Ok, so input device opening should not block the rfkill signal and the 
> > rfkill handler
> > should still go through with its work unless 

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

[Ivo van Doorn]

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 is done via BIOS SMM (see
> > > wistron driver) or there is no special button at all and users might
> > > want to assign one of their standard keyboard buttons to be an RF
> > > switch.
> >
> > Making sure rfkill supports keys that are not handled by the driver
> > is a bit hard. Just as drivers that can only check if the button is
> > toggled and not what the current state is.
> > The problem is that it is hard to make a clean split between the
> > 2 different button controls. Not all drivers allow the radio to be
> > enabled while the button status are indicating the radio should
> > be off.
> 
> If they do not allow controlling the state of the radio
> programmatically then it should not be part of rfkill I am afraid. It
> is like the power switch - if you hold it for so long it kills the
> power to the box and there is nothing you can do about it.

Ok, this will give rfkill more possibilities as I could in that case
also allow the user to toggle the radio to the state that is different
than indicated by the key.
Currently this was not possible since I had to keep in mind that there
were keys that would directly control the radio.

> > The buttons that are already integrated into the keyboard,
> > by example by using a Fn key combo don't control the device
> > directly. So the driver cannot offer anything to the rfkill driver.
> > Such buttons should be mapped in userspace without the help of rfkill,
> > since the kernel cannot detect if that key belonged to a radio
> > control key or not.
> >
> 
> 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 belong to rfkill interface. I do not understand the need for 2nd
> interface. If you separate radio switch from button code then
> userspace only need to implement 1st interface and be done with it.
> You will have set of cards that provide interface to enable/disable
> their transmitters and set of buttons that signal userspace desired
> state change. If both switch and button is implemented by the same
> driver then the driver can implement automatic button handling.
> Otherwise userspace help is necessary.

Well there are 3 possible hardware key approaches:

 1 - Hardware key that controls the hardware radio, and does not report 
anything to userspace
 2 - Hardware key that does not control the hardware radio and does not report 
anything to userspace
 3 - Hardware key that does not control the hardware radio and reports the key 
to userspace

So rfkill should not be used in the case of (1) and (3), but we still need 
something to support (2)
or should the keys not be handled by userspace and always by the driver?
This is making rfkill moving slowly away from the generic approach for all 
rfkill keys as the initial
intention was.

> > > attribute should be a tri-state on/off/auto, "auto" meaning the driver
> > > itself manages radio state. This would avoid another tacky IMHO point
> > > that in your implementation mere opening of an input device takes over
> > > RF driver. Explicit control allow applications "snoop" RF state
> > > without disturbing it.
> >
> > Currently userspace can always check the state of the button whenever
> > they like by checking the sysfs entry.
> >
> 
> Unless the key is not directly connected to the driver (so there is no
> sysfs entry). Again you force 2 different interfaces.

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
userspace wants to handle the event.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 is done via BIOS SMM (see
   wistron driver) or there is no special button at all and users might
   want to assign one of their standard keyboard buttons to be an RF
   switch.
 
  Making sure rfkill supports keys that are not handled by the driver
  is a bit hard. Just as drivers that can only check if the button is
  toggled and not what the current state is.
  The problem is that it is hard to make a clean split between the
  2 different button controls. Not all drivers allow the radio to be
  enabled while the button status are indicating the radio should
  be off.
 
 If they do not allow controlling the state of the radio
 programmatically then it should not be part of rfkill I am afraid. It
 is like the power switch - if you hold it for so long it kills the
 power to the box and there is nothing you can do about it.

Ok, this will give rfkill more possibilities as I could in that case
also allow the user to toggle the radio to the state that is different
than indicated by the key.
Currently this was not possible since I had to keep in mind that there
were keys that would directly control the radio.

  The buttons that are already integrated into the keyboard,
  by example by using a Fn key combo don't control the device
  directly. So the driver cannot offer anything to the rfkill driver.
  Such buttons should be mapped in userspace without the help of rfkill,
  since the kernel cannot detect if that key belonged to a radio
  control key or not.
 
 
 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 belong to rfkill interface. I do not understand the need for 2nd
 interface. If you separate radio switch from button code then
 userspace only need to implement 1st interface and be done with it.
 You will have set of cards that provide interface to enable/disable
 their transmitters and set of buttons that signal userspace desired
 state change. If both switch and button is implemented by the same
 driver then the driver can implement automatic button handling.
 Otherwise userspace help is necessary.

Well there are 3 possible hardware key approaches:

 1 - Hardware key that controls the hardware radio, and does not report 
anything to userspace
 2 - Hardware key that does not control the hardware radio and does not report 
anything to userspace
 3 - Hardware key that does not control the hardware radio and reports the key 
to userspace

So rfkill should not be used in the case of (1) and (3), but we still need 
something to support (2)
or should the keys not be handled by userspace and always by the driver?
This is making rfkill moving slowly away from the generic approach for all 
rfkill keys as the initial
intention was.

   attribute should be a tri-state on/off/auto, auto meaning the driver
   itself manages radio state. This would avoid another tacky IMHO point
   that in your implementation mere opening of an input device takes over
   RF driver. Explicit control allow applications snoop RF state
   without disturbing it.
 
  Currently userspace can always check the state of the button whenever
  they like by checking the sysfs entry.
 
 
 Unless the key is not directly connected to the driver (so there is no
 sysfs entry). Again you force 2 different interfaces.

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
userspace wants to handle the event.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 belong to rfkill interface. I do not understand the need for 2nd
   interface. If you separate radio switch from button code then
   userspace only need to implement 1st interface and be done with it.
   You will have set of cards that provide interface to enable/disable
   their transmitters and set of buttons that signal userspace desired
   state change. If both switch and button is implemented by the same
   driver then the driver can implement automatic button handling.
   Otherwise userspace help is necessary.
 
  Well there are 3 possible hardware key approaches:
 
   1 - Hardware key that controls the hardware radio, and does not report 
  anything to userspace
 
 Can't do anything here so just ignore it.

Ok.

   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.

   3 - Hardware key that does not control the hardware radio and reports the 
  key to userspace
 
  So rfkill should not be used in the case of (1) and (3), but we still need 
  something to support (2)
  or should the keys not be handled by userspace and always by the driver?
  This is making rfkill moving slowly away from the generic approach for all 
  rfkill keys as the initial
  intention was.
 
 
 I my vision rfkill would represent userspace namageable radio
 switch. We have the followng possible configurations:
 
 1. A device that does not allow controlling its transmitter from
 userspace. The driver should not use/register with rfkill subsystem as
 userspace can't do anyhting with it. If device has a button killing
 the transmitter the driver can still signal userspace appropriate
 event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was
 presssed so userspace can monitor state of the transmitter and
 probably shut down other transmitters to keep everything in sync.

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. ;)

Because it could still register with rfkill, only not give the callback 
functions
for changing the radio or polling. Then the driver can use the send_event 
function
to inform rfkill of the event and process it further. The sysfs attributes could
even be reduced to only add the change_status attribute when the radio_enable
and radio_disable callback functions are implemented.

 2. A device that does allow controlling its transmitter. The driver
 may (should) register with rfkill subsystem. Additionally, if there is
 a button, the driver should register it with input subsystem. Driver
 should manage transmitter state in response to button presses unless
 userspace takes over the process.

This is indeed the main goal of rfkill. :)

 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.

 attribute should be a tri-state on/off/auto, auto meaning the driver
 itself manages radio state. This would avoid another tacky IMHO point
 that in your implementation mere opening of an input device takes over
 RF driver. Explicit control allow applications snoop RF state
 without disturbing it.
   
Currently userspace can always check the state of the button whenever
they like by checking the sysfs entry.
   
  
   Unless the key is not directly connected to the driver (so there is no
   sysfs entry). Again you force 2 different interfaces.
 
  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
  userspace wants to handle the event.
 
 
 I don't think a config option is a good idea unless by config option
 

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

[Ivo van Doorn]

[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))
> > +   schedule_work(>toggle_work);
> > +
> > +   mutex_unlock(>mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(rfkill_report_event);
> 
> Please use kernel-doc notation for non-static functions.
> See Documentation/kernel-doc-nano-HOWTO.txt for more info.

All kernel-doc notations were placed in the rfkill.h header.
I'll move them to the rfkill.c file.


[snip]

> > + * @rfkill: rfkill structure to be deregistered
> > + * @init_status: initial status of the key at the time this function is 
> > called
> > + *
> > + * This function should be called by the key driver when the rfkill 
> > structure
> > + * needs to be registered. Immediately from registration the key driver
> > + * should be able to receive calls through the poll, enable_radio and
> > + * disable_radio handlers if those were registered.
> > + */
> > +int rfkill_register_key(struct rfkill *rfkill, int init_status);
> > +
> > +/**
> > + * rfkill_deregister_key - Deregister a previously registered rfkill 
> > structre.
> 
> "structure"

Thanks for the pointers. I'll fix them asap.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 = >type[rfkill->key_type];
> > +   struct rfkill_key *key;
> > +   int status;
> > +
> > +   if (!rfkill)
> > +   return -EINVAL; 
> > +
> > +   if (rfkill->key_type >= KEY_TYPE_MAX)
> > +   return -EINVAL;
> > +
> > +   /*
> > +* Increase module use count to prevent this
> > +* module to be unloaded while there are still
> > +* registered keys.
> > +*/
> > +   if (!try_module_get(THIS_MODULE))
> > +   return -EBUSY;
> 
> This is obviously broken.  Please add a "struct module *owner;"
> field to struct rfkill instead.

Thanks, will fix this asap.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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-type[rfkill-key_type];
  +   struct rfkill_key *key;
  +   int status;
  +
  +   if (!rfkill)
  +   return -EINVAL; 
  +
  +   if (rfkill-key_type = KEY_TYPE_MAX)
  +   return -EINVAL;
  +
  +   /*
  +* Increase module use count to prevent this
  +* module to be unloaded while there are still
  +* registered keys.
  +*/
  +   if (!try_module_get(THIS_MODULE))
  +   return -EBUSY;
 
 This is obviously broken.  Please add a struct module *owner;
 field to struct rfkill instead.

Thanks, will fix this asap.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

[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))
  +   schedule_work(master-toggle_work);
  +
  +   mutex_unlock(master-mutex);
  +}
  +EXPORT_SYMBOL_GPL(rfkill_report_event);
 
 Please use kernel-doc notation for non-static functions.
 See Documentation/kernel-doc-nano-HOWTO.txt for more info.

All kernel-doc notations were placed in the rfkill.h header.
I'll move them to the rfkill.c file.


[snip]

  + * @rfkill: rfkill structure to be deregistered
  + * @init_status: initial status of the key at the time this function is 
  called
  + *
  + * This function should be called by the key driver when the rfkill 
  structure
  + * needs to be registered. Immediately from registration the key driver
  + * should be able to receive calls through the poll, enable_radio and
  + * disable_radio handlers if those were registered.
  + */
  +int rfkill_register_key(struct rfkill *rfkill, int init_status);
  +
  +/**
  + * rfkill_deregister_key - Deregister a previously registered rfkill 
  structre.
 
 structure

Thanks for the pointers. I'll fix them asap.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 keys often control the wireless devices on the radio
> > like the wifi, bluetooth and irda.
> >
> > The rfkill works as follows, when the user presses the hardware key
> > to control the wireless (wifi, bluetooth or irda) radio a signal will
> > go to rfkill. This happens by the hardware driver sending a signal
> > to rfkill, or rfkill polling for the button status.
> > The key signal will then be processed by rfkill, each key will have
> > its own input device, if this input device has not been openened
> > by the user, rfkill will keep the signal and either turn the radio
> > on or off based on the key status.
> > If the input device has been opened, rfkill will send the signal to
> > userspace and do nothing further. The user is in charge of controlling
> > the radio.
> >
> > This driver (if accepted and applied) will be usefull for the rt2x00 drivers
> > (rt2400pci, rt2500pci, rt2500usb, rt61pci and rt73usb) in the wireless-dev
> > tree and the MSI laptop driver from Lennart Poettering in the main
> > linux kernel tree.
> >
> > Before this patch can be applied to any tree, I first wish to hear
> > if the patch is acceptable. Since the previous time it was send I have made
> > several fixes based on the feedback like adding the sysfs entries for
> > reading the status.
> >
> 
> Hi Ivo,
> 
> I apologize for not responding to your post earlier, it was a busy week.

No problem, it didn't compile anyway. And this time I have CC'ed all
people that have previously shown interest in rfkill, so they are now
updated about rfkill as well. ;)

> 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 button at all and users might
> want to assign one of their standard keyboard buttons to be an RF
> switch.

Making sure rfkill supports keys that are not handled by the driver
is a bit hard. Just as drivers that can only check if the button is
toggled and not what the current state is.
The problem is that it is hard to make a clean split between the
2 different button controls. Not all drivers allow the radio to be
enabled while the button status are indicating the radio should
be off.
The buttons that are already integrated into the keyboard,
by example by using a Fn key combo don't control the device
directly. So the driver cannot offer anything to the rfkill driver.
Such buttons should be mapped in userspace without the help of rfkill,
since the kernel cannot detect if that key belonged to a radio
control key or not.

> I think it would be better if there was an rfkill class listing all
> controlled devices (preferrably grouped by their type - WiFi, BT,
> IRDA, etc) and if every group would provide an attribute allowing to
> control state of the whole group (do we realistically need to kill
> just one interface? Wouldn't ifconfig be suitable for that?). The

There have been mixed feelings on the netdev list about what should
exactly happen when the button is pressed. The possible options are:

1 - rfkill will kill all interfaces
2 - rfkill will kill all interfaces of the same type (wifi, bt, irda)
3 - rfkill will kill the interface it belongs to
 
Personally I would favour the second option, but used the third after hearing
objections to the second method. So since there are also fans of
the third option I think there should be a decision made about what the
correct option is, so rfkill can follow that method.

> attribute should be a tri-state on/off/auto, "auto" meaning the driver
> itself manages radio state. This would avoid another tacky IMHO point
> that in your implementation mere opening of an input device takes over
> RF driver. Explicit control allow applications "snoop" RF state
> without disturbing it.

Currently userspace can always check the state of the button whenever
they like by checking the sysfs entry. 


> If there are concerns that drivers will have to re-implement most of
> the button handling you are still free to create a simple
> implementation of polled RF button (I don't think that interrupt
> driver RF buttons would share alot of code) so that users would only
> need to implement a polling function.

Isn't the current interface to the driver not clean enough?
It only asks for the (optional) poll method, and the enable/disable method.
I believe this should not add too much code into the drivers, especially when
all methods are optional.

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at 

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

[Ivo van Doorn]

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 keys often control the wireless devices on the radio
  like the wifi, bluetooth and irda.
 
  The rfkill works as follows, when the user presses the hardware key
  to control the wireless (wifi, bluetooth or irda) radio a signal will
  go to rfkill. This happens by the hardware driver sending a signal
  to rfkill, or rfkill polling for the button status.
  The key signal will then be processed by rfkill, each key will have
  its own input device, if this input device has not been openened
  by the user, rfkill will keep the signal and either turn the radio
  on or off based on the key status.
  If the input device has been opened, rfkill will send the signal to
  userspace and do nothing further. The user is in charge of controlling
  the radio.
 
  This driver (if accepted and applied) will be usefull for the rt2x00 drivers
  (rt2400pci, rt2500pci, rt2500usb, rt61pci and rt73usb) in the wireless-dev
  tree and the MSI laptop driver from Lennart Poettering in the main
  linux kernel tree.
 
  Before this patch can be applied to any tree, I first wish to hear
  if the patch is acceptable. Since the previous time it was send I have made
  several fixes based on the feedback like adding the sysfs entries for
  reading the status.
 
 
 Hi Ivo,
 
 I apologize for not responding to your post earlier, it was a busy week.

No problem, it didn't compile anyway. And this time I have CC'ed all
people that have previously shown interest in rfkill, so they are now
updated about rfkill as well. ;)

 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 button at all and users might
 want to assign one of their standard keyboard buttons to be an RF
 switch.

Making sure rfkill supports keys that are not handled by the driver
is a bit hard. Just as drivers that can only check if the button is
toggled and not what the current state is.
The problem is that it is hard to make a clean split between the
2 different button controls. Not all drivers allow the radio to be
enabled while the button status are indicating the radio should
be off.
The buttons that are already integrated into the keyboard,
by example by using a Fn key combo don't control the device
directly. So the driver cannot offer anything to the rfkill driver.
Such buttons should be mapped in userspace without the help of rfkill,
since the kernel cannot detect if that key belonged to a radio
control key or not.

 I think it would be better if there was an rfkill class listing all
 controlled devices (preferrably grouped by their type - WiFi, BT,
 IRDA, etc) and if every group would provide an attribute allowing to
 control state of the whole group (do we realistically need to kill
 just one interface? Wouldn't ifconfig be suitable for that?). The

There have been mixed feelings on the netdev list about what should
exactly happen when the button is pressed. The possible options are:

1 - rfkill will kill all interfaces
2 - rfkill will kill all interfaces of the same type (wifi, bt, irda)
3 - rfkill will kill the interface it belongs to
 
Personally I would favour the second option, but used the third after hearing
objections to the second method. So since there are also fans of
the third option I think there should be a decision made about what the
correct option is, so rfkill can follow that method.

 attribute should be a tri-state on/off/auto, auto meaning the driver
 itself manages radio state. This would avoid another tacky IMHO point
 that in your implementation mere opening of an input device takes over
 RF driver. Explicit control allow applications snoop RF state
 without disturbing it.

Currently userspace can always check the state of the button whenever
they like by checking the sysfs entry. 


 If there are concerns that drivers will have to re-implement most of
 the button handling you are still free to create a simple
 implementation of polled RF button (I don't think that interrupt
 driver RF buttons would share alot of code) so that users would only
 need to implement a polling function.

Isn't the current interface to the driver not clean enough?
It only asks for the (optional) poll method, and the enable/disable method.
I believe this should not add too much code into the drivers, especially when
all methods are optional.

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate "RF button support"
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..4777d73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,887 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_AUTHOR("Ivo van Doorn <[EMAIL PROTECTED]>");
+MODULE_VERSION("1.0");
+MODULE_DESCRIPTION("RF key support");
+MODULE_LICENSE("GPL");
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Once key status change has been detected, the toggled
+* field should be set to indicate a notification to
+* user or driver should be performed.
+*/
+   int toggled;
+
+   /*
+* Current state of the device radio, this state will
+* change after the radio has actually been toggled since
+* receiving the radio key event.
+*/
+   int radio_status;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+*/
+   int key_status;
+
+   /*
+* Input device for this key,
+* we also keep track of the number of
+* times this input device is open. This
+* is important for determining to whom we
+* should report key events.
+*/
+   struct input_dev *input;
+   unsigned int open_count;
+
+   /*
+* Key index number.
+*/
+   unsigned int key_index;
+
+   /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+   struct list_head entry;
+};
+
+/*
+ * rfkill key type structure.
+ */
+struct rfkill_type {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Name of this radio type.
+*/
+   char *name;
+
+   /*
+* Key type identification. Value must be any
+* in the key_type enum.
+*/

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

[Ivo van Doorn]

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 keys often control the wireless devices on the radio
> > like the wifi, bluetooth and irda.
> 
> Ok, what was the conclusion on the following issues?
> 
> 1) What about rfkill keys that aren't routed via software?  There are
> two modes here: (a) the key is not hardwired to the module and the
> driver is responsible for disabling the radio, (b) the key is hardwired
> to the module and firmware or some other mechanism disables the radio
> without driver interaction.  I thought I'd heard of some (b) hardware,
> mostly on older laptops, but does anyone know how prevalent (b) hardware
> is?  If there isn't any, do we care about it for now?

On condition
a)
The driver is supposed to read the button status by the method provided by
the device. (i.e. reading the register) the rfkill will periodically poll the 
driver
(if the polling method has been provided by the driver) and the rfkill
will do its work when the status of the register has changed.
With the input device open, the user can listen to the events and switch off
the radio manually (by using a tool like ifconfig or through the sysfs field)
When the input device is not open, rfkill will use the driver provided callback
functions to enable or disable the radio.

b)
In this case an interrupt is usually send to the driver about the event, or 
still the
register will be possible. On both occassions the signal can still be caught by
rfkill and handled further.
If the event is send to userspace so the user can still perform tasks,
the user can however not use the sysfs field to change the radio status
since it is only allowed to switch the radio to the status that the button 
indicates.
But the user can still perform tasks that should be handled (like stopping
programs that need the network).

I have heard that the broadcom chipsets toggle the radio state without
intervention of the driver, and instead only send an interrupt event.

> 2) Is there hardware that has separate keys for separate radios?  i.e.,
> one key for Bluetooth, and one key for WiFi?  I know Bastien has a
> laptop where the same rfkill key handles _both_ ipw2200 and the BT
> module, but in different ways: it actually removes the BT USB device
> from the USB bus, but uses the normal ipw rfkill mechanism.

Don't know about this hardware, my laptop has 2 seperate buttons for wifi
and bluetooth.
But it would be quite hard to caught such events cleanly, in this case the
option would be to register 2 seperate rfkill_key structures. That way the
key is represented twice to the user. But the enable_radio and disable _radio
callback functions from the driver would make the callback for the wifi and
bluetooth radio  individually possibly.

> 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 userspace there are 2 ways to listen, either regularly check the sysfs entry
for the status. Or the prefered way listen to the input device that is created 
for
each key.

> In any case, any movement on rfkill interface/handling standardization
> is quite welcome :)

True, there are currently a lot of methods floating around. And a single way
to notify the user would be a nice idea. :)

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 ?

Good point, a race condition could indeed occur in the only reader
that sends the signal to the userspace through the input device.
I'll fix this immediately.

Thanks,

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 or so

It was indeed intended to be a mutex, I had however missed
the presence of the mutex header in the kernel.
Will fix this immediately.

Thanks,

Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 keys often control the wireless devices on the radio
like the wifi, bluetooth and irda.

The rfkill works as follows, when the user presses the hardware key
to control the wireless (wifi, bluetooth or irda) radio a signal will
go to rfkill. This happens by the hardware driver sending a signal
to rfkill, or rfkill polling for the button status.
The key signal will then be processed by rfkill, each key will have
its own input device, if this input device has not been openened
by the user, rfkill will keep the signal and either turn the radio
on or off based on the key status.
If the input device has been opened, rfkill will send the signal to
userspace and do nothing further. The user is in charge of controlling
the radio.

This driver (if accepted and applied) will be usefull for the rt2x00 drivers
(rt2400pci, rt2500pci, rt2500usb, rt61pci and rt73usb) in the wireless-dev
tree and the MSI laptop driver from Lennart Poettering in the main
linux kernel tree.

Before this patch can be applied to any tree, I first wish to hear
if the patch is acceptable. Since the previous time it was send I have made
several fixes based on the feedback like adding the sysfs entries for
reading the status.

Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>

---

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate "RF button support"
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..2a896db
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,880 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+MODULE_AUTHOR("Ivo van Doorn <[EMAIL PROTECTED]>");
+MODULE_VERSION("1.0");
+MODULE_DESCRIPTION("RF key support");
+MODULE_LICENSE("GPL");
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Once key status change has been detected, the toggled
+* field should be set to indicate a notification to
+* user or driver should be performed.
+*/
+   int toggled;
+
+   /*
+* Current stat

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

[Ivo van Doorn]

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 keys often control the wireless devices on the radio
like the wifi, bluetooth and irda.

The rfkill works as follows, when the user presses the hardware key
to control the wireless (wifi, bluetooth or irda) radio a signal will
go to rfkill. This happens by the hardware driver sending a signal
to rfkill, or rfkill polling for the button status.
The key signal will then be processed by rfkill, each key will have
its own input device, if this input device has not been openened
by the user, rfkill will keep the signal and either turn the radio
on or off based on the key status.
If the input device has been opened, rfkill will send the signal to
userspace and do nothing further. The user is in charge of controlling
the radio.

This driver (if accepted and applied) will be usefull for the rt2x00 drivers
(rt2400pci, rt2500pci, rt2500usb, rt61pci and rt73usb) in the wireless-dev
tree and the MSI laptop driver from Lennart Poettering in the main
linux kernel tree.

Before this patch can be applied to any tree, I first wish to hear
if the patch is acceptable. Since the previous time it was send I have made
several fixes based on the feedback like adding the sysfs entries for
reading the status.

Signed-off-by Ivo van Doorn [EMAIL PROTECTED]

---

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate RF button support
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..2a896db
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,880 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/input.h
+#include linux/rfkill.h
+
+#include asm/semaphore.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Once key status change has been detected, the toggled
+* field should be set to indicate a notification to
+* user or driver should be performed.
+*/
+   int toggled

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

[Ivo van Doorn]

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 so

It was indeed intended to be a mutex, I had however missed
the presence of the mutex header in the kernel.
Will fix this immediately.

Thanks,

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 ?

Good point, a race condition could indeed occur in the only reader
that sends the signal to the userspace through the input device.
I'll fix this immediately.

Thanks,

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 keys often control the wireless devices on the radio
  like the wifi, bluetooth and irda.
 
 Ok, what was the conclusion on the following issues?
 
 1) What about rfkill keys that aren't routed via software?  There are
 two modes here: (a) the key is not hardwired to the module and the
 driver is responsible for disabling the radio, (b) the key is hardwired
 to the module and firmware or some other mechanism disables the radio
 without driver interaction.  I thought I'd heard of some (b) hardware,
 mostly on older laptops, but does anyone know how prevalent (b) hardware
 is?  If there isn't any, do we care about it for now?

On condition
a)
The driver is supposed to read the button status by the method provided by
the device. (i.e. reading the register) the rfkill will periodically poll the 
driver
(if the polling method has been provided by the driver) and the rfkill
will do its work when the status of the register has changed.
With the input device open, the user can listen to the events and switch off
the radio manually (by using a tool like ifconfig or through the sysfs field)
When the input device is not open, rfkill will use the driver provided callback
functions to enable or disable the radio.

b)
In this case an interrupt is usually send to the driver about the event, or 
still the
register will be possible. On both occassions the signal can still be caught by
rfkill and handled further.
If the event is send to userspace so the user can still perform tasks,
the user can however not use the sysfs field to change the radio status
since it is only allowed to switch the radio to the status that the button 
indicates.
But the user can still perform tasks that should be handled (like stopping
programs that need the network).

I have heard that the broadcom chipsets toggle the radio state without
intervention of the driver, and instead only send an interrupt event.

 2) Is there hardware that has separate keys for separate radios?  i.e.,
 one key for Bluetooth, and one key for WiFi?  I know Bastien has a
 laptop where the same rfkill key handles _both_ ipw2200 and the BT
 module, but in different ways: it actually removes the BT USB device
 from the USB bus, but uses the normal ipw rfkill mechanism.

Don't know about this hardware, my laptop has 2 seperate buttons for wifi
and bluetooth.
But it would be quite hard to caught such events cleanly, in this case the
option would be to register 2 seperate rfkill_key structures. That way the
key is represented twice to the user. But the enable_radio and disable _radio
callback functions from the driver would make the callback for the wifi and
bluetooth radio  individually possibly.

 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 userspace there are 2 ways to listen, either regularly check the sysfs entry
for the status. Or the prefered way listen to the input device that is created 
for
each key.

 In any case, any movement on rfkill interface/handling standardization
 is quite welcome :)

True, there are currently a lot of methods floating around. And a single way
to notify the user would be a nice idea. :)

Ivo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ivo van Doorn]

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 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
  Say Y here if you want to support the built-in real time clock
  of the HP SDC controller.
 
+config RFKILL
+   tristate RF button support
+   help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
 obj-$(CONFIG_INPUT_WISTRON_BTNS)   += wistron_btns.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL)   += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..4777d73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,887 @@
+/*
+   Copyright (C) 2006 Ivo van Doorn
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the
+   Free Software Foundation, Inc.,
+   59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+   struct rfkill *rfkill;
+
+   /*
+* Pointer to type structure that this key belongs to.
+*/
+   struct rfkill_type *type;
+
+   /*
+* Once key status change has been detected, the toggled
+* field should be set to indicate a notification to
+* user or driver should be performed.
+*/
+   int toggled;
+
+   /*
+* Current state of the device radio, this state will
+* change after the radio has actually been toggled since
+* receiving the radio key event.
+*/
+   int radio_status;
+
+   /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+*/
+   int key_status;
+
+   /*
+* Input device for this key,
+* we also keep track of the number of
+* times this input device is open. This
+* is important for determining to whom we
+* should report key events.
+*/
+   struct input_dev *input;
+   unsigned int open_count;
+
+   /*
+* Key index number.
+*/
+   unsigned int key_index;
+
+   /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+   struct list_head entry;
+};
+
+/*
+ * rfkill key type structure.
+ */
+struct rfkill_type {
+   /*
+* For sysfs representation.
+*/
+   struct class_device *cdev;
+
+   /*
+* Name of this radio type.
+*/
+   char *name;
+
+   /*
+* Key type identification. Value must be any