On Saturday 23 February 2008, Sebastian Siewior wrote:
> * Sebastian Siewior | 2008-02-23 21:06:37 [+0100]:
>
> >I add this to the patch desctiption and post a depends on patach
> ARGH, this was CONFIG_WIRELESS_EXT and not MAC80211. You would like to
> see a select or depend statement on that one?
On Saturday 23 February 2008, Sebastian Siewior wrote:
> * Ivo van Doorn | 2008-02-23 20:44:59 [+0100]:
>
> >Is there any particular reason why this driver is in drivers/net instead
> >of drivers/net/wireless (along with all other wireless drivers?
>
> My understanding
On Saturday 23 February 2008, Sebastian Siewior wrote:
> * Ivo van Doorn | 2008-02-23 20:50:34 [+0100]:
>
> >Additionally, what part of the driver actually uses mac80211?
> >I just browsed to the code, and it seems to work completely without
> >using mac80211. Instead it s
On Saturday 23 February 2008, Ivo van Doorn wrote:
> On Saturday 23 February 2008, Sebastian Siewior wrote:
> > so select it.
> > Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
> > ---
> > drivers/net/Kconfig |1 +
> > 1 files changed, 1 insertions
On Saturday 23 February 2008, Sebastian Siewior wrote:
> so select it.
> Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
> ---
> drivers/net/Kconfig |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index f337800..a11605
rfkill_switch_all shouldn't be called by drivers directly,
instead they should send a signal over the input device.
To prevent confusion for driver developers, move the
function into a rfkill private header.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/in
On Wednesday 19 September 2007, John W. Linville wrote:
> On Wed, Sep 19, 2007 at 08:31:19PM +0200, Ivo van Doorn wrote:
>
> > > Ivo and his team may feel I am jumping the gun a bit -- they have
> > > a few more random bugs they wanted to squash before going upstream.
On Wednesday 19 September 2007, Michael Buesch wrote:
> On Wednesday 19 September 2007 20:47:59 Ivo van Doorn wrote:
> > On Wednesday 19 September 2007, David Miller wrote:
> > > From: Ivo van Doorn <[EMAIL PROTECTED]>
> > > Date: Wed, 19 Sep 2007 20:31:19 +0200
&
On Wednesday 19 September 2007, David Miller wrote:
> From: Ivo van Doorn <[EMAIL PROTECTED]>
> Date: Wed, 19 Sep 2007 20:31:19 +0200
>
> > Because I am indeed not really happy with this early merge, but I'll do my
> > best to resolve the last outstanding bugs
Hi,
> This patch adds the rt2x00 drivers for Ralink wireless hardware.
> This collection of drivers has seen lots of action in Fedora (both
> F7 and rawhide) and many people are using them with good results
> (although some problems do remain).
>
> Ivo in particular has been very helpful in respo
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Changes since v1 and v2:
- Spellchecking
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Acked-by:
moves IRDA support completely,
so it can be added whenever a driver wants the
feature.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
CC: Dmitry Torokhov <[EMAIL PROTECTED]>
CC: Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
---
include/linux/rfkill.h |8 +++-
net/rfkill/Kconf
This patch will add support for UWB keys to rfkill,
support for this has been requested by Inaky.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
CC: Dmitry Torokhov <[EMAIL PROTECTED]>
CC: Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
---
include/linux/input.h |1 +
incl
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Changes since v1 and v2:
- Spellchecking
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
Only
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Changes since v1:
- Spellchecking
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
Only patch 3
On Monday 10 September 2007, Randy Dunlap wrote:
> On Mon, 10 Sep 2007 19:56:03 +0200 Ivo van Doorn wrote:
>
> > Add a documentation file which contains
> > a short description about rfkill with some
> > notes about drivers and the userspace interface.
>
> Th
This patch will add support for UWB keys to rfkill,
support for this has been requested by Inaky.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
include/linux/input.h |1 +
include/linux/rfkill.h|2 ++
net/rfkill/rf
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
Documentation/rfkil
moves IRDA support completely,
so it can be added whenever a driver wants the
feature.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
include/linux/rfkill.h |8 +++-
net/rfkill/Kconfig |2 +-
net/rfkill/rfkill.c
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
Documentation/rfkill.txt | 88 ++
1 files changed, 88 inse
This patch will add support for UWB keys to rfkill,
support for this has been requested by Inaky.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
CC: Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
---
include/linux/input.h |1 +
include/linux/rfkill.h|2 ++
net/rfkill/rf
moves IRDA support completely,
so it can be added whenever a driver wants the
feature.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
include/linux/rfkill.h |8 +++-
net/rfkill/Kconfig |2 +-
net/rfkill/rfkill.c|5 +
3 files changed, 5 insertions(+), 10 de
Hi Dmitry,
I have a few rfkill related patches for which I would prefer if you to could
take a look at before I send them for inclusion.
Thanks. :)
Ivo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
Hi,
> If I'm reading the state bits and the message correcly dev_base_lock was
> aquired for write with IRQ enabled (via register_netdevice), but lockep also
> saw it aquired for read *in* IRQ (hardirq) context (rt2x00 code path, via
> rt2x00lib_beacondone -> ieee80211_beacon_get); this means that
The rfkill state Sysfs attribute should be made writable,
we already pass the argument for the store handler,
so we only need to update the permissions flag.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index f3986d4..db3395b
The rfkill name can be made const safely,
this makes the compiler happy when drivers make
it point to some const string used elsewhere.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index 7c1ffba..a8a6ea8 100644
--- a/i
coverity has spotted a bug in rfkill.c (bug id #1627),
in rfkill_allocate() NULL was returns if the kzalloc() works,
and deref the NULL pointer if it fails,
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index a973603..f3986d4
Hi,
> However, ad-hoc still does not work, since the network device's
> carrier status does not seem to be properly set. (It remains
> in NO-CARRIER even after "wlan0: Selected IBSS BSSID
> 92:68:a2:db:de:45 based on configured SSID". I dirtily hacked
> around that with the following two-liner:
I
On Monday 07 May 2007 09:46, Michael Wu wrote:
> From: Ivo van Doorn <[EMAIL PROTECTED]>
>
> This patch adds a library for reading from and writing to 93cx6 eeproms.
>
> Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
Signed-off-by: Ivo van Doorn <[EMAIL PROTECT
> > 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.
> > > 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
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,
. This pointer is only a reference
to a local variable so drivers will not need to call kfree() on it.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rpU3 dscape/include/net/d80211.h dscape.control/include/net/d80211.h
--- dscape/include/net/d80211.h 2007-02-06 00:19:37.0
On Monday 05 February 2007 22:37, Jiri Benc wrote:
> On Mon, 5 Feb 2007 16:32:24 +0100, Ivo van Doorn wrote:
> > When a driver requested additional header room
> > through the extra_tx_headroom field, the stack
> > should respect that and make sure that all frames
> >
On Monday 05 February 2007 21:28, Jiri Benc wrote:
> On Sat, 3 Feb 2007 17:25:18 +0100, Ivo van Doorn wrote:
> > When rt2500usb and rt73usb will start using beacontemplates,
> > they would also need a control structure to be passed along to
> > correctly set the tx parame
Hi,
> > Did you already send that patchset to the netdev list?
> > Because I haven't seen a patch series about rts for d80211 yet.
>
> No, [EMAIL PROTECTED]
Hmm, wasn't subscribed to that list yet. :(
But now I am. :)
> > The new rt2500usb and rt73usb packet ring handling no longer use a DMA
>
On Monday 05 February 2007 19:08, Jiri Benc wrote:
> On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote:
> > I also think that sending RTS in software is not going to work,
> > as the timing can not be guaranteed. And timing is why we do it in
> > the first place. If the HW is not capable of s
Hi,
> > > > Not all hardware are capable of generating their own RTS frames.
> > > > This patch will add support for creating the RTS frame in software,
> > > > when the driver requests this through the flag
> > > > IEEE80211_HW_SOFTWARE_RTS
> > >
> > > It seems this is not the ideal solution. Mo
On Monday 05 February 2007 18:37, Jiri Benc wrote:
> On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote:
> > --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100
> > +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0
> > +0100
On Monday 05 February 2007 18:28, Jiri Benc wrote:
> On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote:
> > Not all hardware are capable of generating their own RTS frames.
> > This patch will add support for creating the RTS frame in software,
> > when the driver requ
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3 dscape/net/
On Saturday 03 February 2007 17:33, Michael Wu wrote:
> On Saturday 03 February 2007 11:25, Ivo van Doorn wrote:
> > p54 seems to ignore the beacon that is being passed,
> > even though it is requesting the BEACON_TEMPLATE.
> > That is why I not only added a line to free
the beacon itself.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/d80211/p54/prism54common.c
b/drivers/net/wireless/d80211/p54/prism54common.c
index fd4ea5d..5a00d65 100644
--- a/drivers/net/wireless/d80211/p54/prism54common.c
+++ b/drivers/net/wi
that have the BEACON_TEMPLATE flag
set to also free the control structure. (bcm43xx and p54 will be
fixed in the next 2 patches)
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 65a5d36..b1b40f0 100644
--- a/include/net/d8
Drivers that require beacon templates will also have the
control structure at their disposal and should always free it.
bcm43xx doesn't use the control structure, but should still free it.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/d80
This patch makes sure the multiread/multiwrite
functions for eeprom_93cx6 work with little endian
data. The singleread still works with host endian.
Most drivers still want the multiread to work with little
endian because this is used for data like the MAC address.
Signed-off-by Ivo van Doorn
On Wednesday 31 January 2007 20:16, Ivo van Doorn wrote:
> Most hardware can keep track of sequence numbers themselves,
> unfortunately *most* doesn't cover all devices. ;)
> This patch will keep track of the sequence number if the flag
> IEEE80211_HW_SOFTWARE_SEQUENCE has been
Most hardware can keep track of sequence numbers themselves,
unfortunately *most* doesn't cover all devices. ;)
This patch will keep track of the sequence number if the flag
IEEE80211_HW_SOFTWARE_SEQUENCE has been set.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -
Not all hardware are capable of generating their own RTS frames.
This patch will add support for creating the RTS frame in software,
when the driver requests this through the flag
IEEE80211_HW_SOFTWARE_RTS
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/include/net/d802
hanges 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 +7
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
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
-
Hi,
This patch should be enough to allow creation of standalone d80211 tarball
(i.e. version of d80211 that could be compiled without patching the vanilla
kernel) after "invisible master interface" patches.
That looks very nice indeed, that saves me quite a big patch
I usually apply to the rt2
Hi,
> Correct, similar problems have been detected in rt2x00. The temporary
> solution in there is to demand a scanning operation after the interface
> has been brought up.
Scanning? No no no, please! That would be a clear bug and misbehaviour.
Hmm, I think I forgot to add one little thing in
Hi,
I have discovered that while I can indeed associate without
wpa_supplicant using bcm43xx_d80211 driver, I have to set the channel
every time the interface is brought down and up.
It turns out d80211 uses the "config" method of the hardware drivers
very sparingly. It's only used for scannin
Hi John,
> These patches have been send during 2006 but never
> have been applied or rejected. Even after sending requests
> for updates on these patches.
> So I have no idea if you had rejected them, simply
> overlooked them, or if they are still in your pending list.
>
> Short summary of which
m bit,
as the IEEE specs mandate. (Comment has been added to prevent future
attempts to use the __set_bit and __clear_bit)
And the local argument has been removed.
Signed-off-by Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/net/d8021
On Tuesday 02 January 2007 17:22, Christoph Hellwig wrote:
> On Tue, Jan 02, 2007 at 04:30:41PM +0100, Ivo Van Doorn wrote:
> > +static inline void __bss_tim_set(struct ieee80211_local *local,
> > +struct ieee80211_if_ap *bss, int aid)
> > +{
>
This patch removes the crc-itu-t files from rt2x00
and makes sure rt2x00 will use the generic crc-itu-t
implementation inside the lib folder.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev_crc/drive
This patch removes the eeprom_93cx6 files from rt2x00
and makes sure rt2x00 will use the generic eeprom_93cx6
implementation inside the lib folder.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev_eeprom/d
This patch adds the eeprom_93cx6 module to the lib folder.
This module provides a generic approach for reading and
writing words from the eeprom chipsets 93c46 and 93c66.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/include/linux/eeprom_93cx6.h
wi
This patch add the crc-itu-t implementation to the
lib folder.
This crc handler uses the CRC ITU-T V.41 routine
that is used in multiple drivers.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/include/linux/crc-itu-t.h
wireless-dev_crc/include/linux/crc-i
Hi John,
These patches have been send during 2006 but never
have been applied or rejected. Even after sending requests
for updates on these patches.
So I have no idea if you had rejected them, simply
overlooked them, or if they are still in your pending list.
Short summary of which patches are be
tion, simple fix below.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
[Sorry, yet another rt2x00 CVS patch...]
To make it easier for everybody, here is the same patch
only this time applied to the dscape git tree. ;)
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Ivo
e dscape git tree. ;)
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..b132ae0 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
Hi,
> > This patch addes support for writing to the eeprom,
> > this also moves some duplicate code into seperate functions.
>
> John: Do you want me to merge this path with the eeprom merge patch,
> and move the patch that moves rt2x00 to use this eeprom module into a
> separate patch or all the
Hi,
This patch addes support for writing to the eeprom,
this also moves some duplicate code into seperate functions.
John: Do you want me to merge this path with the eeprom merge patch,
and move the patch that moves rt2x00 to use this eeprom module into a
separate patch or all these 2 patches
+= 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
Hi,
On Friday 15 December 2006 20:39, Michael Buesch wrote:
> Fix breakage from removal of PKT_PROBE_RESP.
Jiri had already send a patch to the netdev list to cover this breakage.
([PATCH 1/2] rt2x00: fix breakage after pkt_type field was removed)
And I personally favour the patch from Jiri.
Ivo
Hi,
> This fixes compilation for the d80211 hwmode API change.
I haven't had time yet to look closely at more of the benefits
of the new hwmode API change, but this patch looks good.
Thanks!
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Ivo van Doorn
Hi,
> How, by private ioctls? That's just wrong; I believe you still need to
> go through the 4-way handshake to get the right keying information even
> if you use PSK, which means you still need the supplicant, right?
All I did was add this to /etc/network/interfaces:
iface wlan0 inet static
This patch addes support for writing to the eeprom,
this also moves some duplicate code into seperate functions.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rNU3 wireless-dev/include/linux/eeprom_93cx6.h
wireless-dev-eeprom/include/linux/eeprom_93cx6.h
--- wireless-dev/i
On Wednesday 13 December 2006 18:38, Dan Williams wrote:
> On Wed, 2006-12-13 at 12:12 -0500, Lennart Sorensen wrote:
> > On Wed, Dec 13, 2006 at 06:00:35PM +0100, Jiri Benc wrote:
> > > John, in addition to the previous pull request, please also apply the
> > > following two fixes.
> >
> > What i
On Wednesday 13 December 2006 18:12, Lennart Sorensen wrote:
> On Wed, Dec 13, 2006 at 06:00:35PM +0100, Jiri Benc wrote:
> > John, in addition to the previous pull request, please also apply the
> > following two fixes.
>
> What is the state of the rx2x00 driver by now? I have been playing
> aro
On Wednesday 13 December 2006 18:05, Lennart Sorensen wrote:
> On Wed, Dec 13, 2006 at 05:47:41PM +0100, Ivo van Doorn wrote:
> > Do you need to actually write data to the eeprom chip?
> > Currently the module does not support writing to the eeprom,
> > this is something I co
crc-itu-t should only appear in the kernel configuration menu
when rt2x00 is enabled. The module should only be build when
rt2x00 is used, otherwise crc-itu-t is simply in the wrong
location since it is not a network driver.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -
On Wednesday 13 December 2006 18:00, Jiri Benc wrote:
> Fix breakage after pkt_type field was removed from ieee80211_tx_control.
Hmm, I must have missed that patch.
Your patch looks good to me.
Thanks
> Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
Signed-off-by: Ivo van Doorn <[
On Wednesday 13 December 2006 16:44, Lennart Sorensen wrote:
> On Sat, Dec 09, 2006 at 02:05:06PM +0100, Ivo Van Doorn wrote:
> > Nope, don't have that device. I'll create a patch that will place the eeprom
> > module in the /lib folder. I'll send that to the list as
Hi,
I am currently porting the bcm43xx driver to my new Sonics
Silicon Backplane busdriver.
I am having a major pain implementing the hw->modes field
for this. In particular, the problem is allocation.
I always felt sick about hw->modes, but with my new code it's
damn complicated to get allocati
Hi,
> > > > > 2 - Hardware key that does not control the hardware radio and does
not report anything to userspace
> > > >
> > > > Kind of uninteresting button ;)
> > >
> > > And this is the button that rfkill was originally designed for.
> > > Laptops with integrated WiFi cards from Ralink have
Hi
> I have checked the adm80211 code as well, it seems to behave quite the
> same, with the most notable difference the fact that adm80211 writes the
> READ_OPCODE and the word index within a single command, while in
> eeprom_93cx6 this is split into 2 seperate write commands.
> I have not yet
On Sunday 03 December 2006 19:39, Michael Wu wrote:
> On Sunday 03 December 2006 13:19, Ivo van Doorn wrote:
> > rt2400pci, rt2500pci and rt61pci share exactly the
> > same code for the eeprom reading. The only difference
> > is that rt61pci has a slightly different register
Hi,
> > > > 2 - Hardware key that does not control the hardware radio and does not
> > > > report anything to userspace
> > >
> > > Kind of uninteresting button ;)
> >
> > And this is the button that rfkill was originally designed for.
> > Laptops with integrated WiFi cards from Ralink have a ha
Hi,
> > > > 2 - Hardware key that does not control the hardware radio and does not
> > > > report anything to userspace
> > >
> > > Kind of uninteresting button ;)
> >
> > And this is the button that rfkill was originally designed for.
> > Laptops with integrated WiFi cards from Ralink have a
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 Tuesday 05 December 2006 11:32, Christoph Hellwig wrote:
> > +/*
> > + * Function called by the key driver when the rfkill structure
> > + * needs to be registered.
> > + */
> > +int rfkill_register_key(struct rfkill *rfkill, int init_status)
> > +{
> > + struct rfkill_type *type = &master->ty
[snip]
> > +/*
> > + * Function called by the key driver to report the new status
> > + * of the key.
> > + */
> > +void rfkill_report_event(struct rfkill *rfkill, int new_status)
> > +{
> > + mutex_lock(&master->mutex);
> > +
> > + if (rfkill_check_key(rfkill->key, new_status))
> > +
Hi,
> > This patch is a resend of a patch I has been send to the linux kernel
> > and netdev list earlier. The most recent version of a few weeks back
> > didn't compile since I missed 1 line in my patch that changed
> > include/linux/input.h.
> >
> > This patch will offer the handling of radiokey
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 radioke
On Sunday 03 December 2006 20:20, Arjan van de Ven wrote:
> this open_count thing smells fishy to me; what are the locking rules for
> it? What guarantees that the readers of it don't get the value changed
> underneath them between looking at the value and doing whatever action
> depends on it's va
On Sunday 03 December 2006 20:18, Arjan van de Ven wrote:
> On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> > +
> > + down(&master->key_sem);
> > +
>
> Hi,
>
> this one seems to be used as a mutex only, please consider using a mutex
&
On Sunday 03 December 2006 19:39, Michael Wu wrote:
> On Sunday 03 December 2006 13:19, Ivo van Doorn wrote:
> > rt2400pci, rt2500pci and rt61pci share exactly the
> > same code for the eeprom reading. The only difference
> > is that rt61pci has a slightly different register
tatus.
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
Introduce new defines for the SIFS, PIFS, EIFS, DIFS,
and make use of it in the drivers.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3 wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-timing/drivers/net/wireless/d80211/rt2x00/rt240
byteordering mechanism.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
http://www.mendiosus.nl/rt2x00/03_descriptor.diff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
rings have been initialized.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3 wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
Fix rt2x00 compilation problems due to the d80211 update.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
http://www.mendiosus.nl/rt2x00/06_d80211.diff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More m
Hi,
This patch series will bring rt2x00 completely up to date.
This includes the compile fixes after last d80211 update,
and brings so many fixes it is hard to summarize them.
Basically what it comes down to is that with this version
several people have managed to get the drivers working
and even
1 - 100 of 356 matches
Mail list logo
