* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-15 15:51 UTC (permalink / raw)
To: Stefan Rompf; +Cc: netdev, linux-kernel
In-Reply-To: <200601151340.10730.stefan@loplof.de>
Stefan Rompf wrote:
> Even though it is a bit more work on kernel side, we should allow changing
> the
> mode of virtual devices. Let's face it, even though we find multi-BSS
> capabilities very interesting, 999 of 1000 users won't care due to the two
> facts that IPW firmware IMHO doesn't allow it and virtual interfaces are
> limited to one channel anyway. These users rightfully expect to have one
> interface and be able to do all configurations on it.
Isn't that rather a question of having good user-space tools that make
deactivating one type of interface and activating another seamless?
johannes
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: Stuffed Crust @ 2006-01-15 15:39 UTC (permalink / raw)
To: Jeff Garzik; +Cc: John W. Linville, netdev, linux-kernel
In-Reply-To: <43C97693.7000109@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
> A big open issue: should you fake ethernet, or represent 802.11
> natively throughout the rest of the net stack?
>
> The former causes various and sundry hacks, and the latter requires that
> you touch a bunch of non-802.11 code to make it aware of a new frame class.
Internally, we're pure 802.11. One thing to keep in mind that we're not
going to be bridging/translating non-data traffic to other networks, and
with that in mind, 802.3<->802.11 translation is trivial, and won't lose
anything except for a bit of efficiency. (and then, just to be
contrary, the prism54 hardware actually requires 802.3 frames!)
That said.. we need to make the rest of the stack 802.11-aware.
Translating between 802.11 and 802.3 is trivial, as we only need to know
about a few operating parameters in order to perform the conversion --
AP/STA mode, BSSID, QoS parametsrs. WDS link parameters. All of these
can be attached to the net_device to be used by the hard_header code.
(Part of the problem is that 802.11 has a variable-length header - 24,
26, 30, or 32 bytes, and each address field means different things
depending on which mode we're using..)
Meanwhile, A current "good enough for most" solution is to make all
"data" interfaces to the 802.11 stack appear as 802.3 interfaces. Each
of these net_devices could translate to/from 802.11 on the fly. Thus
internally the stack would be pure 802.11, but interacting with the
outside world would depend on the "mode" of the net_device. You want
to tx/rx 802.11 management frames with QoS enabled? Create a "type
802_11_a3_qos" inteface.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stuffed Crust @ 2006-01-15 15:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Johannes Berg, netdev, linux-kernel
In-Reply-To: <43C97605.9030907@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
> >This can be accomplished by passing a static table to the
> >register_wiphy_device() call (or perhaps via a struct wiphy_dev
> >parameter) or through a more explicit, dynamic interface like:
> >
> > wiphy_register_supported_frequency(hw, 2412).
>
> For completely programmable hardware, the stack should interact with a
> module like ieee80211_geo, to help ensure the hardware stays within
> legal limits.
While there is much to debate about where to draw the functionality
line, completely programmable hardware is the norm these days.
... and said code would be responsible for driving the scanning state
machines, and also for more esoteric functions like handling RADAR
traps, automatic channel switching, etc.
Handling scans is quite interesting -- I've seen hardware which requires
manual channel changing (including full RF parameter specification),
host timing for the channel dwell time, and manual probe request
issuance.. and on the other end of the spectrum, a simple "issue scan"
command that takes few, if any, parameters.
And unfortunately, many things in between.
This leads me to belive that the internal scan workflow should work
something like this:
* Userspace app issues scan request (aka "refresh AP list")
* Knowing the hardware frequency capabilities, the 802.11 stack applies
802.11d and regdomain rules to the available frequency set, and
issues multiple internal "scan request" commands to the hardware
driver. (eg "perform an initial passive sweep across the entire
2.4G band", "perform an active scan on frequencies 2412->2437
looking for ssid "HandTossed", "perform an active scan on
frequencies 5200-5400 looking for ssid "HandTossed", etc)
(note that ideally, userspace apps/libs would be at least partially
aware of 802.11d rules, but the kernel must do the RightThing if
told to "scan all available channels for any access points")
* The hardware driver takes this scan request, and maps it into the
capabilities of the hardware:
Hardware A: (very thin MAC)
- Using library code, generates an appropriate probe request frame,
translates it into a format the hardware expects/needs,
and schedules it appropriately.
- Loops through the frequency set specified, and for each:
- Issues a channel change command
- Immediately transmits the probe request (for active scans)
- Dwells for an appropriate time
- RX'ed beacon/probe response frames come down as regular 802.11
frames into the stack
- Moves to the next channel
Hardware B: (thinner MAC)
- Using library code, generates an appropriate probe request frame,
and translate it into a format the hardware expects.
- Program the probe request frame into the hardware as a probe
template.
- Loops through the frequency set specified, and for each:
- Issues a channel change command
- Wait for a scan complete signal
- RX'ed beacon/probe response frames come down as regular 802.11
frames into the stack
- Moves to the next channel
Hardware C: (thick MAC, ala prism2 or prism54)
- Issues a hardware "scan request"
- Waits for the hardware to signal "scan complete"
- Requests hardware scan results
- For each scan result, the hardware returns:
- Translate result into an 802.11 probe response frame and
pass down the regular RX path.
So as you can see, I think the channel iteration, dwell, etc should
be performed by the hardware driver itself, as the variation at the
logical "tell the hardware perform a scan" step is so extreme.
* Meanwhile, the 802.11 stack is receiving the beacons/probe responses
from the hardware via the regular rx path. It diverts these (and
other 802.11 management/control) frames, decodes them, and then adds
them to the stack's internal list of available stations, updating any
internal states/counters as necessary. (These frames could also be
echoed to a special netdev interface if desired)
(stuff like detecting an AP going away depends on us noticing a lack
of beacons arriving, for example. Most hardware does not
notify us of this event. Likewise, we should expire other
APs from our list if they go away.. etc. For AP operation we need
to maintain this STA list, period -- so why not use it across the
board? But this is another discussion for another time..)
* The 802.11 stack issues a MLME-Scan-Complete notification to
userspace.
* Interested userspace apps see this event, then query the
scan results and presents them to the user in some pretty format, or
alternatively perform automatic roaming based on scan results.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Vitaly Bordug @ 2006-01-15 13:19 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jgarzik, saw, linux-kernel, netdev
In-Reply-To: <20060105181826.GD12313@stusta.de>
On Thu, 5 Jan 2006 19:18:26 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> This patch removes the obsolete drivers/net/eepro100.c driver.
>
> Is there any known problem in e100 still preventing us from removing
> this driver (it seems noone was able anymore to verify the ARM problem)?
>
I think I am recalling some problems on ppc82xx, when e100 was stuck on startup,
and eepro100 worked just fine.
Even if the patch below will be scheduled for application, we need to set up enough time
for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Stefan Rompf @ 2006-01-15 12:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel
In-Reply-To: <1137191522.2520.63.camel@localhost>
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
> [Changing mode of virtual devices]
>
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinking is that
> different virtual types have different structures associated, so
> changing it needs re-creating structures anyway. And different virtual
> device types might even be provided by different kernel modules so you
> don't carry around AP mode if you don't need it.
Even though it is a bit more work on kernel side, we should allow changing the
mode of virtual devices. Let's face it, even though we find multi-BSS
capabilities very interesting, 999 of 1000 users won't care due to the two
facts that IPW firmware IMHO doesn't allow it and virtual interfaces are
limited to one channel anyway. These users rightfully expect to have one
interface and be able to do all configurations on it.
Stefan
^ permalink raw reply
* Re: [PATCH] ACX: swap netdevice_t for struct net_device
From: Carlos Martín @ 2006-01-15 11:54 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: acx100-devel, netdev
In-Reply-To: <200601151306.57824.vda@ilport.com.ua>
On Sunday 15 January 2006 12:06, Denis Vlasenko wrote:
> On Sunday 15 January 2006 01:43, Carlos Martín wrote:
> > Attached patch does a s/netdevice_t/struct net_device/g on all the files
that
> > required it. It's against 20060114
>
> Too late :)
> acx-20060115 already has no netdevice_t.
Can you read my mind? :) I see you also got rid of wlandevice_t, nice.
cmn
--
Carlos Martín http://www.cmartin.tk
"Erdbeben? Sicherlich etwas, das mit Erdberen zu tun hat." -- me, paraphrased
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* acxsm: migrate acx from homegrown 802.11 handling to softmac stack
From: Denis Vlasenko @ 2006-01-15 11:52 UTC (permalink / raw)
To: netdev, softmac-dev, acx100-devel
Hi,
http://195.66.192.167/linux/acx_patches/acxsm-20060115.tar.bz2
README says:
==================
*** Not run tested. Almost certainly won't work. Lots of things are TODO. ***
This tarball contains a port of acx driver to ieee80211softmac
stack. Broadcom 43xx driver was used as an example.
See http://bcm43xx.berlios.de/,
ftp://ftp.berlios.de/pub/bcm43xx/snapshots/
Latest softmac source is in softmac-snapshot/ and net/
is a symling to softmac-snapshot/include/net/.
softmac-snapshot/ is to be replaced regularly with newer
snapshots from http://softmac.sipsolutions.net/SoftMAC.
grep for '//SM' to see the code added to standalone acx driver code.
...
...
===================
This is it.
P.S. It does not mean that acx driver is discontinued.
It will be supported as before. Let's see whether acxsm
will get any traction at all.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: Arnaldo Carvalho de Melo @ 2006-01-15 11:23 UTC (permalink / raw)
To: David S. Miller; +Cc: jgarzik, linville, netdev, linux-kernel
In-Reply-To: <20060114.175140.07007614.davem@davemloft.net>
On 1/14/06, David S. Miller <davem@davemloft.net> wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Sat, 14 Jan 2006 17:09:23 -0500
>
> > A big open issue: should you fake ethernet, or represent 802.11
> > natively throughout the rest of the net stack?
> >
> > The former causes various and sundry hacks, and the latter requires that
> > you touch a bunch of non-802.11 code to make it aware of a new frame class.
>
> The former, most importantly, can cause the packet to get copied.
> Actually, this depends upon how you implement things and when the
> header change occurs.
>
> My vote is for making the whole of the networking 802.11 frame class
> aware.
Agreed :-)
- Arnaldo
^ permalink raw reply
* Re: [PATCH] ACX: swap netdevice_t for struct net_device
From: Denis Vlasenko @ 2006-01-15 11:06 UTC (permalink / raw)
To: acx100-devel; +Cc: Carlos Martín, netdev
In-Reply-To: <200601150043.34890.carlos@cmartin.tk>
On Sunday 15 January 2006 01:43, Carlos Martín wrote:
> Hi,
>
> Does netdevice_t serve any actual purpose now? It used to be for 2.2/2.4
> compatibility, but we don't have that anymore.
>
> Attached patch does a s/netdevice_t/struct net_device/g on all the files that
> required it. It's against 20060114
Too late :)
acx-20060115 already has no netdevice_t.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: wireless: recap of current issues (stack)
From: Ulrich Kunitz @ 2006-01-15 10:04 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Ulrich Kunitz, linville, netdev, linux-kernel, dsd
In-Reply-To: <20060114204211.72942d45.zaitcev@redhat.com>
On Sat, 14 Jan 2006, Pete Zaitcev wrote:
> On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <kune@deine-taler.de> wrote:
>
> > [...] Register accesses in USB devices should be
> > able to sleep. However the 80211 stacks I've seen so far have a
> > fixed set of capabilities and do also assume, that at the driver
> > layer everything can be done in atomic mode, which is only true
> > for buses that support memory-mapping.
>
> If this problem is real, then it's serious. However, I'm not seeing it
> with prism54usb and Berg's softmac (yet?). Would you be so kind to provide
> the file name and function name for the code which makes these assumptions?
>
> Thanks,
> -- Pete
>
Pete,
I've been wrong.
I couldn't find the problem in the latest version of the
ieee80211softmac. Thank you for noticing me.
Uli
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: feyd @ 2006-01-15 9:35 UTC (permalink / raw)
To: netdev, linux-kernel
In-Reply-To: <20060113221935.GJ16166@tuxdriver.com>
John W. Linville wrote:
> Configuration seems to be coalescing around netlink. Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
On the other hand, the tree structure of sysfs can handle the
resource exclusivity and sharing naturaly.
A proposal of the layout:
template - template of device that can be created
profile - exclusive set of templates and other resources
plain SoftMAC card:
/sys/class/ieee80211/phy0/profile0/template0/mode # ap
| | /... # ap specific stuff
| |
| *--->/template1/mode # sta
| | /... # sta specific stuff
| |
| *--->/template2/mode # rfmon
| /... # rfmon specific stuff
|
*->/profile
/channel
/txpower
/... # other phy specific stuff
FullMAC card with mode constraints:
/sys/class/ieee80211/phy0/profile0/template0/mode # sta
| /... # sta specific stuff
|
*->/profile1/template0/mode # rfmon
| /... # rfmon specific stuff
|
*->/... # phy specific stuff
virtual interface:
/sys/class/ieee80211/sta0/parent # ->../phy0
/...
card with two chips that share some phy resources:
/sys/class/ieee80211/phy0/txpower # shared txpower
/...
/sys/class/ieee80211/phy1/parent # ->../phy0
/channel # independent
/...
/sys/class/ieee80211/phy2/parent # ->../phy0
/channel # independent
/...
Feyd
^ permalink raw reply
* Re: wireless: recap of current issues (stack)
From: Pete Zaitcev @ 2006-01-15 4:42 UTC (permalink / raw)
To: Ulrich Kunitz; +Cc: linville, netdev, linux-kernel, zaitcev, dsd
In-Reply-To: <Pine.LNX.4.58.0601141448480.5587@p15091797.pureserver.info>
On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <kune@deine-taler.de> wrote:
> [...] Register accesses in USB devices should be
> able to sleep. However the 80211 stacks I've seen so far have a
> fixed set of capabilities and do also assume, that at the driver
> layer everything can be done in atomic mode, which is only true
> for buses that support memory-mapping.
If this problem is real, then it's serious. However, I'm not seeing it
with prism54usb and Berg's softmac (yet?). Would you be so kind to provide
the file name and function name for the code which makes these assumptions?
Thanks,
-- Pete
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: David S. Miller @ 2006-01-15 1:51 UTC (permalink / raw)
To: jgarzik; +Cc: linville, netdev, linux-kernel
In-Reply-To: <43C97693.7000109@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Sat, 14 Jan 2006 17:09:23 -0500
> A big open issue: should you fake ethernet, or represent 802.11
> natively throughout the rest of the net stack?
>
> The former causes various and sundry hacks, and the latter requires that
> you touch a bunch of non-802.11 code to make it aware of a new frame class.
The former, most importantly, can cause the packet to get copied.
Actually, this depends upon how you implement things and when the
header change occurs.
My vote is for making the whole of the networking 802.11 frame class
aware.
^ permalink raw reply
* Re: wireless: recap of current issues (actions)
From: John W. Linville @ 2006-01-15 0:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
In-Reply-To: <43C9770F.1000400@pobox.com>
On Sat, Jan 14, 2006 at 05:11:27PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >Since we are toying with the issue of multiple stacks (at least in the
> >wireless development kernels), some thought needs to be done w.r.t. how
> >to make a final decision between the two stacks. An objective lists
> >of functional feature requirements seems like a good place to start.
> >IOW, I would like to have a list of features that would trigger the
> >removal of one stack shortly after the other stack achieves support
> >for the list. Is this feasible?
>
> Also, an objective and honest list of problems with both stacks should
> be considered...
Yes, someone (Johannes? Jiri?) had the beginnings of this a few days
ago, but I seem to have lost the link. Could someone repost it?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: John W. Linville @ 2006-01-15 0:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
In-Reply-To: <43C97693.7000109@pobox.com>
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >Other Issues
> >============
>
> A big open issue: should you fake ethernet, or represent 802.11
> natively throughout the rest of the net stack?
>
> The former causes various and sundry hacks, and the latter requires that
> you touch a bunch of non-802.11 code to make it aware of a new frame class.
I had this entry in the "compatibility" section:
We need to be an 802.11 stack (i.e. drivers need to handle 802.11
frames). Ethernet emulation is bound to paint us into a corner
eventually (if it hasn't already)
My opinion is that we need to 'bite the bullet' and make the kernel
aware of 802.11. I figure we can leverage some existing work by
davem and acme for this.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Adrian Bunk @ 2006-01-15 0:43 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: Jeff Garzik, saw, linux-kernel, netdev
In-Reply-To: <20060105210444.GA5878@xi.wantstofly.org>
On Thu, Jan 05, 2006 at 10:04:44PM +0100, Lennert Buytenhek wrote:
> On Thu, Jan 05, 2006 at 01:57:07PM -0500, Jeff Garzik wrote:
>
> > >This patch removes the obsolete drivers/net/eepro100.c driver.
> > >
> > >Is there any known problem in e100 still preventing us from removing
> > >this driver (it seems noone was able anymore to verify the ARM problem)?
> >
> > Still waiting to see if e100 in -mm works on ARM.
>
> e100 seems to work okay on the (modern) ARM CPUs I've tried. The case
> where e100 failed but eepro100 worked was (I think) on older ARM hardware,
> and I'm not sure whether that kind of hardware is used anymore..
Jeff, is this enough to accept my patch?
> cheers,
> Lennert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [PATCH] ACX: swap netdevice_t for struct net_device
From: Carlos Martín @ 2006-01-14 23:43 UTC (permalink / raw)
To: acx100-devel; +Cc: netdev, Denis Vlasenko
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Hi,
Does netdevice_t serve any actual purpose now? It used to be for 2.2/2.4
compatibility, but we don't have that anymore.
Attached patch does a s/netdevice_t/struct net_device/g on all the files that
required it. It's against 20060114
cmn
--
Carlos Martín http://www.cmartin.tk
"Erdbeben? Sicherlich etwas, das mit Erdberen zu tun hat." -- me, paraphrased
[-- Attachment #2: acx-kill-netdevice_t.patch --]
[-- Type: text/x-diff, Size: 7530 bytes --]
diff --git a/acx_func.h b/acx_func.h
index fb55e29..6798b79 100644
--- a/acx_func.h
+++ b/acx_func.h
@@ -352,7 +352,7 @@ acx_up_helper(wlandevice_t *priv, const
** IRQ -> acxpci_l_clean_txdesc -> acx_wake_queue
** Review carefully all callsites */
static inline void
-acx_stop_queue(netdevice_t *dev, const char *msg)
+acx_stop_queue(struct net_device *dev, const char *msg)
{
if (netif_queue_stopped(dev))
return;
@@ -363,14 +363,14 @@ acx_stop_queue(netdevice_t *dev, const c
}
static inline int
-acx_queue_stopped(netdevice_t *dev)
+acx_queue_stopped(struct net_device *dev)
{
return netif_queue_stopped(dev);
}
/*
static inline void
-acx_start_queue(netdevice_t *dev, const char *msg)
+acx_start_queue(struct net_device *dev, const char *msg)
{
netif_start_queue(dev);
if (msg)
@@ -379,7 +379,7 @@ acx_start_queue(netdevice_t *dev, const
*/
static inline void
-acx_wake_queue(netdevice_t *dev, const char *msg)
+acx_wake_queue(struct net_device *dev, const char *msg)
{
netif_wake_queue(dev);
if (msg)
@@ -387,7 +387,7 @@ acx_wake_queue(netdevice_t *dev, const c
}
static inline void
-acx_carrier_off(netdevice_t *dev, const char *msg)
+acx_carrier_off(struct net_device *dev, const char *msg)
{
netif_carrier_off(dev);
if (msg)
@@ -395,7 +395,7 @@ acx_carrier_off(netdevice_t *dev, const
}
static inline void
-acx_carrier_on(netdevice_t *dev, const char *msg)
+acx_carrier_on(struct net_device *dev, const char *msg)
{
netif_carrier_on(dev);
if (msg)
@@ -601,7 +601,7 @@ void acx_l_update_ratevector(wlandevice_
void acx_init_task_scheduler(wlandevice_t *priv);
void acx_schedule_task(wlandevice_t *priv, unsigned int set_flag);
-int acx_e_ioctl_old(netdevice_t *dev, struct ifreq *ifr, int cmd);
+int acx_e_ioctl_old(struct net_device *dev, struct ifreq *ifr, int cmd);
client_t *acx_l_sta_list_get(wlandevice_t *priv, const u8 *address);
void acx_l_sta_list_del(wlandevice_t *priv, client_t *clt);
@@ -634,7 +634,7 @@ const char* acx_get_packet_type_string(u
#endif
const char* acx_cmd_status_str(unsigned int state);
-int acx_i_start_xmit(struct sk_buff *skb, netdevice_t *dev);
+int acx_i_start_xmit(struct sk_buff *skb, struct net_device *dev);
void great_inquisitor(wlandevice_t *priv);
@@ -642,8 +642,8 @@ void acx_s_get_firmware_version(wlandevi
void acx_display_hardware_details(wlandevice_t *priv);
int acx_e_change_mtu(struct net_device *dev, int mtu);
-struct net_device_stats* acx_e_get_stats(netdevice_t *dev);
-struct iw_statistics* acx_e_get_wireless_stats(netdevice_t *dev);
+struct net_device_stats* acx_e_get_stats(struct net_device *dev);
+struct iw_statistics* acx_e_get_wireless_stats(struct net_device *dev);
int __init acxpci_e_init_module(void);
int __init acxusb_e_init_module(void);
diff --git a/common.c b/common.c
index 80fe316..b42f296 100644
--- a/common.c
+++ b/common.c
@@ -755,14 +755,14 @@ acx_e_change_mtu(struct net_device *dev,
** acx_e_get_stats, acx_e_get_wireless_stats
*/
struct net_device_stats*
-acx_e_get_stats(netdevice_t *dev)
+acx_e_get_stats(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
return &priv->stats;
}
struct iw_statistics*
-acx_e_get_wireless_stats(netdevice_t *dev)
+acx_e_get_wireless_stats(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
return &priv->wstats;
@@ -2801,7 +2801,7 @@ acx_l_handle_txrate_auto(wlandevice_t *p
** Called by network core. Can be called outside of process context.
*/
int
-acx_i_start_xmit(struct sk_buff *skb, netdevice_t *dev)
+acx_i_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
tx_t *tx;
@@ -3839,7 +3839,7 @@ acx_l_process_data_frame_client(wlandevi
{
const u8 *da, *bssid;
const wlan_hdr_t *hdr;
- netdevice_t *dev = priv->netdev;
+ struct net_device *dev = priv->netdev;
int result = NOT_OK;
FN_ENTER;
@@ -6492,7 +6492,7 @@ acx_s_after_interrupt_recalib(wlandevice
static void
acx_e_after_interrupt_task(void *data)
{
- netdevice_t *dev = (netdevice_t *) data;
+ struct net_device *dev = (struct net_device *) data;
wlandevice_t *priv = netdev_priv(dev);
FN_ENTER;
diff --git a/pci.c b/pci.c
index 4bc7b58..de0ddb3 100644
--- a/pci.c
+++ b/pci.c
@@ -95,14 +95,14 @@
/***********************************************************************
*/
-static void acxpci_i_tx_timeout(netdevice_t *dev);
+static void acxpci_i_tx_timeout(struct net_device *dev);
static irqreturn_t acxpci_i_interrupt(int irq, void *dev_id, struct pt_regs *regs);
-static void acxpci_i_set_multicast_list(netdevice_t *dev);
+static void acxpci_i_set_multicast_list(struct net_device *dev);
-static int acxpci_e_open(netdevice_t *dev);
-static int acxpci_e_close(netdevice_t *dev);
-static void acxpci_s_up(netdevice_t *dev);
-static void acxpci_s_down(netdevice_t *dev);
+static int acxpci_e_open(struct net_device *dev);
+static int acxpci_e_close(struct net_device *dev);
+static void acxpci_s_up(struct net_device *dev);
+static void acxpci_s_down(struct net_device *dev);
/***********************************************************************
@@ -177,7 +177,7 @@ write_flush(wlandevice_t *priv)
/***********************************************************************
*/
typedef struct acx_device {
- netdevice_t *newest;
+ struct net_device *newest;
} acx_device_t;
/* if this driver was only about PCI devices, then we probably wouldn't
@@ -1965,7 +1965,7 @@ enable_acx_irq(wlandevice_t *priv)
}
static void
-acxpci_s_up(netdevice_t *dev)
+acxpci_s_up(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
unsigned long flags;
@@ -2026,7 +2026,7 @@ disable_acx_irq(wlandevice_t *priv)
}
static void
-acxpci_s_down(netdevice_t *dev)
+acxpci_s_down(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
unsigned long flags;
@@ -2091,7 +2091,7 @@ acxpci_s_down(netdevice_t *dev)
** <0 driver reported error
*/
static int
-acxpci_e_open(netdevice_t *dev)
+acxpci_e_open(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
int result = OK;
@@ -2142,7 +2142,7 @@ done:
** <0 driver reported error
*/
static int
-acxpci_e_close(netdevice_t *dev)
+acxpci_e_close(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
@@ -2182,7 +2182,7 @@ acxpci_e_close(netdevice_t *dev)
** Called from network core. Must not sleep!
*/
static void
-acxpci_i_tx_timeout(netdevice_t *dev)
+acxpci_i_tx_timeout(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
unsigned long flags;
@@ -2231,7 +2231,7 @@ acxpci_i_tx_timeout(netdevice_t *dev)
** FIXME: most likely needs refinement
*/
static void
-acxpci_i_set_multicast_list(netdevice_t *dev)
+acxpci_i_set_multicast_list(struct net_device *dev)
{
wlandevice_t *priv = netdev_priv(dev);
unsigned long flags;
@@ -2512,7 +2512,7 @@ acxpci_i_interrupt(int irq, void *dev_id
register u16 irqtype;
u16 unmasked;
- priv = (wlandevice_t *) (((netdevice_t *) dev_id)->priv);
+ priv = (wlandevice_t *) (((struct net_device *) dev_id)->priv);
/* LOCKING: can just spin_lock() since IRQs are disabled anyway.
* I am paranoid */
diff --git a/wlan_compat.h b/wlan_compat.h
index 8a3b399..9a6ea6b 100644
--- a/wlan_compat.h
+++ b/wlan_compat.h
@@ -219,9 +219,6 @@
#define __WLAN_PRAGMA_PACK1__
#define __WLAN_PRAGMA_PACKDFLT__
-#undef netdevice_t
-typedef struct net_device netdevice_t;
-
/* Interrupt handler backwards compatibility stuff */
#ifndef IRQ_NONE
#define IRQ_NONE
^ permalink raw reply related
* Re: wireless: recap of current issues (configuration)
From: Dan Williams @ 2006-01-14 23:41 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060113221935.GJ16166@tuxdriver.com>
On Fri, 2006-01-13 at 17:19 -0500, John W. Linville wrote:
> Configuration
> =============
>
> Configuration seems to be coalescing around netlink. Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
>
> The kernel should provide generic handlers for netlink
> configuraion messages, and there should be a per-device 80211_ops
> (wireless_ops? akin to ethtool_ops) structure for drivers to
> populate appropriately.
One other thing: capability. It's not enough to be able to configure
the device, user-space tools also have to know what the device is
capable of before they try touching it. Ie, which ciphers, protocols,
channels, etc. Similar to the IWRANGE ioctl that there is now. Half
the problem now is that you can't reliably tell what drivers support
which features, or how much they support a particular feature. Think of
ethernet devices and whether or not they support carrier detection,
there's absolutely no way to tell that now (unless they respond to
ethtool or MII, and some cards freeze if you touch them with MII too
often).
Dan
^ permalink raw reply
* Re: [2.6.15] running tcpdump on 3c905b causes freeze (reproducable)
From: Folkert van Heusden @ 2006-01-14 23:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel
In-Reply-To: <20060114060457.06efae88.akpm@osdl.org>
> > > > > > > Have you tried enabling the NMI watchdog? Enable CONFIG_X86_LOCAL_APIC and
> > > > > > > boot with `nmi_watchdog=1' on the command line, make sure that the NMI line
> > > > > > > of /proc/interrupts is incrementing.
> > > > > > I'll give it a try. I've added it to the append-line in the lilo config.
> > > > > > Am now compiling the kernel.
> > > > > No change. Well, that is: the last message on the console now is
> > > > > "setting eth1 to promiscues mode".
> > > > Did you confirm that the NMI counters in /proc/interrupts are incrementing?
> > > Yes:
> > > root@muur:/home/folkert# for i in `seq 1 5` ; do cat /proc/interrupts | grep NMI ; sleep 1 ; done
> > > NMI: 6949080 6949067
...
> > > NMI: 6949488 6949475
> >
> > Is there anything else I can try?
> argh. I haven't forgotten. Hopefully after -rc1 I'll have more time...
Sorry :-)
> Your report didn't mention whether that card work OK under earlier 2.6
> kernels. If it does, a bit of bisection searching would really help.
2.6.15 crash
2.6.14.4 crash
2.6.14 crash
2.6.12.6 crash "NMI watchdog detected LOCKUP"
2.6.6 crash "NMI watchdog detected LOCKUP on CPU1 eip c02500aa, registers:"
2.6.1 would not boot
Folkert van Heusden
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: wireless: recap of current issues (stack)
From: Dan Williams @ 2006-01-14 23:29 UTC (permalink / raw)
To: Simon Kelley
Cc: Chase Venters, netdev, linux-kernel, Jiri Benc, Stefan Rompf,
Mike Kershaw, Krzysztof Halasa, Robert Hancock,
Alistair John Strachan, Dominik Brodowski, Denis Vlasenko,
Danny van Dyk, Stephen Hemminger, feyd, Andreas Mohr,
Bas Vermeulen, Jean Tourrilhes, Daniel Drake, Ulrich Kunitz,
Phil Dibowitz, Michael Buesch, Marcel Holtmann, Patrick McHardy,
Ingo Oeser, Harald Welte <la
In-Reply-To: <43C8D685.70805@thekelleys.org.uk>
On Sat, 2006-01-14 at 10:46 +0000, Simon Kelley wrote:
> Chase Venters wrote:
>
> > As an aside to this whole thing, I know we're talking about *kernel* wireless
> > but it's worthless to most people without good userland support as well.
> > Anyone have any thoughts and feelings on what things look like on the
> > desktop? I think if we work closely with some desktop people, we can shepard
> > in some wonderful new desktop support on top of the new netlink API.
> >
>
> An obvious place to start is the NetworkManager project. They should be
> asked the obvious "what do you need" and "does this provide it"
> questions. Dan Williams has been active recently producing small kernel
> patches which make the kernel side stuff work better with NM, so he
> might be a good contact to start with.
We are actually moving NM on top of wpa_supplicant for the actual
connection process. So essentially, while NM does talk to the card for
information and scanning, wpa_supplicant provides the bulk of the actual
connection process control. Any card that works with wpa_supplicant
should then work with NetworkManager.
Novel's is working on a KDE applet for NM which should hit CVS soon, I
think.
Dan
^ permalink raw reply
* Re: wireless: recap of current issues (actions)
From: Jeff Garzik @ 2006-01-14 22:11 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060113222512.GN16166@tuxdriver.com>
John W. Linville wrote:
> Actions
> =======
>
> I need to establish a public git tree for wireless. I would like for
> this to be on kernel.org, but I haven't got an account established
> there yet. I've been dragging my feet a little, hoping that the
> kernel.org account would materialize.
> Since we are toying with the issue of multiple stacks (at least in the
> wireless development kernels), some thought needs to be done w.r.t. how
> to make a final decision between the two stacks. An objective lists
> of functional feature requirements seems like a good place to start.
> IOW, I would like to have a list of features that would trigger the
> removal of one stack shortly after the other stack achieves support
> for the list. Is this feasible?
Also, an objective and honest list of problems with both stacks should
be considered...
Jeff
^ permalink raw reply
* Re: wireless: recap of current issues (other issues)
From: Jeff Garzik @ 2006-01-14 22:09 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060113222408.GM16166@tuxdriver.com>
John W. Linville wrote:
> Other Issues
> ============
A big open issue: should you fake ethernet, or represent 802.11
natively throughout the rest of the net stack?
The former causes various and sundry hacks, and the latter requires that
you touch a bunch of non-802.11 code to make it aware of a new frame class.
Jeff
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Jeff Garzik @ 2006-01-14 22:07 UTC (permalink / raw)
To: Stuffed Crust; +Cc: Johannes Berg, netdev, linux-kernel
In-Reply-To: <20060114011726.GA19950@shaftnet.org>
Stuffed Crust wrote:
> The hardware knows what frequencies it supports. Unfortunately this has
> to be a somewhat dynamic thing, as this is often not queryable until the
> device firmware is up and running.
>
> This can be accomplished by passing a static table to the
> register_wiphy_device() call (or perhaps via a struct wiphy_dev
> parameter) or through a more explicit, dynamic interface like:
>
> wiphy_register_supported_frequency(hw, 2412).
For completely programmable hardware, the stack should interact with a
module like ieee80211_geo, to help ensure the hardware stays within
legal limits.
Jeff
^ permalink raw reply
* [PATCH] fix ip[6]t_policy compiler warnings after x_tables merge
From: Harald Welte @ 2006-01-14 20:40 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]
Hi Dave!
Please apply, thanks.
[NETFILTER] ip[6]t_policy: Fix compilation warnings
ip[6]t_policy argument conversion slipped when merging with x_tables
Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Harald Welte <laforge@netfilter.org>
--- a/net/ipv4/netfilter/ipt_policy.c 2006-01-14 16:11:52.000000000 +0100
+++ b/net/ipv4/netfilter/ipt_policy.c 2006-01-14 18:55:26.000000000 +0100
@@ -95,7 +95,10 @@
static int match(const struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
- const void *matchinfo, int offset, int *hotdrop)
+ const void *matchinfo,
+ int offset,
+ unsigned int protoff,
+ int *hotdrop)
{
const struct ipt_policy_info *info = matchinfo;
int ret;
@@ -113,7 +116,7 @@
return ret;
}
-static int checkentry(const char *tablename, const struct ipt_ip *ip,
+static int checkentry(const char *tablename, const void *ip_void,
void *matchinfo, unsigned int matchsize,
unsigned int hook_mask)
{
--- a/net/ipv6/netfilter/ip6t_policy.c 2006-01-14 16:11:52.000000000 +0100
+++ b/net/ipv6/netfilter/ip6t_policy.c 2006-01-14 18:52:58.000000000 +0100
@@ -118,7 +118,7 @@
return ret;
}
-static int checkentry(const char *tablename, const struct ip6t_ip6 *ip,
+static int checkentry(const char *tablename, const void *ip_void,
void *matchinfo, unsigned int matchsize,
unsigned int hook_mask)
{
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [-mm patch] drivers/net/wireless/tiacx/: remove code for WIRELESS_EXT < 18
From: Adrian Bunk @ 2006-01-14 15:21 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: John W. Linville, jgarzik, netdev, linux-kernel
WIRELESS_EXT < 18 will never be true in the kernel.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/wireless/tiacx/acx_struct.h | 5
drivers/net/wireless/tiacx/common.c | 4
drivers/net/wireless/tiacx/conv.c | 2
drivers/net/wireless/tiacx/ioctl.c | 436 -----------------------
drivers/net/wireless/tiacx/pci.c | 8
drivers/net/wireless/tiacx/usb.c | 6
drivers/net/wireless/tiacx/wlan.c | 2
drivers/net/wireless/tiacx/wlan_compat.h | 10
8 files changed, 1 insertion(+), 472 deletions(-)
WIRELESS_EXT < 18 will never be true in the kernel.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/wireless/tiacx/acx_struct.h | 5
drivers/net/wireless/tiacx/common.c | 4
drivers/net/wireless/tiacx/conv.c | 2
drivers/net/wireless/tiacx/ioctl.c | 436 -----------------------
drivers/net/wireless/tiacx/pci.c | 8
drivers/net/wireless/tiacx/usb.c | 6
drivers/net/wireless/tiacx/wlan.c | 2
drivers/net/wireless/tiacx/wlan_compat.h | 10
8 files changed, 1 insertion(+), 472 deletions(-)
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/acx_struct.h.old 2005-12-03 02:58:36.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/acx_struct.h 2005-12-03 02:59:36.000000000 +0100
@@ -1053,9 +1053,8 @@
* the struct net_device. */
/*** Device statistics ***/
struct net_device_stats stats; /* net device statistics */
-#ifdef WIRELESS_EXT
struct iw_statistics wstats; /* wireless statistics */
-#endif
+
/*** Power managment ***/
struct pm_dev *pm; /* PM crap */
@@ -1103,9 +1102,7 @@
u8 scan_rate;
u16 scan_duration;
u16 scan_probe_delay;
-#if WIRELESS_EXT > 15
struct iw_spy_data spy_data; /* FIXME: needs to be implemented! */
-#endif
/*** Wireless network settings ***/
/* copy of the device address (ifconfig hw ether) that we actually use
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/common.c.old 2005-12-03 02:59:47.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/common.c 2005-12-03 03:00:04.000000000 +0100
@@ -46,9 +46,7 @@
#include <linux/wireless.h>
#include <linux/pm.h>
#include <linux/vmalloc.h>
-#if WIRELESS_EXT >= 13
#include <net/iw_handler.h>
-#endif /* WE >= 13 */
#include "acx.h"
@@ -2707,7 +2705,6 @@
acxlog(L_ASSOC, "%s(%d):%s\n",
__func__, new_status, acx_get_status_name(new_status));
-#if WIRELESS_EXT > 13 /* wireless_send_event() and SIOCGIWSCAN */
/* wireless_send_event never sleeps */
if (ACX_STATUS_4_ASSOCIATED == new_status) {
union iwreq_data wrqu;
@@ -2729,7 +2726,6 @@
wrqu.ap_addr.sa_family = ARPHRD_ETHER;
wireless_send_event(priv->netdev, SIOCGIWAP, &wrqu, NULL);
}
-#endif
priv->status = new_status;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/conv.c.old 2005-12-03 03:00:17.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/conv.c 2005-12-03 03:00:26.000000000 +0100
@@ -36,9 +36,7 @@
#include <linux/if_arp.h>
#include <linux/etherdevice.h>
#include <linux/wireless.h>
-#if WIRELESS_EXT >= 13
#include <net/iw_handler.h>
-#endif
#include "acx.h"
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/pci.c.old 2005-12-03 03:02:16.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/pci.c 2005-12-03 03:02:30.000000000 +0100
@@ -45,9 +45,7 @@
#include <linux/if_arp.h>
#include <linux/rtnetlink.h>
#include <linux/wireless.h>
-#if WIRELESS_EXT >= 13
#include <net/iw_handler.h>
-#endif
#include <linux/netdevice.h>
#include <linux/ioport.h>
#include <linux/pci.h>
@@ -1820,11 +1818,7 @@
dev->hard_start_xmit = &acx_i_start_xmit;
dev->get_stats = &acx_e_get_stats;
dev->get_wireless_stats = &acx_e_get_wireless_stats;
-#if WIRELESS_EXT >= 13
dev->wireless_handlers = (struct iw_handler_def *)&acx_ioctl_handler_def;
-#else
- dev->do_ioctl = &acx_e_ioctl_old;
-#endif
dev->set_multicast_list = &acxpci_i_set_multicast_list;
dev->tx_timeout = &acxpci_i_tx_timeout;
dev->change_mtu = &acx_e_change_mtu;
@@ -3842,7 +3836,6 @@
r100 = txdesc->u.r1.rate;
r111 = txdesc->u.r2.rate111;
-#if WIRELESS_EXT > 13 /* wireless_send_event() and IWEVTXDROP are WE13 */
/* need to check for certain error conditions before we
* clean the descriptor: we still need valid descr data here */
if (unlikely(0x30 & error)) {
@@ -3857,7 +3850,6 @@
MAC_COPY(wrqu.addr.sa_data, hdr->a1);
wireless_send_event(priv->netdev, IWEVTXDROP, &wrqu, NULL);
}
-#endif
/* ...and free the desc */
txdesc->error = 0;
txdesc->ack_failures = 0;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/wlan.c.old 2005-12-03 03:02:58.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/wlan.c 2005-12-03 03:03:02.000000000 +0100
@@ -43,9 +43,7 @@
#include <linux/types.h>
#include <linux/if_arp.h>
#include <linux/wireless.h>
-#if WIRELESS_EXT >= 13
#include <net/iw_handler.h>
-#endif
#include "acx.h"
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/wlan_compat.h.old 2005-12-03 03:03:11.000000000 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/wlan_compat.h 2005-12-03 03:03:19.000000000 +0100
@@ -228,15 +228,6 @@
typedef struct net_device netdevice_t;
#endif
-#ifdef WIRELESS_EXT
-#if (WIRELESS_EXT < 13)
-struct iw_request_info {
- __u16 cmd; /* Wireless Extension command */
- __u16 flags; /* More to come ;-) */
-};
-#endif
-#endif
-
/* Interrupt handler backwards compatibility stuff */
#ifndef IRQ_NONE
#define IRQ_NONE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--- linux-2.6.15-mm3-full/drivers/net/wireless/tiacx/ioctl.c.old 2006-01-14 15:56:54.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/wireless/tiacx/ioctl.c 2006-01-14 15:59:12.000000000 +0100
@@ -39,9 +39,7 @@
#include <linux/if_arp.h>
#include <linux/wireless.h>
-#if WIRELESS_EXT >= 13
#include <net/iw_handler.h>
-#endif /* WE >= 13 */
#include "acx.h"
@@ -330,11 +328,9 @@
case IW_MODE_AUTO:
priv->mode = ACX_MODE_OFF;
break;
-#if WIRELESS_EXT > 14
case IW_MODE_MONITOR:
priv->mode = ACX_MODE_MONITOR;
break;
-#endif /* WIRELESS_EXT > 14 */
case IW_MODE_ADHOC:
priv->mode = ACX_MODE_0_ADHOC;
break;
@@ -382,10 +378,8 @@
switch (priv->mode) {
case ACX_MODE_OFF:
*uwrq = IW_MODE_AUTO; break;
-#if WIRELESS_EXT > 14
case ACX_MODE_MONITOR:
*uwrq = IW_MODE_MONITOR; break;
-#endif /* WIRELESS_EXT > 14 */
case ACX_MODE_0_ADHOC:
*uwrq = IW_MODE_ADHOC; break;
case ACX_MODE_2_STA:
@@ -617,7 +611,6 @@
}
-#if WIRELESS_EXT > 13
/***********************************************************************
** acx_s_scan_add_station
*/
@@ -772,7 +765,6 @@
FN_EXIT1(result);
return result;
}
-#endif /* WIRELESS_EXT > 13 */
/*----------------------------------------------------------------
@@ -1486,39 +1478,6 @@
/***********************************************************************
-** Private functions
-*/
-
-#if WIRELESS_EXT < 13
-/***********************************************************************
-** acx_ioctl_get_iw_priv
-**
-** I added the monitor mode and changed the stuff below
-** to look more like the orinoco driver
-*/
-static int
-acx_ioctl_get_iw_priv(struct iwreq *iwr)
-{
- int result = -EINVAL;
-
- if (!iwr->u.data.pointer)
- return -EINVAL;
- result = verify_area(VERIFY_WRITE, iwr->u.data.pointer,
- sizeof(acx_ioctl_private_args));
- if (result)
- return result;
-
- iwr->u.data.length = VEC_SIZE(acx_ioctl_private_args);
- if (copy_to_user(iwr->u.data.pointer,
- acx_ioctl_private_args, sizeof(acx_ioctl_private_args)) != 0)
- result = -EFAULT;
-
- return result;
-}
-#endif
-
-
-/***********************************************************************
** acx_ioctl_get_nick
*/
static inline int
@@ -2585,7 +2544,6 @@
/***********************************************************************
*/
-#if WIRELESS_EXT >= 13
static const iw_handler acx_ioctl_handler[] =
{
(iw_handler) acx_ioctl_commit, /* SIOCSIWCOMMIT */
@@ -2624,13 +2582,8 @@
(iw_handler) acx_ioctl_get_ap, /* SIOCGIWAP */
(iw_handler) NULL, /* [nothing] */
(iw_handler) acx_ioctl_get_aplist, /* SIOCGIWAPLIST */
-#if WIRELESS_EXT > 13
(iw_handler) acx_ioctl_set_scan, /* SIOCSIWSCAN */
(iw_handler) acx_ioctl_get_scan, /* SIOCGIWSCAN */
-#else /* WE > 13 */
- (iw_handler) NULL, /* SIOCSIWSCAN */
- (iw_handler) NULL, /* SIOCGIWSCAN */
-#endif /* WE > 13 */
(iw_handler) acx_ioctl_set_essid, /* SIOCSIWESSID */
(iw_handler) acx_ioctl_get_essid, /* SIOCGIWESSID */
(iw_handler) acx_ioctl_set_nick, /* SIOCSIWNICKN */
@@ -2694,392 +2647,3 @@
.private_args = (struct iw_priv_args *) acx_ioctl_private_args,
};
-#endif /* WE >= 13 */
-
-
-#if WIRELESS_EXT < 13
-/***********************************************************************
-** Main function
-**
-** acx_e_ioctl_old
-**
-** This is the *OLD* ioctl handler.
-** Make sure to not only place your additions here, but instead mainly
-** in the new one (acx_ioctl_handler[])!
-*/
-int
-acx_e_ioctl_old(netdevice_t *dev, struct ifreq *ifr, int cmd)
-{
- wlandevice_t *priv = netdev_priv(dev);
- int result = 0;
- struct iwreq *iwr = (struct iwreq *)ifr;
-
- log(L_IOCTL, "%s cmd = 0x%04X\n", __func__, cmd);
-
- /* This is the way it is done in the orinoco driver.
- * Check to see if device is present.
- */
- if (0 == netif_device_present(dev)) {
- return -ENODEV;
- }
-
- switch (cmd) {
-/* WE 13 and higher will use acx_ioctl_handler_def */
- case SIOCGIWNAME:
- /* get name == wireless protocol */
- result = acx_ioctl_get_name(dev, NULL,
- (char *)&(iwr->u.name), NULL);
- break;
-
- case SIOCSIWNWID: /* pre-802.11, */
- case SIOCGIWNWID: /* not supported. */
- result = -EOPNOTSUPP;
- break;
-
- case SIOCSIWFREQ:
- /* set channel/frequency (Hz)
- data can be frequency or channel :
- 0-1000 = channel
- > 1000 = frequency in Hz */
- result = acx_ioctl_set_freq(dev, NULL, &(iwr->u.freq), NULL);
- break;
-
- case SIOCGIWFREQ:
- /* get channel/frequency (Hz) */
- result = acx_ioctl_get_freq(dev, NULL, &(iwr->u.freq), NULL);
- break;
-
- case SIOCSIWMODE:
- /* set operation mode */
- result = acx_ioctl_set_mode(dev, NULL, &(iwr->u.mode), NULL);
- break;
-
- case SIOCGIWMODE:
- /* get operation mode */
- result = acx_ioctl_get_mode(dev, NULL, &(iwr->u.mode), NULL);
- break;
-
- case SIOCSIWSENS:
- /* Set sensitivity */
- result = acx_ioctl_set_sens(dev, NULL, &(iwr->u.sens), NULL);
- break;
-
- case SIOCGIWSENS:
- /* Get sensitivity */
- result = acx_ioctl_get_sens(dev, NULL, &(iwr->u.sens), NULL);
- break;
-
-#if WIRELESS_EXT > 10
- case SIOCGIWRANGE:
- /* Get range of parameters */
- {
- struct iw_range range;
- result = acx_ioctl_get_range(dev, NULL,
- &(iwr->u.data), (char *)&range);
- if (copy_to_user(iwr->u.data.pointer, &range,
- sizeof(struct iw_range)))
- result = -EFAULT;
- }
- break;
-#endif
-
- case SIOCGIWPRIV:
- result = acx_ioctl_get_iw_priv(iwr);
- break;
-
- /* case SIOCSIWSPY: */
- /* case SIOCGIWSPY: */
- /* case SIOCSIWTHRSPY: */
- /* case SIOCGIWTHRSPY: */
-
- case SIOCSIWAP:
- /* set access point by MAC address */
- result = acx_ioctl_set_ap(dev, NULL, &(iwr->u.ap_addr),
- NULL);
- break;
-
- case SIOCGIWAP:
- /* get access point MAC address */
- result = acx_ioctl_get_ap(dev, NULL, &(iwr->u.ap_addr),
- NULL);
- break;
-
- case SIOCGIWAPLIST:
- /* get list of access points in range */
- result = acx_ioctl_get_aplist(dev, NULL, &(iwr->u.data),
- NULL);
- break;
-
-#if NOT_FINISHED_YET
- case SIOCSIWSCAN:
- /* start a station scan */
- result = acx_ioctl_set_scan(iwr, priv);
- break;
-
- case SIOCGIWSCAN:
- /* get list of stations found during scan */
- result = acx_ioctl_get_scan(iwr, priv);
- break;
-#endif
-
- case SIOCSIWESSID:
- /* set ESSID (network name) */
- {
- char essid[IW_ESSID_MAX_SIZE+1];
-
- if (iwr->u.essid.length > IW_ESSID_MAX_SIZE)
- {
- result = -E2BIG;
- break;
- }
- if (copy_from_user(essid, iwr->u.essid.pointer,
- iwr->u.essid.length))
- {
- result = -EFAULT;
- break;
- }
- result = acx_ioctl_set_essid(dev, NULL,
- &(iwr->u.essid), essid);
- }
- break;
-
- case SIOCGIWESSID:
- /* get ESSID */
- {
- char essid[IW_ESSID_MAX_SIZE+1];
- if (iwr->u.essid.pointer)
- result = acx_ioctl_get_essid(dev, NULL,
- &(iwr->u.essid), essid);
- if (copy_to_user(iwr->u.essid.pointer, essid,
- iwr->u.essid.length))
- result = -EFAULT;
- }
- break;
-
- case SIOCSIWNICKN:
- /* set nick */
- {
- char nick[IW_ESSID_MAX_SIZE+1];
-
- if (iwr->u.data.length > IW_ESSID_MAX_SIZE)
- {
- result = -E2BIG;
- break;
- }
- if (copy_from_user(nick, iwr->u.data.pointer,
- iwr->u.data.length))
- {
- result = -EFAULT;
- break;
- }
- result = acx_ioctl_set_nick(dev, NULL,
- &(iwr->u.data), nick);
- }
- break;
-
- case SIOCGIWNICKN:
- /* get nick */
- {
- char nick[IW_ESSID_MAX_SIZE+1];
- if (iwr->u.data.pointer)
- result = acx_ioctl_get_nick(dev, NULL,
- &(iwr->u.data), nick);
- if (copy_to_user(iwr->u.data.pointer, nick,
- iwr->u.data.length))
- result = -EFAULT;
- }
- break;
-
- case SIOCSIWRATE:
- /* set default bit rate (bps) */
- result = acx_ioctl_set_rate(dev, NULL, &(iwr->u.bitrate),
- NULL);
- break;
-
- case SIOCGIWRATE:
- /* get default bit rate (bps) */
- result = acx_ioctl_get_rate(dev, NULL, &(iwr->u.bitrate),
- NULL);
- break;
-
- case SIOCSIWRTS:
- /* set RTS threshold value */
- result = acx_ioctl_set_rts(dev, NULL, &(iwr->u.rts), NULL);
- break;
- case SIOCGIWRTS:
- /* get RTS threshold value */
- result = acx_ioctl_get_rts(dev, NULL, &(iwr->u.rts), NULL);
- break;
-
- /* case SIOCSIWFRAG: */
- /* case SIOCGIWFRAG: */
-
-#if WIRELESS_EXT > 9
- case SIOCGIWTXPOW:
- /* get tx power */
- result = acx_ioctl_get_txpow(dev, NULL, &(iwr->u.txpower),
- NULL);
- break;
-
- case SIOCSIWTXPOW:
- /* set tx power */
- result = acx_ioctl_set_txpow(dev, NULL, &(iwr->u.txpower),
- NULL);
- break;
-#endif
-
- case SIOCSIWRETRY:
- result = acx_ioctl_set_retry(dev, NULL, &(iwr->u.retry), NULL);
- break;
-
- case SIOCGIWRETRY:
- result = acx_ioctl_get_retry(dev, NULL, &(iwr->u.retry), NULL);
- break;
-
- case SIOCSIWENCODE:
- {
- /* set encoding token & mode */
- u8 key[29];
- if (iwr->u.encoding.pointer) {
- if (iwr->u.encoding.length > 29) {
- result = -E2BIG;
- break;
- }
- if (copy_from_user(key, iwr->u.encoding.pointer,
- iwr->u.encoding.length)) {
- result = -EFAULT;
- break;
- }
- }
- else
- if (iwr->u.encoding.length) {
- result = -EINVAL;
- break;
- }
- result = acx_ioctl_set_encode(dev, NULL,
- &(iwr->u.encoding), key);
- }
- break;
-
- case SIOCGIWENCODE:
- {
- /* get encoding token & mode */
- u8 key[29];
-
- result = acx_ioctl_get_encode(dev, NULL,
- &(iwr->u.encoding), key);
- if (iwr->u.encoding.pointer) {
- if (copy_to_user(iwr->u.encoding.pointer,
- key, iwr->u.encoding.length))
- result = -EFAULT;
- }
- }
- break;
-
- /******************** iwpriv ioctls below ********************/
-#if ACX_DEBUG
- case ACX100_IOCTL_DEBUG:
- acx_ioctl_set_debug(dev, NULL, NULL, iwr->u.name);
- break;
-#endif
-
- case ACX100_IOCTL_SET_PLED:
- acx100_ioctl_set_led_power(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_GET_PLED:
- acx100_ioctl_get_led_power(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_LIST_DOM:
- acx_ioctl_list_reg_domain(dev, NULL, NULL, NULL);
- break;
-
- case ACX100_IOCTL_SET_DOM:
- acx_ioctl_set_reg_domain(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_GET_DOM:
- acx_ioctl_get_reg_domain(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_SET_SCAN_PARAMS:
- acx_ioctl_set_scan_params(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_GET_SCAN_PARAMS:
- acx_ioctl_get_scan_params(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_SET_PREAMB:
- acx_ioctl_set_short_preamble(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_GET_PREAMB:
- acx_ioctl_get_short_preamble(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_SET_ANT:
- acx_ioctl_set_antenna(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_GET_ANT:
- acx_ioctl_get_antenna(dev, NULL, NULL, NULL);
- break;
-
- case ACX100_IOCTL_RX_ANT:
- acx_ioctl_set_rx_antenna(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_TX_ANT:
- acx_ioctl_set_tx_antenna(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_SET_ED:
- acx_ioctl_set_ed_threshold(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_SET_CCA:
- acx_ioctl_set_cca(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_MONITOR: /* set sniff (monitor) mode */
- log(L_IOCTL, "%s: IWPRIV monitor\n", dev->name);
-
- /* can only be done by admin */
- if (!capable(CAP_NET_ADMIN)) {
- result = -EPERM;
- break;
- }
- result = acx_ioctl_wlansniff(dev, NULL, NULL, iwr->u.name);
- break;
-
- case ACX100_IOCTL_TEST:
- acx_ioctl_unknown11(dev, NULL, NULL, NULL);
- break;
-
- case ACX111_IOCTL_INFO:
- acx111_ioctl_info(dev, NULL, NULL, NULL);
- break;
-
- default:
- log(L_IOCTL, "wireless ioctl 0x%04X queried "
- "but not implemented yet\n", cmd);
- result = -EOPNOTSUPP;
- break;
- }
-
- if ((priv->dev_state_mask & ACX_STATE_IFACE_UP) && priv->set_mask) {
- acx_sem_lock(priv);
- acx_s_update_card_settings(priv);
- acx_sem_unlock(priv);
- }
-
- /* older WEs don't have a commit handler,
- * so we need to fix return code in this case */
- if (-EINPROGRESS == result)
- result = 0;
-
- return result;
-}
-#endif /* WE < 13 */
--- linux-2.6.15-mm3-full/drivers/net/wireless/tiacx/usb.c.old 2006-01-14 15:57:02.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/wireless/tiacx/usb.c 2006-01-14 15:57:31.000000000 +0100
@@ -57,9 +57,7 @@
#include <linux/rtnetlink.h>
#include <linux/etherdevice.h>
#include <linux/wireless.h>
-#if WIRELESS_EXT >= 13
#include <net/iw_handler.h>
-#endif
#include <linux/vmalloc.h>
#include "acx.h"
@@ -622,11 +620,7 @@
dev->hard_start_xmit = (void *)&acx_i_start_xmit;
dev->get_stats = (void *)&acx_e_get_stats;
dev->get_wireless_stats = (void *)&acx_e_get_wireless_stats;
-#if WIRELESS_EXT >= 13
dev->wireless_handlers = (struct iw_handler_def *)&acx_ioctl_handler_def;
-#else
- dev->do_ioctl = (void *)&acx_e_ioctl_old;
-#endif
dev->set_multicast_list = (void *)&acxusb_i_set_rx_mode;
#ifdef HAVE_TX_TIMEOUT
dev->tx_timeout = &acxusb_i_tx_timeout;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox