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..a116056 100644
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(+), 0 deletions(-)
diff --git a/drivers/net
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 seems to work directly
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 is/was that the wireless device
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/include/linux/rfkill.h
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 responding
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 as soon as possible.
Relax
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
Because I am indeed not really happy
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.
But since they are bugs, any
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/Kconfig |2 +-
net/rfkill
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 +
include/linux/rfkill.h
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: Randy Dunlap [EMAIL
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.
Thanks. I have noted a few typo/editorial
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 was updated, patches
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 patch 3 was updated
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|5 +
3 files changed
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/rfkill-input.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]
Acked-by: Dmitry Torokhov [EMAIL PROTECTED]
---
Documentation/rfkill.txt | 88
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
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 deletions(-)
diff --git
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 a
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/include
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 100644
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 was
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 PROTECTED]
---
drivers/misc/Kconfig
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
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
. 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 +0100
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/d80211
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 requests this through the flag
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
@@ -405,6 +405,7 @@
int
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. Most of drivers needing
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 sending
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
buffer
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
that are being send to the stack
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 set.
Signed-off
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
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/d80211.h
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/d80211/bcm43xx
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/wireless
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 control structure
but also
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/d80211.h b
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 -rNU3 dscape/include
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
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
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
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 scanning
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 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
,
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/d80211/ieee80211_i.h b/net/d80211
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)
+{
+ bss-tim[(aid)/8] |= 1((aid
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
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
wireless-dev_eeprom
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-itu-t.h
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/drivers
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/drivers/net
. ;)
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
@@ -558,20 +558,32 @@ struct sta_attribute
.
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 van Doorn [EMAIL PROTECTED]
---
diff
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
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
- 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,
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 [EMAIL PROTECTED
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,
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
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 [EMAIL PROTECTED
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 --git a/drivers
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 could add (The original Ralink
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
around
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
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
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 reading
approach. In any
Hi,
2 - Hardware key that does not control the hardware radio and does not
report anything to userspace
Kind of uninteresting button ;)
And this is the button that rfkill was originally designed for.
Laptops with integrated WiFi cards from Ralink have a hardware button
Hi,
2 - Hardware key that does not control the hardware radio and does not
report anything to userspace
Kind of uninteresting button ;)
And this is the button that rfkill was originally designed for.
Laptops with integrated WiFi cards from Ralink have a hardware button that
On 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
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 radiokeys on a
Add new rt2500usb and rt73usb device id numbers.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-base-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-base/drivers/net/wireless
Always use kzalloc instead of kmalloc.
Remove duplicate init functions.
And destroy the workqueue before freeing
resources, otherwise a thread on the queue might
still want to access that resource.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-ringfull/drivers/net
Correctly initialize the channel_change_time.
Make sure that channel is reset afterwards,
otherwise the channel is not correctly initialized
and rx/tx will fail.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless
Move the crc handling of rt61pci and rt73usb into a seperate module.
This will create the crc-itu-t module inside the rt2x00 folder.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev-crc/drivers/net/wireless
rt61pci and rt73usb have the WMM ring priorities
backwards. RING_AC_VO is the most important ring
while RING_AC_BK the least important ring.
Lets reorder the ring handling.
(And fix some small typos in the comments regarding
the rings)
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3
Each received packet has a signal field, this field
can be translated into the rate with which the frame
has been received.
Create a seperate function for this since the
conversion is equal for all drivers.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-interface
Correctly let the non-monitor and monitor interfaces
excist peacefully together. Make sure the configuration
is always accurate and allows the correct packets to
come through, let the interface enable the radio at
the correct time etc. etc.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
http
Overhaul the byteordering mechanism.
All byteordering happens at the reading and writing
of the register/eeprom/descriptor instead of the
get/set_field functions.
This makes sparse very happy and reduces the errors
significantly.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
http
Put the link tuning in a workqueue, this prevents
the interrupthandlers from being busy for a too long
period and blocking new inetrrupt handling.
To do this correctly we add a link structure containing
all information regarding the link status.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED
As usual, when I make a large patch series,
I overlook important bits...
This will fix all issues that have arisen from this
patch series.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-compile/drivers
a register.
Scheduling the request is required, but a clean solution
needs to be found.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-init
van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 12:38:28.0 +0100
+++ wireless-dev
Latest d80211 stack no longer provides any ethtool support.
At the moment there is no quick replacement possible for
the ethtool features (debugfs is under investigation, but
requires more work).
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-base/drivers/net/wireless
handling.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 15:09
are suggesting the CRC_ERROR count is
actually the FCS_ERROR count.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-signal/drivers/net
No set_field commands are required for the mac registers.
This was previously done for the byteordering.
But since the MAC is already read in the correct byteorder
this had never had to happen at all anyway.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-vendor/drivers
ethtool was removed from
d80211. This feature will be used when debugfs has been
implemented.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
http://www.mendiosus.nl/rt2x00/04_eeprom.diff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Remove the rt2x00usb_vendor_request from the rt2x00usb.h
header, and place it into the rt2x00_vendor_request.
This means that the rt2x00_vendor_request function
needs a timeout value especially for commands that
require a lot of time (i.e. Firmware writing).
Signed-off-by Ivo van Doorn [EMAIL
1 - 100 of 301 matches
Mail list logo
