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.
&g
...@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
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
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
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 ne
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 200
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
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
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
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
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,
> > > >
&g
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
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
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
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:
> >
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
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
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
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:
>
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:
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
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:
ies 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/r
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
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
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 w
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
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
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.
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.
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
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
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
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
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,
> &
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
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
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
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
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
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
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
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/driver
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
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
>
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
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)
>
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:
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:
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)
> > Well in drivers/net are the network drivers but not the irda and bluetooth
> > drivers,
> > those are located in different folders in drivers/ so I think misc would be
> > the most
> > suitable location.
>
> We could also consider the ./net itself. rfkill is not a driver, it is
> a
Well in drivers/net are the network drivers but not the irda and bluetooth
drivers,
those are located in different folders in drivers/ so I think misc would be
the most
suitable location.
We could also consider the ./net itself. rfkill is not a driver, it is
a facility.
True, in
> > > 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).
> > >
Hi,
> I am very sorry for taking so much time to respond but finally I went
> through the patch and I still have the same objection as before -
> it mixes two logically (and often physically) separated objects into
> a single entity. I think that RF switch and button should be separate
>
Hi,
I am very sorry for taking so much time to respond but finally I went
through the patch and I still have the same objection as before -
it mixes two logically (and often physically) separated objects into
a single entity. I think that RF switch and button should be separate
entities,
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
s 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
Hi,
> > + /*
> > +* Pointer to rfkill structure
> > +* that was filled in by key driver.
> > +*/
> > + struct rfkill *rfkill;
>
> Since rfkill is basically a function pointer table,
> can it be made const?
Sounds good to me.
> > + /*
> > +* Once key status change has been
Hi,
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
Since rfkill is basically a function pointer table,
can it be made const?
Sounds good to me.
+ /*
+* Once key status change has been detected, the
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
quot; 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/
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
+= 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
- 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
Hi,
> > > > > 2 - Hardware key that does not control the hardware radio and does
not report anything to userspace
> > > >
> > > > Kind of uninteresting button ;)
> > >
> > > And this is the button that rfkill was originally designed for.
> > > Laptops with integrated WiFi cards from Ralink
Hi,
2 - Hardware key that does not control the hardware radio and does
not report anything to userspace
Kind of uninteresting button ;)
And this is the button that rfkill was originally designed for.
Laptops with integrated WiFi cards from Ralink have a hardware button
Hi,
> > > > 2 - Hardware key that does not control the hardware radio and does not
> > > > report anything to userspace
> > >
> > > Kind of uninteresting button ;)
> >
> > And this is the button that rfkill was originally designed for.
> > Laptops with integrated WiFi cards from Ralink have a
Hi,
> > > > 2 - Hardware key that does not control the hardware radio and does not
> > > > report anything to userspace
> > >
> > > Kind of uninteresting button ;)
> >
> > And this is the button that rfkill was originally designed for.
> > Laptops with integrated WiFi cards from Ralink have a
Hi,
2 - Hardware key that does not control the hardware radio and does not
report anything to userspace
Kind of uninteresting button ;)
And this is the button that rfkill was originally designed for.
Laptops with integrated WiFi cards from Ralink have a hardware button
Hi,
2 - Hardware key that does not control the hardware radio and does not
report anything to userspace
Kind of uninteresting button ;)
And this is the button that rfkill was originally designed for.
Laptops with integrated WiFi cards from Ralink have a hardware button that
Hi,
> > > That is my point. Given the fact that there are keys that are not
> > > directly connected with the radio switch userspace will have to handle
> > > them (wait for events then turn off radios somehow). You are
> > > advocating that userspace should also implement 2nd method for buttons
On 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
&
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
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
[snip]
> > +/*
> > + * Function called by the key driver to report the new status
> > + * of the key.
> > + */
> > +void rfkill_report_event(struct rfkill *rfkill, int new_status)
> > +{
> > + mutex_lock(>mutex);
> > +
> > + if (rfkill_check_key(rfkill->key, new_status))
> > +
On Tuesday 05 December 2006 11:32, Christoph Hellwig wrote:
> > +/*
> > + * Function called by the key driver when the rfkill structure
> > + * needs to be registered.
> > + */
> > +int rfkill_register_key(struct rfkill *rfkill, int init_status)
> > +{
> > + struct rfkill_type *type =
On Tuesday 05 December 2006 11:32, Christoph Hellwig wrote:
+/*
+ * Function called by the key driver when the rfkill structure
+ * needs to be registered.
+ */
+int rfkill_register_key(struct rfkill *rfkill, int init_status)
+{
+ struct rfkill_type *type =
[snip]
+/*
+ * Function called by the key driver to report the new status
+ * of the key.
+ */
+void rfkill_report_event(struct rfkill *rfkill, int new_status)
+{
+ mutex_lock(master-mutex);
+
+ if (rfkill_check_key(rfkill-key, new_status))
+
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
Hi,
This patch is a resend of a patch I has been send to the linux kernel
and netdev list earlier. The most recent version of a few weeks back
didn't compile since I missed 1 line in my patch that changed
include/linux/input.h.
This patch will offer the handling of radiokeys on a
rfkill with the fixes as suggested by Arjan.
- instead of a semaphore a mutex is now being used.
- open_count changing is now locked by the mutex.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6
Hi,
> > This patch is a resend of a patch I has been send to the linux kernel
> > and netdev list earlier. The most recent version of a few weeks back
> > didn't compile since I missed 1 line in my patch that changed
> > include/linux/input.h.
> >
> > This patch will offer the handling of
On Sunday 03 December 2006 20:20, Arjan van de Ven wrote:
> this open_count thing smells fishy to me; what are the locking rules for
> it? What guarantees that the readers of it don't get the value changed
> underneath them between looking at the value and doing whatever action
> depends on it's
On Sunday 03 December 2006 20:18, Arjan van de Ven wrote:
> On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> > +
> > + down(>key_sem);
> > +
>
> Hi,
>
> this one seems to be used as a mutex only, please consider using a mutex
> instead, as i
.
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 yo
.
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
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
On Sunday 03 December 2006 20:20, Arjan van de Ven wrote:
this open_count thing smells fishy to me; what are the locking rules for
it? What guarantees that the readers of it don't get the value changed
underneath them between looking at the value and doing whatever action
depends on it's value
Hi,
This patch is a resend of a patch I has been send to the linux kernel
and netdev list earlier. The most recent version of a few weeks back
didn't compile since I missed 1 line in my patch that changed
include/linux/input.h.
This patch will offer the handling of radiokeys on a
rfkill with the fixes as suggested by Arjan.
- instead of a semaphore a mutex is now being used.
- open_count changing is now locked by the mutex.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59
90 matches
Mail list logo
