* Re: IP1000 gigabit nic driver
From: Andrew Morton @ 2006-05-03 12:43 UTC (permalink / raw)
To: Pekka Enberg; +Cc: dvrabel, romieu, linux-kernel, netdev, david
In-Reply-To: <1146475901.11271.3.camel@localhost>
On Mon, 01 May 2006 12:31:40 +0300
Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> [PATCH] IP1000 Gigabit Ethernet device driver
>
> This is a cleaned up fork of the IP1000A device driver:
>
> http://www.icplus.com.tw/driver-pp-IP1000A.html
Please remember that to merge this we'll need a signed-off-by from the
original developers. (That's not very gplish, but such is life).
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Pekka J Enberg @ 2006-05-03 13:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: dvrabel, romieu, linux-kernel, netdev, david
In-Reply-To: <20060503054300.b5e8b95f.akpm@osdl.org>
On Wed, 3 May 2006, Andrew Morton wrote:
> Please remember that to merge this we'll need a signed-off-by from the
> original developers. (That's not very gplish, but such is life).
OK. Lets see if we can track one of them developers down. I see Craig
Rich's email (only email found in the original mail) is out of date so if
anyone knows how to reach him, please let me know. Thanks!
Pekka
^ permalink raw reply
* Re: [PATCH] ipg: removing more dead code
From: Pekka J Enberg @ 2006-05-03 13:12 UTC (permalink / raw)
To: David Gómez; +Cc: Francois Romieu, David Vrabel, linux-kernel, netdev
In-Reply-To: <20060502223048.GA32038@fargo>
Hi David,
On Wed, 3 May 2006, David Gómezz wrote:
> I'll test it tomorrow ASAP. For now, here is another patch removing
> more dead code. This code is never reached (NOTGRACE is not defined)
> and the *fiber_detect functions are subsequently never used.
No need to resend this one, but in future, please follow the proper patch
format:
http://www.zipworld.com.au/~akpm/linux/patches/stuff/tpp.txt
Pekka
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 13:19 UTC (permalink / raw)
To: Alexey Toptygin; +Cc: Just Marc, netdev
In-Reply-To: <Pine.NEB.4.62.0605031206040.18261@otaku.freeshell.org>
On Wed, May 03, 2006 at 12:15:30PM +0000, Alexey Toptygin wrote:
>
> I'm curious, how would you do this without filling the disk? With a script
> that starts tcpdump to a ring in the background, waits for the offending
> log entry to appear and then kills tcpdump?
Well if you know the set of IPs that's likely to cause this you just
run tcpdump with an expression to filter out all traffic but those
IPs.
Sinec tcpdump only captures 100 bytes of each packet by default, it
should be manageable assuming that this problem occurs relatively
frequently.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: VJ Channel API - driver level (PATCH)
From: Leonid Grossman @ 2006-05-03 13:56 UTC (permalink / raw)
To: David S. Miller, shemminger; +Cc: alex, netdev
> -----Original Message-----
> From: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] On Behalf Of David S. Miller
> Sent: Tuesday, May 02, 2006 11:48 PM
> To: shemminger@osdl.org
> Cc: alex@neterion.com; netdev@vger.kernel.org
> Subject: Re: VJ Channel API - driver level (PATCH)
>
>
> I don't think we should be defining driver APIs when we
> haven't even figured out how the core of it would even work yet.
>
> A key part of this is the netfilter bits, that will require
> non-trivial flow identification, a hash will simply not be
> enough, and it will not be allowed to not support the
> netfilter bits properly since everyone will have netfilter
> enabled in one way or another.
Hi Dave,
Do you have suggestions on potential hardware assists/offloads for
netfilter?
I suppose some of it can be worthwhile, although in general may be too
complex to implement - especially above 1 Gig.
I'd expect high end NIC ASICs to implement rx steering based upon some
sort of hash (for load balancing), as well as explicit "1:1" steering
between a sw channel and a hw channel. Both options for channel
configuration are present in the driver interface.
If netfilter assists can be done in hardware, I agree the driver
interface will need to add support for these - otherwise, netfilter
processing will stay above the driver.
> -
> To unsubscribe from this list: send the line "unsubscribe
> netdev" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: David Vrabel @ 2006-05-03 14:15 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: Andrew Morton, romieu, linux-kernel, netdev, david
In-Reply-To: <Pine.LNX.4.58.0605031605060.19727@sbz-30.cs.Helsinki.FI>
Pekka J Enberg wrote:
> On Wed, 3 May 2006, Andrew Morton wrote:
>> Please remember that to merge this we'll need a signed-off-by from the
>> original developers. (That's not very gplish, but such is life).
>
> OK. Lets see if we can track one of them developers down. I see Craig
> Rich's email (only email found in the original mail) is out of date so if
> anyone knows how to reach him, please let me know. Thanks!
I think/guess that IC Plus bought out Sundance so you'd need to contact
someone at IC Plus.
David Vrabel
^ permalink raw reply
* [PATCH 0/3] d80211: bugfixes, reducing number of interfaces (again)
From: Jiri Benc @ 2006-05-03 15:11 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville
Following patches can be also obtained from:
git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git up
Jiri Benc:
d80211: get rid of default management interface
d80211: use alloc_netdev
d80211: fix is_ieee80211_device
net/d80211/ieee80211.c | 150 +++++++++++++++++++------------------------
net/d80211/ieee80211_i.h | 10 +-
net/d80211/ieee80211_iface.c | 104 ++++++++++++++++++++++-------
3 files changed, 152 insertions(+), 112 deletions(-)
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* [PATCH 1/3] d80211: get rid of default management interface
From: Jiri Benc @ 2006-05-03 15:11 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville
In-Reply-To: <20060503171031.304543000.midnight@suse.cz>
Default management interface (wmasterXap) confuses users. It is only needed
for AP mode (and only until the new netlink interface between kernel and
hostapd is implemented).
This patch removes default management interface. When first interface is
switched to AP mode, a management interface is created automatically.
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
net/d80211/ieee80211.c | 101 ++++++++++++++++++------------------------
net/d80211/ieee80211_i.h | 4 +-
net/d80211/ieee80211_iface.c | 74 +++++++++++++++++++++++++++++--
3 files changed, 117 insertions(+), 62 deletions(-)
d809b662083c69de844d5fdcf33a8ef149c90b8e
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index ffb7985..1d6e87c 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -1954,8 +1954,6 @@ static inline int identical_mac_addr_all
{
return (type1 == IEEE80211_IF_TYPE_MNTR ||
type2 == IEEE80211_IF_TYPE_MNTR ||
- type1 == IEEE80211_IF_TYPE_MGMT ||
- type2 == IEEE80211_IF_TYPE_MGMT ||
(type1 == IEEE80211_IF_TYPE_AP &&
type2 == IEEE80211_IF_TYPE_WDS) ||
(type1 == IEEE80211_IF_TYPE_WDS &&
@@ -1990,6 +1988,20 @@ static int ieee80211_master_stop(struct
return 0;
}
+static int ieee80211_ap_open(struct net_device *dev)
+{
+ struct ieee80211_local *local = dev->priv;
+
+ if (local->ap_open_count == 0)
+ return -EOPNOTSUPP;
+ return 0;
+}
+
+static int ieee80211_ap_stop(struct net_device *dev)
+{
+ return 0;
+}
+
/* Check if running monitor interfaces should go to a "soft monitor" mode
* and switch them if necessary. */
static inline void ieee80211_start_soft_monitor(struct ieee80211_local *local)
@@ -2032,7 +2044,6 @@ static int ieee80211_open(struct net_dev
struct net_device *ndev = nsdata->dev;
if (ndev != dev && ndev != local->mdev &&
- ndev != local->apdev &&
netif_running(ndev) &&
memcmp(dev->dev_addr, ndev->dev_addr, ETH_ALEN) == 0 &&
!identical_mac_addr_allowed(sdata->type, nsdata->type)) {
@@ -2087,7 +2098,11 @@ static int ieee80211_open(struct net_dev
}
local->open_count++;
- if (sdata->type == IEEE80211_IF_TYPE_MNTR)
+ if (sdata->type == IEEE80211_IF_TYPE_AP) {
+ local->ap_open_count++;
+ if (local->ap_open_count == 1)
+ dev_open(local->apdev);
+ } else if (sdata->type == IEEE80211_IF_TYPE_MNTR)
local->monitors++;
netif_start_queue(dev);
@@ -2112,7 +2127,11 @@ static int ieee80211_stop(struct net_dev
netif_stop_queue(dev);
- if (sdata->type == IEEE80211_IF_TYPE_MNTR)
+ if (sdata->type == IEEE80211_IF_TYPE_AP) {
+ local->ap_open_count--;
+ if (local->ap_open_count == 0)
+ dev_close(local->apdev);
+ } else if (sdata->type == IEEE80211_IF_TYPE_MNTR)
local->monitors--;
local->open_count--;
@@ -2367,6 +2386,10 @@ ieee80211_rx_mgmt(struct net_device *dev
if (msg_type != ieee80211_msg_monitor)
dev = local->apdev;
+ if (!dev) {
+ dev_kfree_skb(skb);
+ return;
+ }
skb->dev = dev;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
@@ -3998,6 +4021,19 @@ void ieee80211_if_setup(struct net_devic
dev->destructor = ieee80211_if_free;
}
+void ieee80211_if_ap_setup(struct net_device *dev)
+{
+ ether_setup(dev);
+ dev->hard_start_xmit = ieee80211_mgmt_start_xmit;
+ dev->change_mtu = ieee80211_change_mtu_apdev;
+ dev->get_stats = ieee80211_get_stats;
+ dev->open = ieee80211_ap_open;
+ dev->stop = ieee80211_ap_stop;
+ dev->type = ARPHRD_IEEE80211_PRISM;
+ dev->hard_header_parse = header_parse_80211;
+ dev->tx_queue_len = 0;
+ dev->destructor = ieee80211_if_free;
+}
static void ieee80211_precalc_rates(struct ieee80211_hw *hw)
{
@@ -4018,7 +4054,7 @@ static void ieee80211_precalc_rates(stru
struct net_device *ieee80211_alloc_hw(size_t priv_data_len,
void (*setup)(struct net_device *))
{
- struct net_device *apdev, *mdev;
+ struct net_device *mdev;
struct ieee80211_local *local;
struct ieee80211_sub_if_data *sdata;
int alloc_size;
@@ -4038,17 +4074,11 @@ struct net_device *ieee80211_alloc_hw(si
* 0b84 *****************
* * hw_priv *
* 1664 *****************
- * * ap net_dev *
- * 17c0 *****************
- * * sub_if *
- * *****************
*/
alloc_size = sizeof(struct net_device) +
sizeof(struct ieee80211_sub_if_data) + 3 +
sizeof(struct ieee80211_local) + 3 +
priv_data_len + 3 +
- sizeof(struct net_device) + 3 +
- sizeof(struct ieee80211_sub_if_data) + 3 +
4096;
mdev = (struct net_device *) kzalloc(alloc_size, GFP_KERNEL);
if (mdev == NULL)
@@ -4061,15 +4091,10 @@ struct net_device *ieee80211_alloc_hw(si
local = mdev->priv;
local->hw_priv = (void *)
((char *) local + ((sizeof(struct ieee80211_local) + 3) & ~3));
- apdev = (struct net_device *)
- ((char *) local->hw_priv + ((priv_data_len + 3) & ~3));
ether_setup(mdev);
memcpy(mdev->name, "wmaster%d", 10);
- if (strlen(mdev->name) + 2 >= sizeof(mdev->name))
- goto fail;
-
local->dev_index = -1;
local->mdev = mdev;
local->rx_handlers = ieee80211_rx_handlers;
@@ -4104,28 +4129,6 @@ struct net_device *ieee80211_alloc_hw(si
ieee80211_if_init(mdev);
- apdev = (struct net_device *)
- ((char *) local->hw_priv + ((priv_data_len + 3) & ~3));
- local->apdev = apdev;
- ether_setup(apdev);
- apdev->priv = local;
- apdev->hard_start_xmit = ieee80211_mgmt_start_xmit;
- apdev->change_mtu = ieee80211_change_mtu_apdev;
- apdev->get_stats = ieee80211_get_stats;
- apdev->open = ieee80211_open;
- apdev->stop = ieee80211_stop;
- apdev->type = ARPHRD_IEEE80211_PRISM;
- apdev->hard_header_parse = header_parse_80211;
- apdev->tx_queue_len = 0;
- sprintf(apdev->name, "%sap", mdev->name);
-
- sdata = IEEE80211_DEV_TO_SUB_IF(apdev);
- sdata->type = IEEE80211_IF_TYPE_MGMT;
- sdata->dev = apdev;
- sdata->master = mdev;
- sdata->local = local;
- list_add_tail(&sdata->list, &local->sub_if_list);
-
mdev->hard_start_xmit = ieee80211_master_start_xmit;
mdev->wireless_handlers =
(struct iw_handler_def *) &ieee80211_iw_handler_def;
@@ -4155,10 +4158,6 @@ struct net_device *ieee80211_alloc_hw(si
setup(mdev);
return mdev;
-
- fail:
- ieee80211_free_hw(mdev);
- return NULL;
}
@@ -4193,15 +4192,11 @@ int ieee80211_register_hw(struct net_dev
sta_info_start(local);
- result = register_netdev(local->apdev);
- if (result < 0)
- goto fail_1st_dev;
-
if (hw->fraglist)
dev->features |= NETIF_F_FRAGLIST;
result = register_netdev(dev);
if (result < 0)
- goto fail_2nd_dev;
+ goto fail_dev;
if (rate_control_initialize(local) < 0) {
printk(KERN_DEBUG "%s: Failed to initialize rate control "
@@ -4226,9 +4221,7 @@ int ieee80211_register_hw(struct net_dev
fail_rate:
unregister_netdev(dev);
-fail_2nd_dev:
- unregister_netdev(local->apdev);
-fail_1st_dev:
+fail_dev:
sta_info_stop(local);
ieee80211_unregister_sysfs(local);
fail_sysfs:
@@ -4247,12 +4240,6 @@ int ieee80211_update_hw(struct net_devic
if (hw->queues == 0)
hw->queues = 1;
- memcpy(local->apdev->dev_addr, dev->dev_addr, ETH_ALEN);
- local->apdev->base_addr = dev->base_addr;
- local->apdev->irq = dev->irq;
- local->apdev->mem_start = dev->mem_start;
- local->apdev->mem_end = dev->mem_end;
-
if (!hw->modes || !hw->modes->channels || !hw->modes->rates ||
!hw->modes->num_channels || !hw->modes->num_rates)
return -1;
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ee0b399..15dcc95 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -320,6 +320,7 @@ struct ieee80211_local {
struct net_device *apdev; /* wlan#ap - management frames (hostapd) */
int open_count;
int monitors;
+ int ap_count, ap_open_count;
struct ieee80211_conf conf;
int dev_index;
@@ -518,6 +519,7 @@ void ieee80211_prepare_rates(struct net_
void ieee80211_tx_set_iswep(struct ieee80211_txrx_data *tx);
int ieee80211_if_update_wds(struct net_device *dev, u8 *remote_addr);
void ieee80211_if_setup(struct net_device *dev);
+void ieee80211_if_ap_setup(struct net_device *dev);
/* ieee80211_ioctl.c */
int ieee80211_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
@@ -586,7 +588,7 @@ int ieee80211_dev_find_index(struct ieee
/* ieee80211_iface.c */
int ieee80211_if_add(struct net_device *dev, const char *name,
int format, struct net_device **new_dev);
-void ieee80211_if_set_type(struct net_device *dev, int type);
+int ieee80211_if_set_type(struct net_device *dev, int type);
void ieee80211_if_reinit(struct net_device *dev);
void __ieee80211_if_del(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata);
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index f3ce45f..2738c94 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -93,9 +93,64 @@ fail:
return ret;
}
-void ieee80211_if_set_type(struct net_device *dev, int type)
+static int ieee80211_if_add_apdev(struct net_device *dev)
+{
+ struct net_device *ndev;
+ struct ieee80211_local *local = dev->priv;
+ struct ieee80211_sub_if_data *sdata, *nsdata;
+ int alloc_size, ret;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ ASSERT_RTNL();
+ alloc_size = sizeof(struct net_device) + 3 +
+ sizeof(struct ieee80211_sub_if_data) + 3;
+
+ ndev = (struct net_device *) kzalloc(alloc_size, GFP_KERNEL);
+ if (ndev == NULL)
+ return -ENOMEM;
+ snprintf(ndev->name, IFNAMSIZ, "%sap", dev->name);
+
+ ndev->priv = local;
+ memcpy(ndev->dev_addr, dev->dev_addr, ETH_ALEN);
+ ndev->base_addr = dev->base_addr;
+ ndev->irq = dev->irq;
+ ndev->mem_start = dev->mem_start;
+ ndev->mem_end = dev->mem_end;
+ ieee80211_if_ap_setup(ndev);
+
+ nsdata = IEEE80211_DEV_TO_SUB_IF(ndev);
+ nsdata->type = IEEE80211_IF_TYPE_AP;
+ nsdata->master = local->mdev;
+ nsdata->dev = ndev;
+ nsdata->local = local;
+ ieee80211_if_sdata_init(nsdata);
+
+ ret = register_netdevice(ndev);
+ if (ret) {
+ if (ret == -EEXIST)
+ printk(KERN_DEBUG "%s: apdev name %s already exists\n",
+ dev->name, ndev->name);
+ kfree(ndev);
+ return ret;
+ }
+ local->apdev = ndev;
+ return 0;
+}
+
+static void ieee80211_if_del_apdev(struct net_device *dev)
+{
+ struct ieee80211_local *local = dev->priv;
+
+ ASSERT_RTNL();
+ unregister_netdevice(local->apdev);
+ local->apdev = NULL;
+}
+
+int ieee80211_if_set_type(struct net_device *dev, int type)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ struct ieee80211_local *local = dev->priv;
+ int res = 0;
sdata->type = type;
switch (type) {
@@ -110,7 +165,14 @@ void ieee80211_if_set_type(struct net_de
sdata->u.ap.max_ratectrl_rateidx = -1;
skb_queue_head_init(&sdata->u.ap.ps_bc_buf);
sdata->bss = &sdata->u.ap;
- break;
+ if (local->ap_count == 0)
+ res = ieee80211_if_add_apdev(sdata->master);
+ if (res == 0) {
+ local->ap_count++;
+ break;
+ }
+ sdata->type = IEEE80211_IF_TYPE_STA;
+ /* fallback to STA, but keep error value in `res' */
case IEEE80211_IF_TYPE_STA:
case IEEE80211_IF_TYPE_IBSS: {
struct ieee80211_sub_if_data *msdata;
@@ -137,7 +199,9 @@ void ieee80211_if_set_type(struct net_de
default:
printk(KERN_WARNING "%s: %s: Unknown interface type 0x%x",
dev->name, __FUNCTION__, type);
+ res = -EINVAL;
}
+ return res;
}
/* Must be called with rtnl lock held. */
@@ -189,6 +253,9 @@ #endif
local->total_ps_buffered--;
dev_kfree_skb(skb);
}
+ local->ap_count--;
+ if (local->ap_count == 0)
+ ieee80211_if_del_apdev(sdata->master);
}
break;
@@ -263,8 +330,7 @@ int ieee80211_if_remove(struct net_devic
list_for_each_entry_safe(sdata, n, &local->sub_if_list, list) {
if ((sdata->type == id || id == -1) &&
strcmp(name, sdata->dev->name) == 0 &&
- sdata->dev != local->mdev &&
- sdata->dev != local->apdev) {
+ sdata->dev != local->mdev) {
__ieee80211_if_del(local, sdata);
return 0;
}
--
1.3.0
^ permalink raw reply related
* [PATCH 2/3] d80211: use alloc_netdev
From: Jiri Benc @ 2006-05-03 15:11 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville
In-Reply-To: <20060503171031.304543000.midnight@suse.cz>
Now when there are no interfaces allocated together anymore, let's use
alloc_netdev for allocation of interfaces. We save some code and also
the structures are really aligned finally.
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
net/d80211/ieee80211.c | 43 ++++++++++++++++++++----------------------
net/d80211/ieee80211_i.h | 6 +-----
net/d80211/ieee80211_iface.c | 28 ++++++++++-----------------
3 files changed, 31 insertions(+), 46 deletions(-)
df3a812091d971e8cec93d51b5a54b6d2ecfb400
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 1d6e87c..fc56450 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -4057,43 +4057,40 @@ struct net_device *ieee80211_alloc_hw(si
struct net_device *mdev;
struct ieee80211_local *local;
struct ieee80211_sub_if_data *sdata;
- int alloc_size;
+ int priv_size;
- /* Ensure 32-bit alignment of our private data and hw private data.
- * Each net_device is followed by a sub_if_data which which is used
- * for wds/vlan information; it is aligned as well.
+ /* Ensure 32-byte alignment of our private data and hw private data.
+ * Each net_device is followed by a sub_if_data which is used for
+ * interface specific information.
*
* Sample memory map looks something like:
*
* 0000 *****************
* * net_dev *
- * 015c *****************
+ * 0160 *****************
* * sub_if *
- * 017c *****************
+ * 0180 *****************
* * local *
- * 0b84 *****************
+ * 0b80 *****************
* * hw_priv *
* 1664 *****************
*/
- alloc_size = sizeof(struct net_device) +
- sizeof(struct ieee80211_sub_if_data) + 3 +
- sizeof(struct ieee80211_local) + 3 +
- priv_data_len + 3 +
- 4096;
- mdev = (struct net_device *) kzalloc(alloc_size, GFP_KERNEL);
+ priv_size = ((sizeof(struct ieee80211_sub_if_data) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST) +
+ ((sizeof(struct ieee80211_local) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST) +
+ priv_data_len;
+ mdev = alloc_netdev(priv_size, "wmaster%d", ether_setup);
if (mdev == NULL)
return NULL;
- mdev->priv = (struct net_device *)
- ((char *) mdev +
- ((sizeof(struct net_device) + 3) & ~3) +
- ((sizeof(struct ieee80211_sub_if_data) + 3) & ~3));
+ mdev->priv = (char *)netdev_priv(mdev) +
+ ((sizeof(struct ieee80211_sub_if_data) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
local = mdev->priv;
- local->hw_priv = (void *)
- ((char *) local + ((sizeof(struct ieee80211_local) + 3) & ~3));
-
- ether_setup(mdev);
- memcpy(mdev->name, "wmaster%d", 10);
+ local->hw_priv = (char *)local +
+ ((sizeof(struct ieee80211_local) +
+ NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
local->dev_index = -1;
local->mdev = mdev;
@@ -4310,7 +4307,7 @@ void ieee80211_unregister_hw(struct net_
void ieee80211_free_hw(struct net_device *dev)
{
- kfree(dev);
+ free_netdev(dev);
}
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 15dcc95..5bf81ff 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -307,11 +307,7 @@ #define NUM_DEFAULT_KEYS 4
int channel_use_raw;
};
-#define IEEE80211_DEV_TO_SUB_IF(dev) ((struct ieee80211_sub_if_data *) \
- ((char *)(dev) + ((sizeof(struct net_device) + 3) & ~3)))
-#define IEEE80211_SUB_IF_TO_DEV(sub_if) ((struct net_device *) \
- ((char *)(sub_if) - ((sizeof(struct net_device) + 3) & ~3)))
-
+#define IEEE80211_DEV_TO_SUB_IF(dev) netdev_priv(dev)
struct ieee80211_local {
struct ieee80211_hw *hw;
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 2738c94..3e3e5ca 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -31,16 +31,12 @@ int ieee80211_if_add(struct net_device *
struct net_device *ndev, *tmp_dev;
struct ieee80211_local *local = dev->priv;
struct ieee80211_sub_if_data *sdata = NULL, *sdata_parent;
- int alloc_size;
int ret;
int i;
ASSERT_RTNL();
- /* ensure 32-bit alignment of our private data and hw private data */
- alloc_size = sizeof(struct net_device) + 3 +
- sizeof(struct ieee80211_sub_if_data) + 3;
-
- ndev = *new_dev = (struct net_device *) kzalloc(alloc_size, GFP_KERNEL);
+ ndev = *new_dev = alloc_netdev(sizeof(struct ieee80211_sub_if_data),
+ "", ieee80211_if_setup);
if (ndev == NULL)
return -ENOMEM;
@@ -68,7 +64,6 @@ int ieee80211_if_add(struct net_device *
ndev->mem_start = dev->mem_start;
ndev->mem_end = dev->mem_end;
ndev->flags = dev->flags & IFF_MULTICAST;
- ieee80211_if_setup(ndev);
sdata = IEEE80211_DEV_TO_SUB_IF(ndev);
sdata->type = IEEE80211_IF_TYPE_AP;
@@ -88,7 +83,7 @@ int ieee80211_if_add(struct net_device *
return 0;
fail:
- kfree(ndev);
+ free_netdev(ndev);
*new_dev = NULL;
return ret;
}
@@ -98,14 +93,13 @@ static int ieee80211_if_add_apdev(struct
struct net_device *ndev;
struct ieee80211_local *local = dev->priv;
struct ieee80211_sub_if_data *sdata, *nsdata;
- int alloc_size, ret;
+ int ret;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
ASSERT_RTNL();
- alloc_size = sizeof(struct net_device) + 3 +
- sizeof(struct ieee80211_sub_if_data) + 3;
- ndev = (struct net_device *) kzalloc(alloc_size, GFP_KERNEL);
+ ndev = alloc_netdev(sizeof(struct ieee80211_sub_if_data), "",
+ ieee80211_if_ap_setup);
if (ndev == NULL)
return -ENOMEM;
snprintf(ndev->name, IFNAMSIZ, "%sap", dev->name);
@@ -116,7 +110,6 @@ static int ieee80211_if_add_apdev(struct
ndev->irq = dev->irq;
ndev->mem_start = dev->mem_start;
ndev->mem_end = dev->mem_end;
- ieee80211_if_ap_setup(ndev);
nsdata = IEEE80211_DEV_TO_SUB_IF(ndev);
nsdata->type = IEEE80211_IF_TYPE_AP;
@@ -130,7 +123,7 @@ static int ieee80211_if_add_apdev(struct
if (ret == -EEXIST)
printk(KERN_DEBUG "%s: apdev name %s already exists\n",
dev->name, ndev->name);
- kfree(ndev);
+ free_netdev(ndev);
return ret;
}
local->apdev = ndev;
@@ -311,9 +304,8 @@ void __ieee80211_if_del(struct ieee80211
list_del(&sdata->list);
ieee80211_proc_deinit_virtual(dev);
unregister_netdevice(dev);
- /* Default data device and management device are allocated with the
- * master device. All other devices are separately allocated and will
- * be freed by net_device->destructor (i. e. ieee80211_if_free). */
+ /* Except master interface, the net_device will be freed by
+ * net_device->destructor (i. e. ieee80211_if_free). */
}
/* Must be called with rtnl lock held. */
@@ -343,7 +335,7 @@ void ieee80211_if_free(struct net_device
struct ieee80211_local *local = dev->priv;
BUG_ON(dev == local->mdev || dev == local->apdev);
- kfree(dev);
+ free_netdev(dev);
}
/* Must be called with rtnl lock held. */
--
1.3.0
^ permalink raw reply related
* [PATCH 3/3] d80211: fix is_ieee80211_device
From: Jiri Benc @ 2006-05-03 15:11 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville
In-Reply-To: <20060503171031.304543000.midnight@suse.cz>
Sending packets from management interface (wmasterXap) didn't work. This
patch fixes that problem; it's not nice but it will go away when the
interface between kernel and hostapd is changed to netlink (the packets will
be sent through master interface then).
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
net/d80211/ieee80211.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
e0a6647c8a9371e00cfcb15452c6b577bc863f37
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index fc56450..701c38b 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -59,6 +59,8 @@ static int rate_control_initialize(struc
static u8 * ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len);
+static int ieee80211_mgmt_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
struct ieee80211_key_conf *
ieee80211_key_data2conf(struct ieee80211_local *local,
@@ -1097,7 +1099,8 @@ __ieee80211_tx_prepare(struct ieee80211_
static int inline is_ieee80211_device(struct net_device *dev)
{
return (dev->wireless_handlers ==
- (struct iw_handler_def *) &ieee80211_iw_handler_def);
+ (struct iw_handler_def *) &ieee80211_iw_handler_def) ||
+ (dev->hard_start_xmit == ieee80211_mgmt_start_xmit);
}
/* Device in tx->dev has a reference added; use dev_put(tx->dev) when
--
1.3.0
^ permalink raw reply related
* RE: VJ Channel API - driver level (PATCH)
From: Caitlin Bestler @ 2006-05-03 15:56 UTC (permalink / raw)
To: Leonid Grossman, David S. Miller, shemminger; +Cc: alex, netdev
netdev-owner@vger.kernel.org wrote:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org
>> [mailto:netdev-owner@vger.kernel.org] On Behalf Of David S. Miller
>> Sent: Tuesday, May 02, 2006 11:48 PM
>> To: shemminger@osdl.org
>> Cc: alex@neterion.com; netdev@vger.kernel.org
>> Subject: Re: VJ Channel API - driver level (PATCH)
>>
>>
>> I don't think we should be defining driver APIs when we haven't even
>> figured out how the core of it would even work yet.
>>
>> A key part of this is the netfilter bits, that will require
>> non-trivial flow identification, a hash will simply not be enough,
>> and it will not be allowed to not support the netfilter bits properly
>> since everyone will have netfilter enabled in one way or another.
>
> Hi Dave,
>
> Do you have suggestions on potential hardware
> assists/offloads for netfilter?
>
> I suppose some of it can be worthwhile, although in general
> may be too complex to implement - especially above 1 Gig.
>
> I'd expect high end NIC ASICs to implement rx steering based
> upon some sort of hash (for load balancing), as well as
> explicit "1:1" steering between a sw channel and a hw
> channel. Both options for channel configuration are present
> in the driver interface.
> If netfilter assists can be done in hardware, I agree the
> driver interface will need to add support for these -
> otherwise, netfilter processing will stay above the driver.
>
>
Even if the hardware cannot fully implement netfilter rules
there is still value in having an interface that documents
exactly how much filtering a given piece of hardware can do.
There is no point in having the kernel repeat packet classifications
that have already been done by the NIC.
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
From: Jiri Benc @ 2006-05-03 16:28 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John W. Linville, netdev, jkmaline
In-Reply-To: <20060502211817.GA30842@instant802.com>
On Tue, 2 May 2006 14:18:17 -0700, Jouni Malinen wrote:
> Add a configuration option for disabling client MLME in kernel
> code. This is used to enable user space MLME for client mode (e.g.,
> with wpa_supplicant). The kernel MLME implementation is unmodified,
> but it could be removed or at least made optional in build
> configuration in the future.
It is too early for this. We need to implement some better communication
interface between kernel and hostapd (or what will implement userspace
MLME) first. The current solution, where there is some special
net_device interface (wmaster0ap) abused to dump informations to
userspace, is ugly and confusing for users.
There is no userspace MLME implementation yet. And if one is going to be
written, I'm really convinced it should be written in a clean way. I
think Simon said he would examine a possibility to convert this stuff to
netlink - is there some progress there?
Also, I'm not sure how fullmac cards could be (potentially) supported
with this approach.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* [PATCH] bcm43xx-d80211: rewrite interface handling
From: Michael Buesch @ 2006-05-03 16:42 UTC (permalink / raw)
To: John W. Linville; +Cc: Jiri Benc, netdev, bcm43xx-dev
Hi John,
Please apply to wireless-dev.
--
Rewrite the virtual interface handling.
With this monitor_during_oper is made possible.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h 2006-04-28 16:13:40.000000000 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h 2006-05-03 18:02:55.000000000 +0200
@@ -626,10 +626,32 @@
u8 algorithm;
};
+struct bcm43xx_interface {
+ /* Opaque ID of the operating interface (!= monitor
+ * interface) from the ieee80211 subsystem.
+ * Do not modify.
+ */
+ int if_id;
+ /* MAC address. */
+ u8 *mac_addr;
+ /* Current BSSID (if any). */
+ u8 *bssid;
+
+ /* Interface type. (IEEE80211_IF_TYPE_XXX) */
+ int type;
+ /* Counter of active monitor interfaces. */
+ int monitor;
+ /* Is the card operating in AP, STA or IBSS mode? */
+ unsigned int operating:1;
+ /* Promisc mode active?
+ * Note that (monitor != 0) implies promisc.
+ */
+ unsigned int promisc:1;
+};
+
struct bcm43xx_private {
struct ieee80211_hw *ieee;
struct ieee80211_low_level_stats ieee_stats;
- int iw_mode;
struct net_device *net_dev;
struct pci_dev *pci_dev;
@@ -653,6 +675,13 @@
short_slot:1, /* TRUE, if short slot timing is enabled. */
firmware_norelease:1; /* Do not release the firmware. Used on suspend. */
+ /* One physical device can have one operating interface
+ * and a virtually infinite amount of monitoring interfaces.
+ * This keeps track of the interfaces and the corresponding
+ * hardware modes.
+ */
+ struct bcm43xx_interface interface;
+ /* Various statistics about the physical device. */
struct bcm43xx_stats stats;
/* Bus type we are connected to.
@@ -716,8 +745,6 @@
/* Informational stuff. */
char nick[IW_ESSID_MAX_SIZE + 1];
- u8 bssid[ETH_ALEN];
- int interfaces;
/* encryption/decryption */
u16 security_offset;
@@ -854,6 +881,15 @@
return bcm;
}
+/* Is the device operating in a specified mode (IEEE80211_IF_TYPE_XXX). */
+static inline
+int bcm43xx_is_mode(struct bcm43xx_private *bcm, int type)
+{
+ if (type == IEEE80211_IF_TYPE_MNTR)
+ return !!bcm->interface.monitor;
+ return (bcm->interface.operating &&
+ bcm->interface.type == type);
+}
static inline
u16 bcm43xx_read16(struct bcm43xx_private *bcm, u16 offset)
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c 2006-04-28 16:13:40.000000000 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c 2006-05-03 18:00:46.000000000 +0200
@@ -217,7 +217,7 @@
bcm43xx_led_blink_stop(led, 0);
continue;
case BCM43xx_LED_APTRANSFER:
- if (bcm->iw_mode == IW_MODE_MASTER) {
+ if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP)) {
if (transferring) {
interval = BCM43xx_LEDBLINK_FAST;
turn_on = 1;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-04-28 16:13:40.000000000 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-05-03 18:12:27.000000000 +0200
@@ -378,18 +378,26 @@
static void bcm43xx_macfilter_clear(struct bcm43xx_private *bcm,
u16 offset)
{
- const u8 zero_addr[ETH_ALEN] = { 0 };
+ static const u8 zero_addr[ETH_ALEN] = { 0 };
bcm43xx_macfilter_set(bcm, offset, zero_addr);
}
static void bcm43xx_write_mac_bssid_templates(struct bcm43xx_private *bcm)
{
- const u8 *mac = (const u8 *)(bcm->net_dev->dev_addr);
- const u8 *bssid = bcm->bssid;
+ static const u8 zero_addr[ETH_ALEN] = { 0 };
+ const u8 *mac = NULL;
+ const u8 *bssid = NULL;
u8 mac_bssid[ETH_ALEN * 2];
int i;
+ bssid = bcm->interface.bssid;
+ if (!bssid)
+ bssid = zero_addr;
+ mac = bcm->interface.mac_addr;
+ if (!mac)
+ mac = zero_addr;
+
memcpy(mac_bssid, mac, ETH_ALEN);
memcpy(mac_bssid + ETH_ALEN, bssid, ETH_ALEN);
@@ -1438,15 +1446,15 @@
static void handle_irq_ps(struct bcm43xx_private *bcm)
{
- if (bcm->iw_mode == IW_MODE_MASTER) {
+ if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP)) {
///TODO: PS TBTT
} else {
if (1/*FIXME: the last PSpoll frame was sent successfully */)
bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
}
- if (bcm->iw_mode == IW_MODE_ADHOC)
+ bcm->reg124_set_0x4 = 0;
+ if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_IBSS))
bcm->reg124_set_0x4 = 1;
- //FIXME else set to false?
}
static void handle_irq_reg124(struct bcm43xx_private *bcm)
@@ -1456,7 +1464,6 @@
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS2_BITFIELD,
bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS2_BITFIELD)
| 0x4);
- //FIXME: reset reg124_set_0x4 to false?
}
static void handle_irq_pmq(struct bcm43xx_private *bcm)
@@ -1509,7 +1516,9 @@
* Request the 80211 subsystem to generate a new beacon
* frame and use it as template.
*/
- bcm->cached_beacon = ieee80211_beacon_get(bcm->net_dev, 0, &control);
+ bcm->cached_beacon = ieee80211_beacon_get(bcm->net_dev,
+ bcm->interface.if_id,
+ &control);
if (unlikely(!bcm->cached_beacon)) {
dprintkl(KERN_WARNING PFX "Could not generate beacon template.\n");
goto ack;
@@ -1603,7 +1612,7 @@
}
if (reason & BCM43xx_IRQ_BEACON) {
- if (bcm->iw_mode == IW_MODE_MASTER)
+ if (bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP))
handle_irq_beacon(bcm);
bcmirq_handled(BCM43xx_IRQ_BEACON);
}
@@ -2147,55 +2156,49 @@
printkl(KERN_ERR PFX "MAC suspend failed\n");
}
-void bcm43xx_set_iwmode(struct bcm43xx_private *bcm,
- int iw_mode)
+static void bcm43xx_select_opmode(struct bcm43xx_private *bcm)
{
- struct net_device *net_dev = bcm->net_dev;
u32 status;
u16 value;
- bcm->iw_mode = iw_mode;
- if (iw_mode == IW_MODE_MONITOR)
- net_dev->type = ARPHRD_IEEE80211;
- else
- net_dev->type = ARPHRD_ETHER;
-
status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- /* Reset status to infrastructured mode */
- status &= ~(BCM43xx_SBF_MODE_AP | BCM43xx_SBF_MODE_MONITOR);
+ /* Reset status to default STA mode */
+ status &= ~BCM43xx_SBF_MODE_AP;
+ status &= ~BCM43xx_SBF_MODE_MONITOR;
status &= ~BCM43xx_SBF_MODE_PROMISC;
status |= BCM43xx_SBF_MODE_NOTADHOC;
-/* FIXME: Always enable promisc mode, until we get the MAC filters working correctly. */
-status |= BCM43xx_SBF_MODE_PROMISC;
-
- switch (iw_mode) {
- case IW_MODE_MONITOR:
+ if (bcm->interface.operating) {
+ switch (bcm->interface.type) {
+ case IEEE80211_IF_TYPE_AP:
+ status |= BCM43xx_SBF_MODE_AP;
+ break;
+ case IEEE80211_IF_TYPE_IBSS:
+ status &= ~BCM43xx_SBF_MODE_NOTADHOC;
+ break;
+ case IEEE80211_IF_TYPE_STA:
+ case IEEE80211_IF_TYPE_MNTR:
+ case IEEE80211_IF_TYPE_WDS:
+ break;
+ default:
+ assert(0);
+ }
+ }
+ if (bcm->interface.monitor) {
status |= BCM43xx_SBF_MODE_MONITOR;
status |= BCM43xx_SBF_MODE_PROMISC;
- break;
- case IW_MODE_ADHOC:
- status &= ~BCM43xx_SBF_MODE_NOTADHOC;
- break;
- case IW_MODE_MASTER:
- status |= BCM43xx_SBF_MODE_AP;
- break;
- case IW_MODE_SECOND:
- case IW_MODE_REPEAT:
- TODO(); /* TODO */
- break;
- case IW_MODE_INFRA:
- /* nothing to be done here... */
- break;
- default:
- dprintk(KERN_ERR PFX "Unknown mode in set_iwmode: %d\n", iw_mode);
}
- if (net_dev->flags & IFF_PROMISC)
+ if (bcm->interface.promisc)
status |= BCM43xx_SBF_MODE_PROMISC;
+
+/* FIXME: Always enable promisc mode, until we get the MAC filters working correctly. */
+status |= BCM43xx_SBF_MODE_PROMISC;
+
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
value = 0x0002;
- if (iw_mode != IW_MODE_ADHOC && iw_mode != IW_MODE_MASTER) {
+ if ((status & BCM43xx_SBF_MODE_NOTADHOC) &&
+ !(status & BCM43xx_SBF_MODE_AP)) {
if (bcm->chip_id == 0x4306 && bcm->chip_rev == 3)
value = 0x0064;
else
@@ -2291,7 +2294,7 @@
bcm43xx_shm_write16(bcm, BCM43xx_SHM_SHARED, 0x0074, 0x0000);
/* Initially set the wireless operation mode. */
- bcm43xx_set_iwmode(bcm, bcm->iw_mode);
+ bcm43xx_select_opmode(bcm);
if (bcm->current_core->rev < 3) {
bcm43xx_write16(bcm, 0x060E, 0x0000);
@@ -2599,27 +2602,6 @@
return err;
}
-static void bcm43xx_gen_bssid(struct bcm43xx_private *bcm)
-{
- const u8 *mac = (const u8*)(bcm->net_dev->dev_addr);
- u8 *bssid = bcm->bssid;
-
- switch (bcm->iw_mode) {
- case IW_MODE_ADHOC:
- random_ether_addr(bssid);
- break;
- case IW_MODE_MASTER:
- case IW_MODE_INFRA:
- case IW_MODE_REPEAT:
- case IW_MODE_SECOND:
- case IW_MODE_MONITOR:
- memcpy(bssid, mac, ETH_ALEN);
- break;
- default:
- assert(0);
- }
-}
-
static void bcm43xx_rate_memory_write(struct bcm43xx_private *bcm,
u16 rate,
int is_ofdm)
@@ -2746,7 +2728,6 @@
/* Maximum Contention Window */
bcm43xx_shm_write32(bcm, BCM43xx_SHM_WIRELESS, 0x0004, 0x000003ff);
- bcm43xx_gen_bssid(bcm);
bcm43xx_write_mac_bssid_templates(bcm);
if (bcm->current_core->rev >= 5)
@@ -4169,13 +4150,8 @@
static int bcm43xx_net_open(struct net_device *net_dev)
{
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
- int res;
- res = bcm43xx_init_board(bcm);
- if (!res)
- return res;
- bcm43xx_set_iwmode(bcm, bcm->iw_mode);
- return 0;
+ return bcm43xx_init_board(bcm);
}
static int bcm43xx_net_stop(struct net_device *net_dev)
@@ -4194,33 +4170,91 @@
struct ieee80211_if_init_conf *conf)
{
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ unsigned long flags;
+ int err = -EOPNOTSUPP;
+
+ bcm43xx_lock_mmio(bcm, flags);
- if (bcm->interfaces > 0)
- return -ENOBUFS;
if (conf->type == IEEE80211_IF_TYPE_MNTR) {
- bcm->iw_mode = IW_MODE_MONITOR;
+ bcm->interface.monitor++;
} else {
- if (memcmp(bcm->net_dev->dev_addr, conf->mac_addr, ETH_ALEN) != 0)
- return -EADDRNOTAVAIL;
- if (conf->type == IEEE80211_IF_TYPE_STA)
- bcm->iw_mode = IW_MODE_INFRA;
- else if (conf->type == IEEE80211_IF_TYPE_IBSS)
- bcm->iw_mode = IW_MODE_ADHOC;
- else if (conf->type == IEEE80211_IF_TYPE_AP)
- bcm->iw_mode = IW_MODE_MASTER;
- else
- return -EOPNOTSUPP;
+ if (bcm->interface.operating)
+ goto out_unlock;
+ bcm->interface.operating = 1;
+ bcm->interface.if_id = conf->if_id;
+ bcm->interface.mac_addr = conf->mac_addr;
+ bcm->interface.type = conf->type;
}
- bcm->interfaces++;
- return 0;
+ if (bcm->initialized)
+ bcm43xx_select_opmode(bcm);
+ err = 0;
+
+ dprintk(KERN_INFO PFX "Virtual interface added "
+ "(type: 0x%08X, ID: %d, MAC: "
+ BCM43xx_MACFMT ")\n",
+ conf->type, conf->if_id,
+ BCM43xx_MACARG(conf->mac_addr));
+
+out_unlock:
+ bcm43xx_unlock_mmio(bcm, flags);
+
+ return err;
}
static void bcm43xx_remove_interface(struct net_device *net_dev,
struct ieee80211_if_init_conf *conf)
{
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ unsigned long flags;
+
+ bcm43xx_lock_mmio(bcm, flags);
+ if (conf->type == IEEE80211_IF_TYPE_MNTR) {
+ bcm->interface.monitor--;
+ assert(bcm->interface.monitor >= 0);
+ } else
+ bcm->interface.operating = 0;
+ if (bcm->initialized)
+ bcm43xx_select_opmode(bcm);
+ bcm43xx_unlock_mmio(bcm, flags);
+
+ dprintk(KERN_INFO PFX "Virtual interface removed "
+ "(type: 0x%08X, ID: %d, MAC: "
+ BCM43xx_MACFMT ")\n",
+ conf->type, conf->if_id,
+ BCM43xx_MACARG(conf->mac_addr));
+}
- bcm->interfaces--;
+static int bcm43xx_config_interface(struct net_device *net_dev,
+ int if_id,
+ struct ieee80211_if_conf *conf)
+{
+ struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ unsigned long flags;
+
+ bcm43xx_lock(bcm, flags);
+ if (conf->type != IEEE80211_IF_TYPE_MNTR) {
+ assert(bcm->interface.if_id == if_id);
+ bcm->interface.bssid = conf->bssid;
+ }
+ bcm43xx_unlock(bcm, flags);
+
+ return 0;
+}
+
+static void bcm43xx_set_multicast_list(struct net_device *net_dev,
+ unsigned short netflags,
+ int mc_count)
+{
+ struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ unsigned long flags;
+
+ bcm43xx_lock_mmio(bcm, flags);
+ if (bcm->interface.promisc != !!(netflags & IFF_PROMISC)) {
+ bcm->interface.promisc = !!(netflags & IFF_PROMISC);
+ if (bcm->initialized)
+ bcm43xx_select_opmode(bcm);
+ }
+ bcm43xx_unlock_mmio(bcm, flags);
}
/* Initialization of struct net_device, just after allocation. */
@@ -4294,6 +4328,8 @@
ieee->name = KBUILD_MODNAME;
ieee->host_gen_beacon = 1;
ieee->rx_includes_fcs = 1;
+ ieee->monitor_during_oper = 1;
+ ieee->channel_change_time = 20000;
ieee->tx = bcm43xx_net_hard_start_xmit;
ieee->open = bcm43xx_net_open;
ieee->stop = bcm43xx_net_stop;
@@ -4301,6 +4337,8 @@
ieee->remove_interface = bcm43xx_remove_interface;
ieee->reset = bcm43xx_net_reset;
ieee->config = bcm43xx_net_config;
+ ieee->config_interface = bcm43xx_config_interface;
+ ieee->set_multicast_list = bcm43xx_set_multicast_list;
//TODO ieee->set_key = bcm43xx_net_set_key;
ieee->get_stats = bcm43xx_net_get_stats;
ieee->queues = 1;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c 2006-04-28 16:13:40.000000000 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c 2006-05-03 17:59:58.000000000 +0200
@@ -94,7 +94,7 @@
bcm43xx_mac_suspend(bcm);
spin_lock(&phy->lock);
} else {
- if (bcm->iw_mode != IW_MODE_MASTER)
+ if (!bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP))
bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
}
phy->is_locked = 1;
@@ -111,7 +111,7 @@
bcm43xx_mac_enable(bcm);
}
} else {
- if (bcm->iw_mode != IW_MODE_MASTER)
+ if (!bcm43xx_is_mode(bcm, IEEE80211_IF_TYPE_AP))
bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
}
phy->is_locked = 0;
--
Greetings Michael.
^ permalink raw reply
* Re: RFC: au1000_etc.c phylib rewrite
From: Herbert Valerio Riedel @ 2006-05-03 16:34 UTC (permalink / raw)
To: Mark Schank
Cc: ppopov, sshtylyov, linux-mips, jgarzik, netdev, Ralf Baechle,
Robin H. Johnson
In-Reply-To: <5.1.0.14.2.20060502095256.01fd4210@205.166.54.3>
[-- Attachment #1: Type: text/plain, Size: 3773 bytes --]
hello *
On Tue, 2006-05-02 at 11:20 -0500, Mark Schank wrote:
> At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote:
> >On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote:
> > > The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned
> > > the board and switched to two single Broadcom phys, but they continued to
> > > control both phys through MAC0, which is the actual purpose of the
> > dual-phy
> > > hack. I am a user of the CSB655, so I sort of care.
> > >
> > > Will the new PHY framework allow a second PHY for a second MAC (MAC1) be
> > > controlled from the first MAC's (MAC0) mdio interface?
> >
> >should'nt be a problem (as opposed to the bosporus case... see below)...
> >I assume the phy-addresses on which the boarcom dual phy is configured
> >are the same for all Cogent CSB655 boards?
>
> Dual PHY configuration:
> MAC0 - phy addr 4
> MAC1 - phy addr 3
> Single PHY configuration:
> MAC0 - phy addr 1
> MAC1 - phy addr 0
while at it, does anyone happen to know what the phy-addr/MAC assignment
on the XXS1500 is?
> >does this need to be autodetected dynamically at runtime, or can we rely
> >on a compile time Kconfig-conditional to set a static phy-addr<->eth%
> >d-phy mapping for this board-specific case? Or de we really need such a
> >complex mii_probe() function to detect weird scenarios? :)
>
> The compile time Kconfig-conditional should be okay. The driver need to
> handle the fact that the MAC1's phy is controlled by MAC0's mdio
> interface. This means that MAC0 controller can not be disabled when the
> associated eth% device is down, otherwise you lose the ability to control
> MAC1's phy.
...or at least, the MAC associated with the particular MII bus should be
brought up if necessary before any mdio access (that's what I'm
implementing right now)
but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY doesn't
seem to be defined anywhere; shouldn't that be at least defined in some
Kconfig file, especially if the XXS1550 board is supposed to make use of
it?
btw, is the CSB655 supported at all in the 2.6 linux-mips branch, I
couldn't find any mention of it in Kconfig files either?
> >using static phy addr mappings would also allow for setting
> >board-specific phy-irq assignments, which would then be handled by the
> >phylib facilities, instead of polling the status of phy with a timer;
> >(and in case we don't have any board-specific compile time setting, we
> >can still fall back to search the phy-addresses for a PHY at runtime as
> >the generic case)
>
> Will the phylib facilities handle the case where two phys share a single IRQ?
afaics from the source, it doesn't handle the case of multiplexed phy
notification irqs; although the interrupt is requested with the SA_SHIRQ
flag, the first phy-interrupt-handler to be called already returns
IRQ_HANDLED... doesn't feel right in some way ;-)
> >while at it, what about that CONFIG_MIPS_BOSPORUS special case? why
> >doesn't the 2nd MAC see any PHY? how is the 2nd MAC connected to the
> >physical world?
>
> I don't have first hand knowledge of this board, but I have worked with
> Kendin switches before. They have a special port that allows direct
> connection of a MAC into the switch port without the use of a phy. The
> MAC's MII is directly connected to the switch ports MII. So instead of this:
> MAC <-> PHY <->PHY <-> Switch_Port
> You have this:
> MAC <-> Switch_Port
>
> So the MAC talks to the physical world via the switch.
thx; in the meantime, I've happened to find the board schematics and the
switch data-sheet in order to understand the situation better
regards,
hvr
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
From: Jouni Malinen @ 2006-05-03 16:44 UTC (permalink / raw)
To: Jiri Benc; +Cc: John W. Linville, netdev, jkmaline
In-Reply-To: <20060503182815.1a9ebb5e@griffin.suse.cz>
On Wed, May 03, 2006 at 06:28:15PM +0200, Jiri Benc wrote:
> It is too early for this. We need to implement some better communication
> interface between kernel and hostapd (or what will implement userspace
> MLME) first. The current solution, where there is some special
> net_device interface (wmaster0ap) abused to dump informations to
> userspace, is ugly and confusing for users.
Why do you think that this would be too early now? I agree that the
interface between kernel and user space MLME can be improved, but I see
no point in making client MLME implementation wait for that to happen.
Personally, I don't think that the wmaster#ap interface is really that
ugly, but I have nothing against this being improved if someone has time
for doing it. I just don't see it as the highest priority.
> There is no userspace MLME implementation yet. And if one is going to be
> written, I'm really convinced it should be written in a clean way. I
> think Simon said he would examine a possibility to convert this stuff to
> netlink - is there some progress there?
But there is.. I committed changes to the wpa_supplicant devel branch
for this yesterday. It seems to work fine with net/d80211 and bcm43xx
with this small patch to d80211 to allow the functionality to be moved
into user space.
I have not yet heard of anyone working with details of converting the
management frame communication to use netlink.
> Also, I'm not sure how fullmac cards could be (potentially) supported
> with this approach.
In the same way as with the kernel space MLME implementation.. This
does not really change regardless of where the MLME code is implemented.
Some time ago, I sent a preliminary patch showing what kind of changes
are needed and this was mainly avoiding calls to some ieee80211_sta.c
functions.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: Question on e1000 patch, rx-copy-break related.
From: Jesse Brandeburg @ 2006-05-03 17:22 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev, jeffrey.t.kirsher
In-Reply-To: <4457B96A.4030808@candelatech.com>
On 5/2/06, Ben Greear <greearb@candelatech.com> wrote:
> In commit: a292ca6efbc1f259ddfb9c902367f2588e0e8b0f
> to e1000_main.c, there is the change below.
>
> I am curious why the skb_put no longer subtracts ETHERNET_FCS_SIZE
> from the length. Is the idea that we will now always include the
> FCS at the end of the skb?
This is a long and hairy story behind this, but there is a bit called
SECRC that controls hardware stripping of the CRC. In *this* driver
we turned that bit on, so that we didn't have to mess with skb->len -=
4 and the nasty negative unwrap if we were using multiple descriptors
for rx.
Since then, we've removed multiple descriptor rx.
And after that, I've discovered that some BMCs are very unhappy if we
strip CRCs using SECRC.
So, my related question is: is it okay if we just always leave the CRC
on the end of the data? It doesn't seem to harm anything.
> It also seems that the skb_put for the else clause is missing here, but
> I think it is fixed in some later patch.
>
> The main reason I ask is that I have a patch that enabled reception of the
> FCS in 2.6.13. It used a flag to determine whether to subtract the ETHERNET_FCS_SIZE
> from length (or not, if we are capturing FCS). I am trying to figure out if this
> is still needed in the later releases.
Well, its a changing picture. I had planned to eventually enable the
hardware to strip the CRC if we aren't connected to some kind of
offboard management. We'll get there in steps.
> Thanks,
> Ben
>
> @@ -3613,17 +3618,40 @@ #endif
> }
> }
>
> - /* Good Receive */
> - skb_put(skb, length - ETHERNET_FCS_SIZE);
> + /* code added for copybreak, this should improve
> + * performance for small packets with large amounts
> + * of reassembly being done in the stack */
> +#define E1000_CB_LENGTH 256
> + if ((length < E1000_CB_LENGTH) &&
> + !rx_ring->rx_skb_top &&
> + /* or maybe (status & E1000_RXD_STAT_EOP) && */
> + !multi_descriptor) {
> + struct sk_buff *new_skb =
> + dev_alloc_skb(length + NET_IP_ALIGN);
> + if (new_skb) {
> + skb_reserve(new_skb, NET_IP_ALIGN);
> + new_skb->dev = netdev;
> + memcpy(new_skb->data - NET_IP_ALIGN,
> + skb->data - NET_IP_ALIGN,
> + length + NET_IP_ALIGN);
> + /* save the skb in buffer_info as good */
> + buffer_info->skb = skb;
> + skb = new_skb;
> + skb_put(skb, length);
> + }
> + }
> +
> + /* end copybreak code */
^ permalink raw reply
* Re: [PATCH] bcm43xx-d80211: rewrite interface handling
From: Jiri Benc @ 2006-05-03 17:44 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, netdev, bcm43xx-dev
In-Reply-To: <200605031842.04801.mb@bu3sch.de>
On Wed, 3 May 2006 18:42:04 +0200, Michael Buesch wrote:
> Rewrite the virtual interface handling.
> With this monitor_during_oper is made possible.
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Jiri Benc <jbenc@suse.cz>
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* RE: VJ Channel API - driver level (PATCH)
From: Caitlin Bestler @ 2006-05-03 17:52 UTC (permalink / raw)
To: Alex Aizman, netdev
Are you proposing a mechanism for the consuming end of a tx
channel to support a large number of channels, or are you
assuming that the number of tx channels will be small enough
that simply polling them in priority order is adequate?
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: Evgeniy Polyakov @ 2006-05-03 18:07 UTC (permalink / raw)
To: Caitlin Bestler
Cc: Leonid Grossman, David S. Miller, shemminger, alex, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149E880@NT-SJCA-0751.brcm.ad.broadcom.com>
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler (caitlinb@broadcom.com) wrote:
> > I'd expect high end NIC ASICs to implement rx steering based
> > upon some sort of hash (for load balancing), as well as
> > explicit "1:1" steering between a sw channel and a hw
> > channel. Both options for channel configuration are present
> > in the driver interface.
> > If netfilter assists can be done in hardware, I agree the
> > driver interface will need to add support for these -
> > otherwise, netfilter processing will stay above the driver.
> >
> >
>
> Even if the hardware cannot fully implement netfilter rules
> there is still value in having an interface that documents
> exactly how much filtering a given piece of hardware can do.
> There is no point in having the kernel repeat packet classifications
> that have already been done by the NIC.
Please do not suppose that vj channel must rely on underlaying hardware.
New interface MUST work better or at least not worse than existing skb
queueing for majority of users, and I doubt users with netfilter capable
hardware are there.
It is only some hint to the SW, not rules, that hardware can provide.
The best would be ipv4/ipv6 hashing, and I think it is enough.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
From: Jiri Benc @ 2006-05-03 18:10 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John W. Linville, netdev, jkmaline
In-Reply-To: <20060503164458.GB10524@instant802.com>
On Wed, 3 May 2006 09:44:58 -0700, Jouni Malinen wrote:
> Why do you think that this would be too early now? I agree that the
> interface between kernel and user space MLME can be improved, but I see
> no point in making client MLME implementation wait for that to happen.
> Personally, I don't think that the wmaster#ap interface is really that
> ugly, but I have nothing against this being improved if someone has time
> for doing it. I just don't see it as the highest priority.
On the other hand, I'm afraid it will be hard to explain to users why
there are all these network interfaces (wmaster0, wmaster0ap) they
shouldn't touch at all. I'm trying to reduce those interfaces as much as
possible. We cannot avoid wmaster0, but we can avoid wmaster0ap. So I
see the new kernel->hostapd (wpa_supplicant) interface as a rather high
priority.
> But there is.. I committed changes to the wpa_supplicant devel branch
> for this yesterday. It seems to work fine with net/d80211 and bcm43xx
> with this small patch to d80211 to allow the functionality to be moved
> into user space.
Oh, sorry, didn't know that.
If you really feel this is a necessary feature (although I think we
should focus more on putting the stack to a form suitable for inclusion
in the kernel than on adding new features now), what about making the
wmaster0ap interface appear only when the device is switched to user
space MLME? Should I make a patch?
> I have not yet heard of anyone working with details of converting the
> management frame communication to use netlink.
With details - no, neither have I.
> > Also, I'm not sure how fullmac cards could be (potentially) supported
> > with this approach.
>
> In the same way as with the kernel space MLME implementation.. This
> does not really change regardless of where the MLME code is implemented.
I had in mind cards with large parts of MLME implemented in their
firmware, when MLME is moved from the stack fully to userspace. Such
cards probably won't allow you to handle e. g. scanning by switching
channels and sending probe requests. I know, we're not going to support
them soon, but isn't this something that will disallow the suppport at
all?
Or do I understand it wrong?
> Some time ago, I sent a preliminary patch showing what kind of changes
> are needed and this was mainly avoiding calls to some ieee80211_sta.c
> functions.
Hm, I probably missed that patch (or maybe just can't remember). Could
you post a link or something?
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* RE: VJ Channel API - driver level (PATCH)
From: Caitlin Bestler @ 2006-05-03 18:12 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: Leonid Grossman, David S. Miller, shemminger, alex, netdev
Evgeniy Polyakov wrote:
> On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
> (caitlinb@broadcom.com) wrote:
>>> I'd expect high end NIC ASICs to implement rx steering based upon
>>> some sort of hash (for load balancing), as well as explicit "1:1"
>>> steering between a sw channel and a hw channel. Both options for
>>> channel configuration are present in the driver interface.
>>> If netfilter assists can be done in hardware, I agree the driver
>>> interface will need to add support for these - otherwise, netfilter
>>> processing will stay above the driver.
>>>
>>>
>>
>> Even if the hardware cannot fully implement netfilter rules there is
>> still value in having an interface that documents exactly how much
>> filtering a given piece of hardware can do.
>> There is no point in having the kernel repeat packet classifications
>> that have already been done by the NIC.
>
> Please do not suppose that vj channel must rely on
> underlaying hardware.
> New interface MUST work better or at least not worse than
> existing skb queueing for majority of users, and I doubt
> users with netfilter capable hardware are there.
> It is only some hint to the SW, not rules, that hardware can provide.
> The best would be ipv4/ipv6 hashing, and I think it is enough.
I agree. I was just stating that *if* there is direct hardware
support then the software should be enabled to skip
redundant checks. What I'm suggesting is really the
equivalent of knowing whether the hardware generates
or checks CRCs and TCP checksums. Don't mandate
the feature, just have the option to avoid redundant work.
^ permalink raw reply
* Re: Question on e1000 patch, rx-copy-break related.
From: Ben Greear @ 2006-05-03 18:12 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: NetDev, jeffrey.t.kirsher
In-Reply-To: <4807377b0605031022s3b5bfad2x757fbd470884c6fd@mail.gmail.com>
Jesse Brandeburg wrote:
> On 5/2/06, Ben Greear <greearb@candelatech.com> wrote:
>
>> In commit: a292ca6efbc1f259ddfb9c902367f2588e0e8b0f
>> to e1000_main.c, there is the change below.
>>
>> I am curious why the skb_put no longer subtracts ETHERNET_FCS_SIZE
>> from the length. Is the idea that we will now always include the
>> FCS at the end of the skb?
>
>
> This is a long and hairy story behind this, but there is a bit called
> SECRC that controls hardware stripping of the CRC. In *this* driver
> we turned that bit on, so that we didn't have to mess with skb->len -=
> 4 and the nasty negative unwrap if we were using multiple descriptors
> for rx.
>
> Since then, we've removed multiple descriptor rx.
>
> And after that, I've discovered that some BMCs are very unhappy if we
> strip CRCs using SECRC.
>
> So, my related question is: is it okay if we just always leave the CRC
> on the end of the data? It doesn't seem to harm anything.
I believe it might mess up bridging logic if it tries to send the entire
skb to a peer interface, ie cause an extra 4 bytes to be written.
I know that this 'save-crc' feature did mess up my particular bridge-like
thing, but that could have been just bugs in my code.
Also, if the CRC data is there, but it is never 'put' into the skb, then
it will be correctly ignored by the stacks, including bridging, and hacks
such as my own that simply increase the skb-put by 4 bytes will work.
My personal preference is to set a flag in the skb struct indicating whether
or not the crc is appended (and skb_put). Then, bridging code can ignore it if needed,
and sniffers and such can get the CRC in user-land. To remain backwards compat,
at least the skb-put of the crc logic should default to OFF so that we don't
break any existing user-land bridging logic. I have the ethtool API logic written to
twiddle this save-crc behaviour if someone decides this is worthy of the kernel.
> Well, its a changing picture. I had planned to eventually enable the
> hardware to strip the CRC if we aren't connected to some kind of
> offboard management. We'll get there in steps.
So, as of 2.6.16.13, is the hardware stripping (SERC) enabled? Could
you also let me know where this bit is defined in case I want to twiddle
it myself (a quick grep for SERC in 2.6.16.13 yields nothing.)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Question on e1000 patch, rx-copy-break related.
From: Chris Leech @ 2006-05-03 18:21 UTC (permalink / raw)
To: Ben Greear; +Cc: Jesse Brandeburg, NetDev, jeffrey.t.kirsher
In-Reply-To: <4458F2A2.60605@candelatech.com>
On 5/3/06, Ben Greear <greearb@candelatech.com> wrote:
> So, as of 2.6.16.13, is the hardware stripping (SERC) enabled? Could
> you also let me know where this bit is defined in case I want to twiddle
> it myself (a quick grep for SERC in 2.6.16.13 yields nothing.)
You missed a C, it's SECRC (Strip Ethernet CRC) in the RCTL register
or E1000_RCTL_SECRC.
- Chris
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
From: Jouni Malinen @ 2006-05-03 18:35 UTC (permalink / raw)
To: Jiri Benc; +Cc: John W. Linville, netdev, jkmaline
In-Reply-To: <20060503201059.58477ea6@griffin.suse.cz>
On Wed, May 03, 2006 at 08:10:59PM +0200, Jiri Benc wrote:
> If you really feel this is a necessary feature (although I think we
> should focus more on putting the stack to a form suitable for inclusion
> in the kernel than on adding new features now), what about making the
> wmaster0ap interface appear only when the device is switched to user
> space MLME? Should I make a patch?
I think it would be nice to get this in so that both client and AP modes
can use the same mechanism (user space MLME); hostapd already needs this
wmaster0ap interface. In other words, if we do not want to see that
interface by default, we could just add a generic mechanism for
registering wmaster0ap that both hostapd and wpa_supplicant could use.
The Host AP driver (driver/net/wireless/hostap) is doing this with
PRISM2_PARAM_HOSTAPD parameter. I don't care how it's done, but some
simple mechanism would be preferred.
> I had in mind cards with large parts of MLME implemented in their
> firmware, when MLME is moved from the stack fully to userspace. Such
> cards probably won't allow you to handle e. g. scanning by switching
> channels and sending probe requests. I know, we're not going to support
> them soon, but isn't this something that will disallow the suppport at
> all?
No, move of MLME to user space should not change this at all. As an
example, wpa_supplicant supports both cases and the patch I'm working on
for getting Prism2 (full MAC for client mode) working with d80211 is
modifying the kernel side to allow this to be done. Both changes are
touching the same areas in the code, but there is no major change in
whether fullmac can be supported or not.
> > Some time ago, I sent a preliminary patch showing what kind of changes
> > are needed and this was mainly avoiding calls to some ieee80211_sta.c
> > functions.
>
> Hm, I probably missed that patch (or maybe just can't remember). Could
> you post a link or something?
http://hostap.epitest.fi/releases/testing/jkm-wireless-dev-patches.tar.gz
That is not up-to-date with wireless-dev.git anymore, though. The key
patch is d80211_fullmac_client.diff which is small enough to include
here. Please note that this is not yet complete, so consider it more an
example on what type of changes are needed.
d80211: Add support for hardware-based client MLME (fullmac)
Add support for using hardware/firmware-based client MLME (fullmac) into
the Devicescape IEEE 802.11 stack. This adds a new flag, hw_client_mlme,
for the low-level drivers to indicate that the client MLME (management
frame processing) is implemented in hardware/firmware. This disables
host-based MLME implementation for client mode.
In addition to changes in net/d80211, this patch fixes client mode for
the Prism2/2.5/3 driver in drivers/net/wireless/d80211 by using the new
mode of implementing client MLME in firmware. AP mode (Host AP) is still
using host-based MLME.
Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>
Index: wireless-dev/drivers/net/wireless/d80211/prism3_hw.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/prism3_hw.c
+++ wireless-dev/drivers/net/wireless/d80211/prism3_hw.c
@@ -2931,6 +2931,7 @@ static struct ieee80211_hw prism3_hw = {
.version = IEEE80211_VERSION,
.name = "prism3",
.host_broadcast_ps_buffering = 1,
+ .hw_client_mlme = 1,
.num_modes = 1,
.num_modes = NUM_ENTRIES(prism3_hw_modes),
.modes = prism3_hw_modes,
Index: wireless-dev/include/net/d80211.h
===================================================================
--- wireless-dev.orig/include/net/d80211.h
+++ wireless-dev/include/net/d80211.h
@@ -441,7 +441,11 @@ struct ieee80211_hw {
/* 1 = low-level driver supports skb fraglist (NETIF_F_FRAGLIST), i.e.,
* more than one skb per frame */
- unsigned int fraglist;
+ unsigned int fraglist:1;
+
+ /* 0 = client MLME in host software (softmac)
+ * 1 = client MLME in hardware/firmware (fullmac) */
+ unsigned int hw_client_mlme:1;
/* This is the time in us to change channels
*/
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===================================================================
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1028,10 +1028,16 @@ static int ieee80211_ioctl_scan_req(stru
u8 *pos = param->u.scan_req.ssid;
int left = param_len - ((u8 *) pos - (u8 *) param);
int len = param->u.scan_req.ssid_len;
+ struct ieee80211_local *local = dev->priv;
if (left < len || len > IEEE80211_MAX_SSID_LEN)
return -EINVAL;
+ if (local->hw->hw_client_mlme) {
+ /* TODO: add local->hw->scan_req() */
+ return 0;
+ }
+
return ieee80211_sta_req_scan(dev, pos, len);
}
@@ -1053,10 +1059,17 @@ static int ieee80211_ioctl_mlme(struct n
struct prism2_hostapd_param *param)
{
struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_local *local = dev->priv;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
if (sdata->type != IEEE80211_SUB_IF_TYPE_STA)
return -EINVAL;
+
+ if (local->hw->hw_client_mlme) {
+ /* TODO: add local->hw->mlme() */
+ return 0;
+ }
+
switch (param->u.mlme.cmd) {
case MLME_STA_DEAUTH:
ieee80211_sta_deauthenticate(dev, param->u.mlme.reason_code);
@@ -1116,7 +1129,8 @@ static int ieee80211_set_gen_ie(struct n
struct ieee80211_sub_if_data *sdata;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- if (sdata->type == IEEE80211_SUB_IF_TYPE_STA)
+ if (sdata->type == IEEE80211_SUB_IF_TYPE_STA &&
+ !local->hw->hw_client_mlme)
return ieee80211_sta_set_extra_ie(dev, ie, len);
kfree(local->conf.generic_elem);
@@ -1783,7 +1797,8 @@ static int ieee80211_ioctl_siwessid(stru
len--;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- if (sdata->type == IEEE80211_SUB_IF_TYPE_STA)
+ if (sdata->type == IEEE80211_SUB_IF_TYPE_STA &&
+ !local->hw->hw_client_mlme)
return ieee80211_sta_set_ssid(dev, ssid, len);
kfree(local->conf.ssid);
@@ -1806,7 +1821,8 @@ static int ieee80211_ioctl_giwessid(stru
struct ieee80211_sub_if_data *sdata;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- if (sdata->type == IEEE80211_SUB_IF_TYPE_STA) {
+ if (sdata->type == IEEE80211_SUB_IF_TYPE_STA &&
+ !local->hw->hw_client_mlme) {
int res = ieee80211_sta_get_ssid(dev, ssid, &len);
if (res == 0)
data->length = len;
@@ -1841,6 +1857,8 @@ static int ieee80211_ioctl_siwap(struct
printk(KERN_DEBUG "%s: Failed to config new BSSID to "
"the low-level driver\n", dev->name);
}
+ if (local->hw->hw_client_mlme)
+ return 0;
return ieee80211_sta_set_bssid(dev, (u8 *) &ap_addr->sa_data);
}
@@ -1877,6 +1895,11 @@ static int ieee80211_ioctl_siwscan(struc
ssid = local->conf.ssid;
ssid_len = local->conf.ssid_len;
}
+ if (local->hw->hw_client_mlme) {
+ /* TODO: add local->hw->scan_req() */
+ return 0;
+ }
+
return ieee80211_sta_req_scan(dev, ssid, ssid_len);
}
@@ -1887,6 +1910,13 @@ static int ieee80211_ioctl_giwscan(struc
{
int res;
struct ieee80211_local *local = dev->priv;
+
+ if (local->hw->hw_client_mlme) {
+ /* TODO: add local->hw->get_scan() */
+ data->length = 0;
+ return 0;
+ }
+
if (local->sta_scanning)
return -EAGAIN;
res = ieee80211_sta_scan_results(dev, extra, IW_SCAN_MAX_DATA);
@@ -2692,6 +2722,7 @@ static int ieee80211_ioctl_siwmlme(struc
struct iw_request_info *info,
struct iw_point *data, char *extra)
{
+ struct ieee80211_local *local = dev->priv;
struct ieee80211_sub_if_data *sdata;
struct iw_mlme *mlme = (struct iw_mlme *) extra;
@@ -2699,6 +2730,11 @@ static int ieee80211_ioctl_siwmlme(struc
if (sdata->type != IEEE80211_SUB_IF_TYPE_STA)
return -EINVAL;
+ if (local->hw->hw_client_mlme) {
+ /* TODO: add local->hw->mlme() */
+ return 0;
+ }
+
switch (mlme->cmd) {
case IW_MLME_DEAUTH:
/* TODO: mlme->addr.sa_data */
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-03 18:45 UTC (permalink / raw)
To: netdev
Cc: johnpol, caitlinb, Leonid.Grossman, davem, shemminger, alex,
yoshfuji
In-Reply-To: <20060503180740.GA14506@2ka.mipt.ru>
In article <20060503180740.GA14506@2ka.mipt.ru> (at Wed, 3 May 2006 22:07:40 +0400), Evgeniy Polyakov <johnpol@2ka.mipt.ru> says:
> > Even if the hardware cannot fully implement netfilter rules
> > there is still value in having an interface that documents
> > exactly how much filtering a given piece of hardware can do.
> > There is no point in having the kernel repeat packet classifications
> > that have already been done by the NIC.
>
> Please do not suppose that vj channel must rely on underlaying hardware.
> New interface MUST work better or at least not worse than existing skb
> queueing for majority of users, and I doubt users with netfilter capable
> hardware are there.
> It is only some hint to the SW, not rules, that hardware can provide.
> The best would be ipv4/ipv6 hashing, and I think it is enough.
And, I believe that, if a packet contains any ipv6 extension header(s),
including routing header, fragmentation header, etc.,
we should process it in kernel as we do for now.
Regards,
--yoshfuji
^ 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