* Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
From: Meelis Roos @ 2006-06-04 12:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <44804379.60808@trash.net>
> Please enable DEBUG_IP_FIREWALL_USER in net/netfilter/x_tables.c as well
> and retry. Results of the raw or mangle table would also be interesting
> because they contain a different number of built-in chains.
Sorry it took so long, I was away. Adding this define does not seem to
do much (table->private->number prints only):
On boot (1 nat rule):
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (1536 buckets, 12288 max) - 224 bytes per conntrack
translate_table: size 632
Finished chain 0
Finished chain 3
Finished chain 4
table->private->number = 4
t->private->number = 4
translate_table: size 800
Bad offset cba528d4
modprobe iptable_nat succeeded in manual modprobe.
modprobe iptable_filter:
translate_table: size 632
Bad offset cbbd910c
modprobe iptable_mangle:
translate_table: size 936
Bad offset cbbd80dc
modprobe iptable_raw:
translate_table: size 480
Bad offset cb8abd44
Retrying ifup and ifdown that tried to do iptables -D and iptables -I:
t->private->number = 4
t->private->number = 4
t->private->number = 4
translate_table: size 800
Bad offset cbbd80dc
t->private->number = 4
And retrying it more (succeeded this time):
t->private->number = 4
t->private->number = 4
translate_table: size 800
Finished chain 0
Finished chain 3
Finished chain 4
ip_tables: Translated table
do_replace: oldnum=4, initnum=4, newnum=5
t->private->number = 5
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-06-04 11:44 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606041214.45999.stefan@loplof.de>
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
On Sunday 4 June 2006 12:14, Stefan Rompf wrote:
> Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
>
> > Except for the bluetooth radio key (which should be supported by the
> > radiobtn interface as well) the other buttons have support through already
> > excisting input devices if I am correct.
>
> You are wrong for quite a bunch of laptop models. That's why I pointed you to
> the wistron_btns driver. Alternatively, look at the acerhk driver
> (http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a
> number of additional buttons that need to be handled by a special driver, all
> sent to userspace, and just one of them to trigger the wireless card. Other
> models just handle the button in ACPI and generate an additional ACPI event.
Ok, indeed a valid point.
Would it be better when the radio_button structure contains a list
of button structures each with its own poll function and current state.
And the radiobtn will loop through the list after each poll_delay time calling
all poll functions. That way drivers can specify themselves which buttons need to be polled.
By renaming enable_radio and disable_radio in the radiobtn structure it could
be made more generic for sending a certain event to the device and not only
an instruction for the radio.
> Looking at the RT2400-driver, I see what you want to accomplish: Take the view
> of the WLAN card on the hardware controlled button enable/disable and
> generate events on it. However, in many cases it is another driver (see
> above) that sets or clears this state, and this should be the instance to
> send the input event.
>
> Note that I do not have objections against the driver being included in the
> kernel - it just does not qualify as generic radiobutton support, but I know
> it's hard to find a good name ;-)
Thats true. :)
Now lets see how this thing can be made a but more generic. ;)
> Looking at the code only: There should be an additional non-polling interface
> for drivers that can generate events on the own.
Welll if the enable_radio and disable_radio are being renamed to a more
generic send_event for sending an event to the driver or something,
something similar can be done for the other way around I think, another handler
to send an event from driver to radiobtn. But should such an event also trigger
a call back to the driver, or should only the input event be triggered?
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Stefan Rompf @ 2006-06-04 10:14 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606041002.33696.IvDoorn@gmail.com>
Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
> Except for the bluetooth radio key (which should be supported by the
> radiobtn interface as well) the other buttons have support through already
> excisting input devices if I am correct.
You are wrong for quite a bunch of laptop models. That's why I pointed you to
the wistron_btns driver. Alternatively, look at the acerhk driver
(http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a
number of additional buttons that need to be handled by a special driver, all
sent to userspace, and just one of them to trigger the wireless card. Other
models just handle the button in ACPI and generate an additional ACPI event.
Looking at the RT2400-driver, I see what you want to accomplish: Take the view
of the WLAN card on the hardware controlled button enable/disable and
generate events on it. However, in many cases it is another driver (see
above) that sets or clears this state, and this should be the instance to
send the input event.
Note that I do not have objections against the driver being included in the
kernel - it just does not qualify as generic radiobutton support, but I know
it's hard to find a good name ;-)
Looking at the code only: There should be an additional non-polling interface
for drivers that can generate events on the own.
Stefan
^ permalink raw reply
* [PATCH] bcm43xx-d80211: Fix 64bit compiler warnings
From: Michael Buesch @ 2006-06-04 10:03 UTC (permalink / raw)
To: linville; +Cc: netdev, bcm43xx-dev
Fix all 64bit compiler warnings.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
index e882bc1..0f7303e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
@@ -227,7 +227,7 @@ static ssize_t tsf_write_file(struct fil
res = -EFAULT;
goto out_unlock;
}
- if (sscanf(buf, "%lli", &tsf) != 1) {
+ if (sscanf(buf, "%llu", (unsigned long long *)(&tsf)) != 1) {
printk(KERN_INFO PFX "debugfs: invalid values for \"tsf\"\n");
res = -EINVAL;
goto out_unlock;
@@ -449,11 +449,11 @@ void bcm43xx_printk_dump(const char *dat
size_t size,
const char *description)
{
- size_t i;
+ unsigned int i;
char c;
- printk(KERN_INFO PFX "Data dump (%s, %u bytes):",
- description, size);
+ printk(KERN_INFO PFX "Data dump (%s, %lu bytes):",
+ description, (unsigned long)size);
for (i = 0; i < size; i++) {
c = data[i];
if (i % 8 == 0)
@@ -468,12 +468,13 @@ void bcm43xx_printk_bitdump(const unsign
size_t bytes, int msb_to_lsb,
const char *description)
{
- size_t i;
+ unsigned int i;
int j;
const unsigned char *d;
- printk(KERN_INFO PFX "*** Bitdump (%s, %u bytes, %s) ***",
- description, bytes, msb_to_lsb ? "MSB to LSB" : "LSB to MSB");
+ printk(KERN_INFO PFX "*** Bitdump (%s, %lu bytes, %s) ***",
+ description, (unsigned long)bytes,
+ msb_to_lsb ? "MSB to LSB" : "LSB to MSB");
for (i = 0; i < bytes; i++) {
d = data + i;
if (i % 8 == 0)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..1dfd74e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -180,7 +180,7 @@ static int alloc_ringmemory(struct bcm43
if (ring->dmabase + BCM43xx_DMA_RINGMEMSIZE > BCM43xx_DMA_BUSADDRMAX) {
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RINGMEMORY >1G "
"(0x%08x, len: %lu)\n",
- ring->dmabase, BCM43xx_DMA_RINGMEMSIZE);
+ (unsigned int)ring->dmabase, BCM43xx_DMA_RINGMEMSIZE);
dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
ring->vbase, ring->dmabase);
return -ENOMEM;
@@ -292,7 +292,7 @@ static int setup_rx_descbuffer(struct bc
dev_kfree_skb_any(skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RX SKB >1G "
"(0x%08x, len: %u)\n",
- dmaaddr, ring->rx_buffersize);
+ (unsigned int)dmaaddr, ring->rx_buffersize);
return -ENOMEM;
}
meta->skb = skb;
@@ -711,7 +711,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA TX SKB >1G "
"(0x%08x, len: %u)\n",
- meta->dmaaddr, hdr_skb->len);
+ (unsigned int)meta->dmaaddr, hdr_skb->len);
return -ENOMEM;
}
@@ -742,7 +742,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA TX SKB >1G "
"(0x%08x, len: %u)\n",
- meta->dmaaddr, skb->len);
+ (unsigned int)meta->dmaaddr, skb->len);
return -ENOMEM;
}
--
Greetings Michael.
^ permalink raw reply related
* [PATCH] bcm43xx-d80211: add DMA rx poll workaround to DMA4
From: Michael Buesch @ 2006-06-04 9:41 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, bcm43xx-dev
This is the same patch as before, but for the dscape port.
Please apply to wireless-dev.
--
Also add the Poll RX DMA Memory workaround to the DMA4
(xmitstatus) path.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..ebe0984 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -604,25 +604,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x0000;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
- * in the lower 12 bits
+ * in the lower 12 bits.
+ * Note that the cookie must never be 0, as this
+ * is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x0000);
@@ -640,16 +643,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x0000:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma->tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma->tx_ring3;
break;
default:
@@ -867,8 +870,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb->data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw->cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i >= 10000)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw->cookie);
+ }
stat.flags = hw->flags;
stat.cnt1 = hw->cnt1;
stat.cnt2 = hw->cnt2;
--
Greetings Michael.
^ permalink raw reply related
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-06-04 8:02 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606031045.08763.stefan@loplof.de>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
On Saturday 3 June 2006 10:45, Stefan Rompf wrote:
> Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
>
> > > Or actually, I don't think the radiobtn/ won't be actually needed as
> > > prefix. The name passed to the radiobtn driver by the driver should be
> > > sufficient.
> >
> > Updated version,
> >
> > Signed-off-by Ivo van Doorn <IvDoorn@gmail.com>
>
> I don't like the patch in it's current form. Many notebooks have a number of
> additional keys that need to be queried/polled using the same interface, but
> just one button is to control the radio, the rest are multimedia keys that
> just need to be forwarded to userspace. Or maybe a bluetooth key.
Except for the bluetooth radio key (which should be supported by the radiobtn interface as well)
the other buttons have support through already excisting input devices if I am correct.
This radiobtn driver is there to poll the device frequently about the radio state only
since that is one of the few buttons that is not sending anything to userspace at the moment.
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* icmp or table->lock deadlock bug? (lockdep) (fwd)
From: James Morris @ 2006-06-04 4:09 UTC (permalink / raw)
To: netdev
---------- Forwarded message ----------
Date: Fri, 2 Jun 2006 16:31:44 -0700 (PDT)
From: Matthew L Foster <mfoster167@yahoo.com>
To: linux-kernel@vger.kernel.org
Cc: mfoster167@yahoo.com
Subject: icmp or table->lock deadlock bug? (lockdep)
Perhaps someone has hit this one already but in case not:
====================================
[ BUG: possible deadlock detected! ]
------------------------------------
kicker/2665 is trying to acquire lock:
(&table->lock){-.-+}, at: [<c02b1384>] ipt_do_table+0x68/0x294
but task is already holding lock:
(&table->lock){-.-+}, at: [<c02b1384>] ipt_do_table+0x68/0x294
which could potentially lead to deadlocks!
other info that might help us debug this:
2 locks held by kicker/2665:
#0: (&table->lock){-.-+}, at: [<c02b1384>] ipt_do_table+0x68/0x294
#1: (&sk->sk_lock.slock#3){-+..}, at: [<c029dab8>] icmp_send+0x100/0x332
stack backtrace:
<c01030b8> show_trace+0x16/0x19 <c0103586> dump_stack+0x1a/0x1f
<c012a880> __lockdep_acquire+0x6c6/0x907 <c012addb> lockdep_acquire+0x4b/0x63
<c02cdab1> _read_lock_bh+0x27/0x2f <c02b1384> ipt_do_table+0x68/0x294
<c02b1e37> ipt_hook+0x1b/0x20 <c0279606> nf_iterate+0x26/0x5a
<c02798ab> nf_hook_slow+0x41/0xba <c0282888> ip_push_pending_frames+0x2e2/0x3a9
<c029d39d> icmp_push_reply+0xc2/0xcd <c029dc8b> icmp_send+0x2d3/0x332
<c02b371c> reject+0x49/0x551 <c02b155d> ipt_do_table+0x241/0x294
<c02b162b> ipt_hook+0x1b/0x20 <c0279606> nf_iterate+0x26/0x5a
<c02798ab> nf_hook_slow+0x41/0xba <c0280482> ip_local_deliver+0x58/0x1e6
<c02803fd> ip_rcv+0x3d5/0x402 <c026bc9b> netif_receive_skb+0x13d/0x1a4
<c026d552> process_backlog+0x7c/0x112 <c026d35c> net_rx_action+0x5b/0xed
<c01188ca> __do_softirq+0x45/0x9f <c0104428> do_softirq+0x45/0xa4
=======================
<c0118954> irq_exit+0x30/0x3c <c01044f7> do_IRQ+0x70/0x7d
<c0102b45> common_interrupt+0x25/0x2c
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
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/
^ permalink raw reply
* RE: kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1
From: Guenther Thomsen @ 2006-06-04 4:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: John W. Linville, netdev
I received the hardware back and took the opportunity to test with 2.6.17-rc5-git11. So far I did only little tests (ttcp on both interfaces in, out or mixed with some 10e6 packets), but it looks good. No errors (well, 16 overruns in 76574513 packets) and line rate (about 111MB/s) on both channels simultaneously. Hurray!
Thanks a lot for you continued efforts.
Guenther
-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@osdl.org]
Sent: Tuesday, May 16, 2006 12:12 PM
To: Guenther Thomsen
Cc: John W. Linville; netdev@vger.kernel.org
Subject: Re: kernel panic (on DHCP discover?) in sky2 driver of
2.6.17-rc1
Could you try the 2.6.17-rc4 version with this patch. It turns out the board
seems to give out of order status responses.
Ignore the vendor sk98lin driver, when I try the stock version it spends it's
life resetting itself because it sets up PCI bus wrong. If I fix that, it spends
it's time getting confused because it can't handle intermixed status reports
properly (checksum et all is per port not per board).
drivers/net/sky2.c | 28 +++++++++++++++++++++-------
1 files changed, 21 insertions(+), 7 deletions(-)
792547bc5e8e4f7d5a1070a168056f429635c254
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index ffd267f..11e7914 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1020,8 +1020,27 @@ static int sky2_up(struct net_device *de
struct sky2_hw *hw = sky2->hw;
unsigned port = sky2->port;
u32 ramsize, rxspace, imask;
- int err = -ENOMEM;
+ int cap, err;
+ struct net_device *otherdev = hw->dev[sky2->port^1];
+ /*
+ * Reduce split transactions (and turn off) rx checksums to
+ * prevent problems with dual ports.
+ */
+ if (otherdev && netif_running(otherdev) &&
+ (cap = pci_find_capability(hw->pdev, PCI_CAP_ID_PCIX))) {
+ struct sky2_port *osky2 = netdev_priv(otherdev);
+ u16 cmd;
+
+ cmd = sky2_pci_read16(hw, cap + PCI_X_CMD);
+ cmd &= ~PCI_X_CMD_MAX_SPLIT;
+ sky2_pci_write16(hw, cap + PCI_X_CMD, cmd);
+
+ sky2->rx_csum = 0;
+ osky2->rx_csum = 0;
+ }
+
+ err = -ENOMEM;
if (netif_msg_ifup(sky2))
printk(KERN_INFO PFX "%s: enabling interface\n", dev->name);
@@ -3067,12 +3086,7 @@ static __devinit struct net_device *sky2
sky2->duplex = -1;
sky2->speed = -1;
sky2->advertising = sky2_supported_modes(hw);
-
- /* Receive checksum disabled for Yukon XL
- * because of observed problems with incorrect
- * values when multiple packets are received in one interrupt
- */
- sky2->rx_csum = (hw->chip_id != CHIP_ID_YUKON_XL);
+ sky2->rx_csum = 1;
spin_lock_init(&sky2->phy_lock);
sky2->tx_pending = TX_DEF_PENDING;
--
1.2.4
^ permalink raw reply related
* [PATCH] bcm43xx: add DMA rx poll workaround to DMA4
From: Michael Buesch @ 2006-06-04 0:20 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, bcm43xx-dev
This is a bugfix and 2.6.17 stuff, if still possible to push upstream.
--
Also add the Poll RX DMA Memory workaround to the DMA4
(xmitstatus) path.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index bbecba0..d0318e5 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -624,25 +624,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x0000;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
- * in the lower 12 bits
+ * in the lower 12 bits.
+ * Note that the cookie must never be 0, as this
+ * is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x0000);
@@ -660,16 +663,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x0000:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma->tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma->tx_ring3;
break;
default:
@@ -839,8 +842,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb->data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw->cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i >= 10000)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw->cookie);
+ }
stat.flags = hw->flags;
stat.cnt1 = hw->cnt1;
stat.cnt2 = hw->cnt2;
--
Greetings Michael.
^ permalink raw reply related
* [PATCH] ipx: endian bug in ipxrtr_route_packet()
From: Alexey Dobriyan @ 2006-06-03 23:36 UTC (permalink / raw)
To: netdev; +Cc: Arnaldo Carvalho de Melo
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
Also, there is the following snippet in net/ipx/af_ipx.c, line 1174
f.ipx_special = sipx->sipx_special;
The former is unsigned char and is compared with 1 and 2. The latter is
__be16 if I'm not mistaken. Is there a bug hiding?
--- a/net/ipx/ipx_route.c
+++ b/net/ipx/ipx_route.c
@@ -238,7 +237,7 @@ int ipxrtr_route_packet(struct sock *sk,
}
/* Apply checksum. Not allowed on 802.3 links. */
- if (sk->sk_no_check || intrfc->if_dlink_type == IPX_FRAME_8023)
+ if (sk->sk_no_check || intrfc->if_dlink_type == htons(IPX_FRAME_8023))
ipx->ipx_checksum = 0xFFFF;
else
ipx->ipx_checksum = ipx_cksum(ipx, len + sizeof(struct ipxhdr));
^ permalink raw reply
* Re: [RFC ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
From: Michael Buesch @ 2006-06-03 23:12 UTC (permalink / raw)
To: Larry Finger; +Cc: John Linville, netdev
In-Reply-To: <448210EF.10103@lwfinger.net>
On Sunday 04 June 2006 00:45, Larry Finger wrote:
> b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for
> communication with the daemon. The first, which is read by the daemon, contains the country and
> outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data
> corresponding to the country and indoor/outdoor information passed from the kernel.
Use sysfs, please.
--
Greetings Michael.
^ permalink raw reply
* [RFC ] [4 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - Patches for bcm43xx to use new ieee80211 routine
From: Larry Finger @ 2006-06-03 22:46 UTC (permalink / raw)
To: netdev, John Linville
This message shows the patch needed to convert the bcm43xx driver to use the new ieee80211_init_geo
routine. Note: I know my mailer has butchered the white space by changing all the tabs into spaces.
The original source is OK. Larry
===================================================================================================
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c \
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index 7ed18ca..eb88a4e 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -87,9 +87,15 @@ static int modparam_long_retry = BCM43xx
module_param_named(long_retry, modparam_long_retry, int, 0444);
MODULE_PARM_DESC(long_retry, "Long-Retry-Limit (0 - 15)");
-static int modparam_locale = -1;
-module_param_named(locale, modparam_locale, int, 0444);
-MODULE_PARM_DESC(country, "Select LocaleCode 0-11 (For travelers)");
+static char modparam_locale[] = " ";
+static char country[3];
+
+module_param_string(country, modparam_locale, 3, 0444);
+MODULE_PARM_DESC(country, "Two character ISO Country Name (For Travelers)");
+
+static int modparam_outdoor;
+module_param_named(outdoor, modparam_outdoor, int, 0444);
+MODULE_PARM_DESC(outdoor, "Set to 1 if interface to be used outdoors");
static int modparam_noleds;
module_param_named(noleds, modparam_noleds, int, 0444);
@@ -621,38 +627,6 @@ static const char * bcm43xx_locale_iso(u
return " ";
}
-static const char * bcm43xx_locale_string(u8 locale)
-{
- switch (locale) {
- case BCM43xx_LOCALE_WORLD:
- return "World";
- case BCM43xx_LOCALE_THAILAND:
- return "Thailand";
- case BCM43xx_LOCALE_ISRAEL:
- return "Israel";
- case BCM43xx_LOCALE_JORDAN:
- return "Jordan";
- case BCM43xx_LOCALE_CHINA:
- return "China";
- case BCM43xx_LOCALE_JAPAN:
- return "Japan";
- case BCM43xx_LOCALE_USA_CANADA_ANZ:
- return "USA/Canada/ANZ";
- case BCM43xx_LOCALE_EUROPE:
- return "Europe";
- case BCM43xx_LOCALE_USA_LOW:
- return "USAlow";
- case BCM43xx_LOCALE_JAPAN_HIGH:
- return "JapanHigh";
- case BCM43xx_LOCALE_ALL:
- return "All";
- case BCM43xx_LOCALE_NONE:
- return "None";
- }
- assert(0);
- return "";
-}
-
static inline u8 bcm43xx_crc8(u8 crc, u8 data)
{
static const u8 t[] = {
@@ -860,17 +834,12 @@ #endif
bcm->sprom.locale = (value & 0x0F00) >> 8;
bcm->sprom.antennas_aphy = (value & 0x3000) >> 12;
bcm->sprom.antennas_bgphy = (value & 0xC000) >> 14;
- if (modparam_locale != -1) {
- if (modparam_locale >= 0 && modparam_locale <= 11) {
- bcm->sprom.locale = modparam_locale;
- printk(KERN_WARNING PFX "Operating with modified "
- "LocaleCode %u (%s)\n",
- bcm->sprom.locale,
- bcm43xx_locale_string(bcm->sprom.locale));
- } else {
- printk(KERN_WARNING PFX "Module parameter \"locale\" "
- "invalid value. (0 - 11)\n");
- }
+ if (strcmp(modparam_locale, " ")) {
+ printk(KERN_WARNING PFX "Operating with modified Country "
+ "Code %s\n", modparam_locale);
+ strcpy(country, modparam_locale);
+ } else {
+ strcpy(country, bcm43xx_locale_iso(bcm->sprom.locale));
}
/* pa0b* */
@@ -939,69 +908,6 @@ #endif
return 0;
}
-static int bcm43xx_geo_init(struct bcm43xx_private *bcm)
-{
- struct ieee80211_geo *geo;
- struct ieee80211_channel *chan;
- int have_a = 0, have_bg = 0;
- int i;
- u8 channel;
- struct bcm43xx_phyinfo *phy;
- const char *iso_country;
-
- geo = kzalloc(sizeof(*geo), GFP_KERNEL);
- if (!geo)
- return -ENOMEM;
-
- for (i = 0; i < bcm->nr_80211_available; i++) {
- phy = &(bcm->core_80211_ext[i].phy);
- switch (phy->type) {
- case BCM43xx_PHYTYPE_B:
- case BCM43xx_PHYTYPE_G:
- have_bg = 1;
- break;
- case BCM43xx_PHYTYPE_A:
- have_a = 1;
- break;
- default:
- assert(0);
- }
- }
- iso_country = bcm43xx_locale_iso(bcm->sprom.locale);
-
- if (have_a) {
- for (i = 0, channel = IEEE80211_52GHZ_MIN_CHANNEL;
- channel <= IEEE80211_52GHZ_MAX_CHANNEL; channel++) {
- chan = &geo->a[i++];
- chan->freq = bcm43xx_channel_to_freq_a(channel);
- chan->channel = channel;
- }
- geo->a_channels = i;
- }
- if (have_bg) {
- for (i = 0, channel = IEEE80211_24GHZ_MIN_CHANNEL;
- channel <= IEEE80211_24GHZ_MAX_CHANNEL; channel++) {
- chan = &geo->bg[i++];
- chan->freq = bcm43xx_channel_to_freq_bg(channel);
- chan->channel = channel;
- }
- geo->bg_channels = i;
- }
- memcpy(geo->name, iso_country, 2);
- if (0 /*TODO: Outdoor use only */)
- geo->name[2] = 'O';
- else if (0 /*TODO: Indoor use only */)
- geo->name[2] = 'I';
- else
- geo->name[2] = ' ';
- geo->name[3] = '\0';
-
- ieee80211_set_geo(bcm->ieee, geo);
- kfree(geo);
-
- return 0;
-}
-
/* DummyTransmission function, as documented on
* http://bcm-specs.sipsolutions.net/DummyTransmission
*/
@@ -3486,13 +3392,15 @@ static int bcm43xx_attach_board(struct b
bcm43xx_radio_turn_off(bcm);
err = bcm43xx_phy_init_tssi2dbm_table(bcm);
+ bcm43xx_wireless_core_disable(bcm);
if (err)
goto err_80211_unwind;
- bcm43xx_wireless_core_disable(bcm);
}
- err = bcm43xx_geo_init(bcm);
+ printk(KERN_INFO PFX "Country Code = %s, Outdoor code = %d\n", country, modparam_outdoor);
+ err = ieee80211_init_geo(bcm->ieee, country, modparam_outdoor);
if (err)
goto err_80211_unwind;
+
bcm43xx_pctl_set_crystal(bcm, 0);
/* Set the MAC address in the networking subsystem */
^ permalink raw reply related
* [RFC ] [3 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - Patches for ieee80211
From: Larry Finger @ 2006-06-03 22:45 UTC (permalink / raw)
To: netdev, John Linville
This message contains the patch to add routine ieee80211_init_geo to the kernel, and a new flag
definition for the IEEE80211 codes. Note: I know that my mailer has messed up the white space by
converting all the tabs to spaces. The original files are OK. Larry
=====================================================================================
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
index d5926bf..8a5dc0f 100644
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -965,6 +965,7 @@ #define IEEE80211_52GHZ_CHANNELS (IEEE80
enum {
IEEE80211_CH_PASSIVE_ONLY = (1 << 0),
+ IEEE80211_CH_80211H_RULES = (1 << 1),
IEEE80211_CH_B_ONLY = (1 << 2),
IEEE80211_CH_NO_IBSS = (1 << 3),
IEEE80211_CH_UNIFORM_SPREADING = (1 << 4),
@@ -973,10 +974,10 @@ enum {
};
struct ieee80211_channel {
- u32 freq;
+ u32 freq; /* in MHz */
u8 channel;
u8 flags;
- u8 max_power;
+ u8 max_power; /* in dBm */
};
struct ieee80211_geo {
@@ -1260,6 +1261,9 @@ extern const struct ieee80211_geo *ieee8
extern int ieee80211_set_geo(struct ieee80211_device *ieee,
const struct ieee80211_geo *geo);
+extern int ieee80211_init_geo(struct ieee80211_device *ieee,
+ char * country, u8 outdoor);
+
extern int ieee80211_is_valid_channel(struct ieee80211_device *ieee,
u8 channel);
extern int ieee80211_channel_to_index(struct ieee80211_device *ieee,
diff --git a/net/ieee80211/ieee80211_geo.c b/net/ieee80211/ieee80211_geo.c
index 192243a..2e4806b 100644
--- a/net/ieee80211/ieee80211_geo.c
+++ b/net/ieee80211/ieee80211_geo.c
@@ -41,6 +41,7 @@ #include <linux/types.h>
#include <linux/wireless.h>
#include <linux/etherdevice.h>
#include <asm/uaccess.h>
+#include <linux/delay.h>
#include <net/ieee80211.h>
@@ -133,6 +134,136 @@ int ieee80211_set_geo(struct ieee80211_d
return 0;
}
+static char ieee80211_country[10];
+static uint ieee80211_outdoor;
+static struct proc_dir_entry *ieee80211_geo_proc;
+static uint ieee80211_data_back;
+struct ieee80211_geo *geo;
+static uint bytes_xfer;
+
+static int show_geo_country(char *page, char **start, off_t offset,
+ int count, int *eof, void *data)
+{
+ return snprintf(page, count, "%s %d\n", ieee80211_country, ieee80211_outdoor);
+}
+
+static int store_geo_data(struct file *file, const char __user * buffer,
+ unsigned long count, void *data)
+{
+ unsigned long len = min((unsigned long)sizeof(struct ieee80211_geo) , count);
+ int i;
+
+ if (copy_from_user((geo + bytes_xfer), buffer, len)) {
+ IEEE80211_ERROR( "Error return from copy_from_user.\n");
+ return -EFAULT;
+ }
+ bytes_xfer += len;
+ if (bytes_xfer == sizeof(struct ieee80211_geo)) {
+ IEEE80211_DEBUG_INFO( "All data has been received.\n");
+ if (!geo->bg_channels && !geo->a_channels) { /* if no channels specified - error */
+ IEEE80211_DEBUG_INFO( "No bg or a/h channels specified.\n");
+ return count;
+ }
+ if (geo->bg_channels > IEEE80211_24GHZ_CHANNELS) { /* too many bg channels */
+ IEEE80211_DEBUG_INFO( "Too many bg channels specified.\n");
+ return count;
+ }
+ if (geo->a_channels > IEEE80211_52GHZ_CHANNELS) { /* too many a channels */
+ IEEE80211_DEBUG_INFO( "Too many a/h channels specified.\n");
+ return count;
+ }
+ for (i=0; i<geo->a_channels; i++) {
+ if (geo->a[i].channel < IEEE80211_52GHZ_MIN_CHANNEL ||
+ geo->a[i].channel > IEEE80211_52GHZ_MAX_CHANNEL)
+ return count; /* here if channel out of range */
+ }
+ for (i=0; i<geo->bg_channels; i++) {
+ if (geo->bg[i].channel < IEEE80211_24GHZ_MIN_CHANNEL ||
+ geo->bg[i].channel > IEEE80211_24GHZ_MAX_CHANNEL)
+ return count; /* here if channel out of range */
+ }
+ IEEE80211_DEBUG_INFO( "Data passed sanity checks.\n"); /* data seems to be correct */
+ ieee80211_data_back = 0;
+ }
+ return count;
+}
+
+int ieee80211_init_geo(struct ieee80211_device *ieee,
+ char *country, u8 outdoor)
+{
+ int ret;
+ struct proc_dir_entry *e1, *e2;
+
+ static const struct ieee80211_geo ieee80211_geos[] = {
+ { /* Default parameters to be returned if daemon not running or other error */
+ "---",
+ .a_channels = 0,
+ .bg_channels = 11,
+ .bg = {{.freq = 2412, .channel = 1, .max_power = 20},
+ {.freq = 2417, .channel = 2, .max_power = 20},
+ {.freq = 2422, .channel = 3, .max_power = 20},
+ {.freq = 2427, .channel = 4, .max_power = 20},
+ {.freq = 2432, .channel = 5, .max_power = 20},
+ {.freq = 2437, .channel = 6, .max_power = 20},
+ {.freq = 2442, .channel = 7, .max_power = 20},
+ {.freq = 2447, .channel = 8, .max_power = 20},
+ {.freq = 2452, .channel = 9, .max_power = 20},
+ {.freq = 2457, .channel = 10, .max_power = 20},
+ {.freq = 2462, .channel = 11, .max_power = 20}
+ },
+ },
+ };
+
+ IEEE80211_DEBUG_INFO( "Country Code: %s, Outdoor: %d\n", country, outdoor);
+ memcpy(ieee80211_country, country, strlen(country));
+ ieee80211_outdoor = outdoor;
+ ieee80211_geo_proc = proc_mkdir("ieee80211_geo", proc_net);
+ (void)ieee80211_set_geo( ieee, ieee80211_geos); /* load default data in case of error */
+ if (ieee80211_geo_proc == NULL) {
+ IEEE80211_ERROR( "Unable to create ieee80211_geo"
+ " proc directory - default geo data loaded\n");
+ return -EIO;
+ }
+ geo = kzalloc(sizeof(struct ieee80211_geo), GFP_KERNEL);
+ if (!geo) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
+ e1 = create_proc_entry("geo_country", S_IFREG | S_IRUSR | S_IWUSR,
+ ieee80211_geo_proc);
+ e1->read_proc = show_geo_country;
+ e2 = create_proc_entry("geo_data", S_IWUSR | S_IWGRP | S_IWOTH,
+ ieee80211_geo_proc);
+ ieee80211_data_back = 1;
+ bytes_xfer = 0;
+ e2->write_proc = store_geo_data;
+
+ if (!e1 || !e2 ) {
+ IEEE80211_ERROR( "Unable to create files in ieee80211_geo"
+ " - default data loaded.\n");
+ ret = -EIO;
+ goto free_geo;
+ }
+ for (ret=0; ret<1000; ret++) {
+ if (!ieee80211_data_back)
+ break;
+ udelay(1000);
+ }
+ if (ret == 1000) {
+ ret = -EIO;
+ IEEE80211_DEBUG_INFO( "ieee80211_geo daemon not running - default data loaded.\n");
+ goto free_geo; /* daemon not running */
+ }
+ ret = ieee80211_set_geo( ieee, geo);
+free_geo:
+ kfree(geo);
+cleanup:
+ remove_proc_entry("geo_country", ieee80211_geo_proc);
+ remove_proc_entry("geo_data", ieee80211_geo_proc);
+ remove_proc_entry("ieee80211_geo", proc_net);
+ return ret;
+}
+
const struct ieee80211_geo *ieee80211_get_geo(struct ieee80211_device *ieee)
{
return &ieee->geo;
@@ -177,4 +308,5 @@ EXPORT_SYMBOL(ieee80211_is_valid_channel
EXPORT_SYMBOL(ieee80211_freq_to_channel);
EXPORT_SYMBOL(ieee80211_channel_to_index);
EXPORT_SYMBOL(ieee80211_set_geo);
+EXPORT_SYMBOL(ieee80211_init_geo);
EXPORT_SYMBOL(ieee80211_get_geo);
^ permalink raw reply related
* [RFC ] [2 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - database
From: Larry Finger @ 2006-06-03 22:45 UTC (permalink / raw)
To: netdev, John Linville
This message shows each of the 2.4 GHz and 5 GHz bands split into indoor and outdoor usage. For each
group, the ISO name for that country is shown before the channel listing. There are a lot of
countries that do not belong in the default group. I welcome any input you can provide for these
missing countries, and any other incorrect information. Note: The country code EU is a pseudonym for
the entire European Union.
Thanks, Larry
=============================================================================================
IEEE80211 Regulatory/Geographical Daemon (V0.1)
Using Database Version of 26 May 2006
=================================================
Countries in 2.4 GHz group 0
AF, AL, DZ, AS, AD, AO, AI, AG, AM, AW, AZ, BS, BH, BD, BB, BY, BZ, BJ, BM, BT
BO, BA, BW, BV, IO, VG, BN, BF, BI, KH, CM, CV, KY, CF, TD, CX, CC, KM, CD, CG
CK, CI, DJ, DM, DO, TL, EG, SV, GQ, ER, ET, FO, FK, FJ, PF, TF, GA, GM, GE, GH
GI, GL, GD, GP, GU, GT, GN, GW, GY, HT, HM, HN, IS, ID, IR, IQ, IL, JO, KZ, KE
KI, KP, KW, KG, LA, LB, LS, LR, LY, MO, MG, MW, MY, MV, ML, MH, MQ, MR, MU, YT
FM, MD, MC, MN, MS, MA, MZ, MM, NA, NR, NP, AN, NC, NZ, NI, NE, NG, NU, NF, MP
NO, OM, PK, PW, PS, PA, PG, PH, PN, PR, QA, RW, SH, KN, LC, PM, VC, WS, SM, ST
SA, SN, CS, SC, SL, SG, SB, SO, ZA, GS, LK, SD, SR, SJ, SZ, CH, SY, TW, TJ, TZ
TH, TG, TK, TO, TT, TN, TM, TC, TV, VI, UG, UA, AE, UM, UY, UZ, VU, VE, VN, WF
EH, YE, ZM, ZW
Indoor Group 0 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
Outdoor Group 0 has no channels in 2.4 GHz band
=================================================
Countries in 2.4 GHz group 1
AT, BE, BG, HR, CY, CZ, DK, EE, EU, FI, DE, GR, VA, HU, IN, IE, IT, LV, LI, LT
LU, MK, MT, NL, PL, PT, RO, SK, SI, ES, SE, TR, GB
Indoor Group 1 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 1 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
=================================================
Countries in 2.4 GHz group 2
AU
Indoor Group 2 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
Outdoor Group 2 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
=================================================
Countries in 2.4 GHz group 3
FR
Indoor Group 3 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 3 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 10
10 2457 10
11 2462 10
12 2467 10
13 2472 10
=================================================
Countries in 2.4 GHz group 4
CN
Indoor Group 4 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 27
2 2417 27
3 2422 27
4 2427 27
5 2432 27
6 2437 27
7 2442 27
8 2447 27
9 2452 27
10 2457 27
11 2462 27
12 2467 27
13 2472 27
Outdoor Group 4 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 27
2 2417 27
3 2422 27
4 2427 27
5 2432 27
6 2437 27
7 2442 27
8 2447 27
9 2452 27
10 2457 27
11 2462 27
12 2467 27
13 2472 27
=================================================
Countries in 2.4 GHz group 5
HK, US
Indoor Group 5 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
Outdoor Group 5 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
=================================================
Countries in 2.4 GHz group 6
CL, CO, CR, CU, EC, JM, MX, PY, PE, RU
Indoor Group 6 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 6 has no channels in 2.4 GHz band
=================================================
Countries in 2.4 GHz group 7
BR, CA
Indoor Group 7 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 30
2 2417 30
3 2422 30
4 2427 30
5 2432 30
6 2437 30
7 2442 30
8 2447 30
9 2452 30
10 2457 30
11 2462 30
Outdoor Group 7 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 30
2 2417 30
3 2422 30
4 2427 30
5 2432 30
6 2437 30
7 2442 30
8 2447 30
9 2452 30
10 2457 30
11 2462 30
=================================================
Countries in 2.4 GHz group 8
GF, RE
Indoor Group 8 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 8 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 10
10 2457 10
11 2462 10
12 2467 10
13 2472 10
=================================================
Countries in 2.4 GHz group 9
AR
Indoor Group 9 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 36
2 2417 36
3 2422 36
4 2427 36
5 2432 36
6 2437 36
7 2442 36
8 2447 36
9 2452 36
10 2457 36
11 2462 36
12 2467 36
13 2472 36
Outdoor Group 9 has no channels in 2.4 GHz band
=================================================
Countries in 2.4 GHz group 10
JP
Indoor Group 10 with 14 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
12 2467 23
13 2472 23
14 2484 23 B_ONLY
Outdoor Group 10 with 14 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
12 2467 23
13 2472 23
14 2484 23 B_ONLY
=================================================
Countries in 2.4 GHz group 11
KR
Indoor Group 11 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 28
2 2417 28
3 2422 28
4 2427 28
5 2432 28
6 2437 28
7 2442 28
8 2447 28
9 2452 28
10 2457 28
11 2462 28
12 2467 28
13 2472 28
Outdoor Group 11 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 28
2 2417 28
3 2422 28
4 2427 28
5 2432 28
6 2437 28
7 2442 28
8 2447 28
9 2452 28
10 2457 28
11 2462 28
12 2467 28
13 2472 28
=================================================
Countries in 5 GHz group 0
AF, AL, DZ, AS, AD, AO, AI, AG, AM, AW, AZ, BS, BH, BD, BB, BY, BZ, BJ, BM, BT
BO, BA, BW, BV, IO, VG, BN, BG, BF, BI, KH, CM, CV, KY, CF, TD, CX, CC, KM, CD
CG, CK, CR, CI, DJ, DM, DO, TL, EC, EG, SV, GQ, ER, ET, FO, FK, FJ, PF, TF, GA
GM, GE, GH, GI, GL, GD, GP, GU, GT, GN, GW, GY, HT, HM, HN, IS, ID, IR, IQ, IL
JO, KZ, KE, KI, KP, KW, KG, LA, LB, LS, LR, LY, LI, MO, MG, MW, MY, MV, ML, MH
MQ, MR, MU, YT, FM, MD, MC, MN, MS, MA, MZ, MM, NA, NR, NP, AN, NC, NZ, NI, NE
NG, NU, NF, MP, NO, OM, PK, PW, PS, PA, PG, PY, PH, PN, PT, PR, QA, RO, RU, RW
SH, KN, LC, PM, VC, WS, SM, ST, SN, CS, SC, SL, SG, SK, SB, SO, ZA, GS, ES, LK
SD, SR, SJ, SZ, CH, SY, TW, TJ, TZ, TH, TG, TK, TO, TT, TN, TM, TC, TV, VI, UG
UA, AE, UM, UY, UZ, VU, VE, VN, WF, EH, YE, ZM, ZW
Indoor Group 0 has no channels in 5 GHz band
Outdoor Group 0 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 1
AT, HR, CY, CZ, DK, EE, EU, FI, FR, GF, DE, VA, HU, IE, IT, LV, LT, LU, MK, MT
NL, PL, RE, SI, SE, GB
Indoor Group 1 with 18 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23 PASSIVE H_RULES
40 5200 23 PASSIVE H_RULES
44 5220 23 PASSIVE H_RULES
48 5240 23 PASSIVE H_RULES
52 5260 23 PASSIVE H_RULES
56 5280 23 PASSIVE H_RULES
60 5300 23 PASSIVE H_RULES
64 5320 23 PASSIVE H_RULES
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
Outdoor Group 1 with 10 channels in 5 GHz bands
Chn Freq Power Flags
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
=================================================
Countries in 5 GHz group 2
AU
Indoor Group 2 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
149 5745 30
153 5765 30
157 5785 30
161 5805 30
Outdoor Group 2 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 30
153 5765 30
157 5785 30
161 5805 30
=================================================
Countries in 5 GHz group 3
SA
Indoor Group 3 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
149 5745 23
153 5765 23
157 5785 23
161 5805 23
Outdoor Group 3 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 4
CN
Indoor Group 4 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 27
153 5765 27
157 5785 27
161 5805 27
Outdoor Group 4 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 27
153 5765 27
157 5785 27
161 5805 27
=================================================
Countries in 5 GHz group 5
HK
Indoor Group 5 with 8 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
Outdoor Group 5 with 8 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
=================================================
Countries in 5 GHz group 6
GR, TR
Indoor Group 6 with 8 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23 PASSIVE H_RULES
40 5200 23 PASSIVE H_RULES
44 5220 23 PASSIVE H_RULES
48 5240 23 PASSIVE H_RULES
52 5260 23 PASSIVE H_RULES
56 5280 23 PASSIVE H_RULES
60 5300 23 PASSIVE H_RULES
64 5320 23 PASSIVE H_RULES
Outdoor Group 6 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 7
BR, CA
Indoor Group 7 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 30
56 5280 30
60 5300 30
64 5320 30
149 5745 30
153 5765 30
157 5785 30
161 5805 30
Outdoor Group 7 with 8 channels in 5 GHz bands
Chn Freq Power Flags
52 5260 30
56 5280 30
60 5300 30
64 5320 30
149 5745 30
153 5765 30
157 5785 30
161 5805 30
=================================================
Countries in 5 GHz group 8
JM, PE
Indoor Group 8 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 20
153 5765 20
157 5785 20
161 5805 20
Outdoor Group 8 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 9
BE
Indoor Group 9 with 11 channels in 5 GHz bands
Chn Freq Power Flags
100 5500 30 PASSIVE H_RULES
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
Outdoor Group 9 with 11 channels in 5 GHz bands
Chn Freq Power Flags
100 5500 30 PASSIVE H_RULES
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
=================================================
Countries in 5 GHz group 10
IN
Indoor Group 10 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 20
40 5200 20
44 5220 20
48 5240 20
52 5260 20
56 5280 20
60 5300 20
64 5320 20
149 5745 20
153 5765 20
157 5785 20
161 5805 20
Outdoor Group 10 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 11
US
Indoor Group 11 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 30 PASSIVE H_RULES
56 5280 30 PASSIVE H_RULES
60 5300 30 PASSIVE H_RULES
64 5320 30 PASSIVE H_RULES
149 5745 36
153 5765 36
157 5785 36
161 5805 36
Outdoor Group 11 with 8 channels in 5 GHz bands
Chn Freq Power Flags
52 5260 30 PASSIVE H_RULES
56 5280 30 PASSIVE H_RULES
60 5300 30 PASSIVE H_RULES
64 5320 30 PASSIVE H_RULES
149 5745 36
153 5765 36
157 5785 36
161 5805 36
=================================================
Countries in 5 GHz group 12
AR
Indoor Group 12 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 36
153 5765 36
157 5785 36
161 5805 36
Outdoor Group 12 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 13
CL, CO, CU
Indoor Group 13 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 30
153 5765 30
157 5785 30
161 5805 30
Outdoor Group 13 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 14
MX
Indoor Group 14 with 22 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 20
40 5200 20
44 5220 20
48 5240 20
52 5260 20
56 5280 20
60 5300 20
64 5320 20
104 5520 20
108 5540 20
112 5560 20
116 5580 20
120 5600 20
124 5620 20
128 5640 20
132 5660 20
136 5680 20
140 5700 20
149 5745 20
153 5765 20
157 5785 20
161 5805 20
Outdoor Group 14 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 15
JP
Indoor Group 15 with 4 channels in 5 GHz bands
Chn Freq Power Flags
34 5170 23
38 5190 23
42 5210 23
46 5230 23
Outdoor Group 15 with 4 channels in 5 GHz bands
Chn Freq Power Flags
34 5170 23
38 5190 23
42 5210 23
46 5230 23
=================================================
Countries in 5 GHz group 16
KR
Indoor Group 16 with 19 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 28
40 5200 28
44 5220 28
48 5240 28
52 5260 28
56 5280 28
60 5300 28
64 5320 28
100 5500 28
104 5520 28
108 5540 28
112 5560 28
116 5580 28
120 5600 28
124 5620 28
149 5745 28
153 5765 28
157 5785 28
161 5805 28
Outdoor Group 16 with 15 channels in 5 GHz bands
Chn Freq Power Flags
52 5260 28
56 5280 28
60 5300 28
64 5320 28
100 5500 28
104 5520 28
108 5540 28
112 5560 28
116 5580 28
120 5600 28
124 5620 28
149 5745 28
153 5765 28
157 5785 28
161 5805 28
Database contains 239 countries, 12 groups in the 2.4 GHz band,
and 17 groups in the 5 GHz bands.
^ permalink raw reply
* [RFC ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
From: Larry Finger @ 2006-06-03 22:45 UTC (permalink / raw)
To: netdev, John Linville
As announced earlier in this list, I am working on providing kernel support for providing regulatory
information to be used to set usable channels, max power, and other information needed by IEEE802.11
drivers. The database will be maintained as a text file processed by a user-space daemon. I now have
the complete system running on my machine. The full database and the user space daemon are available
through a subversion repository at svn://lwfinger.dynalias.org/ide1/ieee80211_geo.
The details of the implementation are as follows:
1. A new routine, ieee80211_init_geo has been written that is called by a driver wishing to use this
functionality. The arguments are an ieee80211_device, a two-character ISO3661 country code, and a
flag that is true if the device is to be used outdoors. This new routine does the following:
a) It establishes a default set of wireless parameters that will be supplied to the driver if the
user space daemon is not running, if the daemon does not respond in a timely fashion, or if the
daemon supplies data that do not pass rudimentary validity checks. The default data includes b/g
channels 1 - 11 for indoor usage at a maximum power of 20 dBm (100 mW). At present, no 5 GHz
channels are defined in the default set. This set of parameters should be legal everywhere.
b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for
communication with the daemon. The first, which is read by the daemon, contains the country and
outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data
corresponding to the country and indoor/outdoor information passed from the kernel.
c) It next spin loops for up to 1 second waiting for the user space daemon to respond. As noted
earlier, if this loop times out, the default set is supplied.
d) It then calls ieee80211_set_geo to load the channel data into the appropriate place in the
ieee80211_device block, and returns the status to the driver.
2. The user-space daemon, which need not be run as root, does the following:
a) It verifies that the text file containing the regulatory information is intact by assuming
that the last line of the file contains the md5 sum for all of the file except for this last line.
The scheme is certainly not tamper proof, but it ensures that whomever has modified the file has
some technical skills. If the checksum is not correct, the program generates an appropriate error
message and exits.
b) It then process the country information consisting of a number pointing to an entry describing
the 2.4 GHz band information, a second number pointing to the description of the 5 GHz bands, and a
two-character country code.
c) It then reads the groups that describe the allowed channels for the 2.4 GHz band and similar
information for the 5 GHz bands and builds the tables in the form needed by the ieee80211_geo
structure. Each input line consists of (a)the band identification characters "b", "bg", "a", or "h",
(b) a channel range consisting of the starting and ending channels, (c) the number of channels
between each stop (normally 1 for b/g and 4 for a), (d) the maximum eirp power for this channel in
dBm, and (e) a set of flags for these channels. Flags currently implemented are for 802.11b only,
for passive scanning, or for 802.11h rules. These data are checked to confirm that every group
mentioned in the country section is indeed present, that the channels listed are appropriate for
that band, and that there are no duplicate channels in any group. If there are any difficulties with
the data the daemon aborts.
d) It then daemonizes, unless the -F command-line switch was supplied.
e) It then spins waiting for the existence of file '/proc/net/ieee80211_geo/country', which is
the indication that the kernel is requesting data.
f) It then reads the country and outdoor flag, finds the appropriate entries in its internal
tables and writes the data back through the pseudo-file.in /proc. If the country code is unknown, a
default dataset is supplied. The program then loops back to step e) and waits for the next driver load.
A segment of the country section of the data file is as follows (data are 2.4 GHz group, 5 GHz group
ISO country name and English country name):
0 0 AO Angola, Republic of
0 0 AI Anguilla
0 0 AG Antigua and Barbuda
9 12 AR Argentina, Argentine Republic
0 0 AM Armenia
0 0 AW Aruba
2 2 AU Australia, Commonwealth of
1 1 AT Austria, Republic of
0 0 AZ Azerbaijan, Republic of
A couple of representative groups from the 2.4 GHz band are:
# Band Ch_Range Ch_Spacing Power Flags
#
bgGroup: 0 - Unspecified Country
# - Saudi Arabia (http://www.citc.sa)
#
bg 1 - 11 1 20 I
#
bgGroup: 1 - General European Union (EU)
# - India (Cetecom June 2 2005)
#
bg 1 - 13 1 20 B
#
Similarly, a couple of 5 GHz groups are:
aGroup: 0 - Unspecified (or unknown details for) Country
# - Bulgaria, Liechtenstein, Portugal, Romania, Slovakia, Spain
#
#
aGroup: 1 - General European Union (EU)
# - French Guiana and Reunion
#
h 36 - 48 4 23 I
h 52 - 64 4 23 IP
h 104 - 140 4 30 BP
I welcome your comments. Part 2 will show a debug dump of the converted database, Part 3 will
present the patch needed to add the new routine to the ieee80211 routines, and Part 4 will show the
patches needed to modify the bcm43xx driver to use the new routine..
Larry
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-03 22:25 UTC (permalink / raw)
To: Daniel Drake; +Cc: linux-usb-devel, John W. Linville, netdev, Ulrich Kunitz
In-Reply-To: <4481E497.2000505@gentoo.org>
Am Samstag, 3. Juni 2006 21:35 schrieb Daniel Drake:
> Oliver Neukum wrote:
> > +static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
> > +{
> > + static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
> > + return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
> > +}
> >
> > Why on the stack?
>
> Technically it's not on the stack because it is static const (it goes in
> rodata), but I don't think that this invalidates your point. What's the
> alternative? kmalloc and kfree every time?
In this case rodata will work. However, if you ever switch to direct DMA
it will fail. I really did overlook the const keyword.
[..]
> > +static void disconnect(struct usb_interface *intf)
> > This is racy. It allows io to disconnected devices. You must take the
> > lock and set a flag that you test after you've taken the lock elsewhere.
>
> Will fix, thanks.
You're welcome
Regards
Oliver
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Daniel Drake @ 2006-06-03 19:35 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-usb-devel, John W. Linville, netdev, Ulrich Kunitz
In-Reply-To: <200606031951.09135.oliver@neukum.org>
Oliver Neukum wrote:
> +static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
> +{
> + static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
> + return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
> +}
>
> Why on the stack?
Technically it's not on the stack because it is static const (it goes in
rodata), but I don't think that this invalidates your point. What's the
alternative? kmalloc and kfree every time?
(Just seems a little over the top for such a small array)
> +static int zd1211_hw_reset_phy(struct zd_chip *chip)
> +{
> + static const struct zd_ioreq16 ioreqs[] = {
>
> This is too much to allocate on the stack.
Again static const, it's definately in rodata, checked with objdump. Do
we need to change this?
> +static void disconnect(struct usb_interface *intf)
> This is racy. It allows io to disconnected devices. You must take the
> lock and set a flag that you test after you've taken the lock elsewhere.
Will fix, thanks.
Daniel
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-03 17:51 UTC (permalink / raw)
To: linux-usb-devel; +Cc: Daniel Drake, John W. Linville, netdev, Ulrich Kunitz
In-Reply-To: <44817083.508@gentoo.org>
Am Samstag, 3. Juni 2006 13:20 schrieb Daniel Drake:
> I tried to submit this patch yesterday, but it doesn't appear to have
> been delivered. The patch is probably a bit on the large side, so I'll
> try again over http:
>
> http://dev.gentoo.org/~dsd/kernel/zd1211rw.patch
>
> Any comments appreciated.
+static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
+{
+ static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
+ return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
+}
Why on the stack?
+static int zd1211_hw_reset_phy(struct zd_chip *chip)
+{
+ static const struct zd_ioreq16 ioreqs[] = {
+ { CR0, 0x0a }, { CR1, 0x06 }, { CR2, 0x26 },
+ { CR3, 0x38 }, { CR4, 0x80 }, { CR9, 0xa0 },
+ { CR10, 0x81 }, { CR11, 0x00 }, { CR12, 0x7f },
+ { CR13, 0x8c }, { CR14, 0x80 }, { CR15, 0x3d },
+ { CR16, 0x20 }, { CR17, 0x1e }, { CR18, 0x0a },
+ { CR19, 0x48 }, { CR20, 0x0c }, { CR21, 0x0c },
+ { CR22, 0x23 }, { CR23, 0x90 }, { CR24, 0x14 },
+ { CR25, 0x40 }, { CR26, 0x10 }, { CR27, 0x19 },
+ { CR28, 0x7f }, { CR29, 0x80 }, { CR30, 0x4b },
+ { CR31, 0x60 }, { CR32, 0x43 }, { CR33, 0x08 },
+ { CR34, 0x06 }, { CR35, 0x0a }, { CR36, 0x00 },
+ { CR37, 0x00 }, { CR38, 0x38 }, { CR39, 0x0c },
+ { CR40, 0x84 }, { CR41, 0x2a }, { CR42, 0x80 },
+ { CR43, 0x10 }, { CR44, 0x12 }, { CR46, 0xff },
+ { CR47, 0x1E }, { CR48, 0x26 }, { CR49, 0x5b },
+ { CR64, 0xd0 }, { CR65, 0x04 }, { CR66, 0x58 },
+ { CR67, 0xc9 }, { CR68, 0x88 }, { CR69, 0x41 },
+ { CR70, 0x23 }, { CR71, 0x10 }, { CR72, 0xff },
+ { CR73, 0x32 }, { CR74, 0x30 }, { CR75, 0x65 },
+ { CR76, 0x41 }, { CR77, 0x1b }, { CR78, 0x30 },
+ { CR79, 0x68 }, { CR80, 0x64 }, { CR81, 0x64 },
+ { CR82, 0x00 }, { CR83, 0x00 }, { CR84, 0x00 },
+ { CR85, 0x02 }, { CR86, 0x00 }, { CR87, 0x00 },
+ { CR88, 0xff }, { CR89, 0xfc }, { CR90, 0x00 },
+ { CR91, 0x00 }, { CR92, 0x00 }, { CR93, 0x08 },
+ { CR94, 0x00 }, { CR95, 0x00 }, { CR96, 0xff },
+ { CR97, 0xe7 }, { CR98, 0x00 }, { CR99, 0x00 },
+ { CR100, 0x00 }, { CR101, 0xae }, { CR102, 0x02 },
+ { CR103, 0x00 }, { CR104, 0x03 }, { CR105, 0x65 },
+ { CR106, 0x04 }, { CR107, 0x00 }, { CR108, 0x0a },
+ { CR109, 0xaa }, { CR110, 0xaa }, { CR111, 0x25 },
+ { CR112, 0x25 }, { CR113, 0x00 }, { CR119, 0x1e },
+ { CR125, 0x90 }, { CR126, 0x00 }, { CR127, 0x00 },
+ { },
+ { CR5, 0x00 }, { CR6, 0x00 }, { CR7, 0x00 },
+ { CR8, 0x00 }, { CR9, 0x20 }, { CR12, 0xf0 },
+ { CR20, 0x0e }, { CR21, 0x0e }, { CR27, 0x10 },
+ { CR44, 0x33 }, { CR47, 0x1E }, { CR83, 0x24 },
+ { CR84, 0x04 }, { CR85, 0x00 }, { CR86, 0x0C },
+ { CR87, 0x12 }, { CR88, 0x0C }, { CR89, 0x00 },
+ { CR90, 0x10 }, { CR91, 0x08 }, { CR93, 0x00 },
+ { CR94, 0x01 }, { CR95, 0x00 }, { CR96, 0x50 },
+ { CR97, 0x37 }, { CR98, 0x35 }, { CR101, 0x13 },
+ { CR102, 0x27 }, { CR103, 0x27 }, { CR104, 0x18 },
+ { CR105, 0x12 }, { CR109, 0x27 }, { CR110, 0x27 },
+ { CR111, 0x27 }, { CR112, 0x27 }, { CR113, 0x27 },
+ { CR114, 0x27 }, { CR115, 0x26 }, { CR116, 0x24 },
+ { CR117, 0xfc }, { CR118, 0xfa }, { CR120, 0x4f },
+ { CR123, 0x27 }, { CR125, 0xaa }, { CR127, 0x03 },
+ { CR128, 0x14 }, { CR129, 0x12 }, { CR130, 0x10 },
+ { CR131, 0x0C }, { CR136, 0xdf }, { CR137, 0x40 },
+ { CR138, 0xa0 }, { CR139, 0xb0 }, { CR140, 0x99 },
+ { CR141, 0x82 }, { CR142, 0x54 }, { CR143, 0x1c },
+ { CR144, 0x6c }, { CR147, 0x07 }, { CR148, 0x4c },
+ { CR149, 0x50 }, { CR150, 0x0e }, { CR151, 0x18 },
+ { CR160, 0xfe }, { CR161, 0xee }, { CR162, 0xaa },
+ { CR163, 0xfa }, { CR164, 0xfa }, { CR165, 0xea },
+ { CR166, 0xbe }, { CR167, 0xbe }, { CR168, 0x6a },
+ { CR169, 0xba }, { CR170, 0xba }, { CR171, 0xba },
+ /* Note: CR204 must lead the CR203 */
+ { CR204, 0x7d },
+ { },
+ { CR203, 0x30 },
+ };
This is too much to allocate on the stack.
+static void disconnect(struct usb_interface *intf)
+{
+ struct net_device *netdev = zd_intf_to_netdev(intf);
+ struct zd_mac *mac = zd_netdev_mac(netdev);
+ struct zd_usb *usb = &mac->chip.usb;
+
+ dev_dbg_f(zd_usb_dev(usb), "\n");
+
+ zd_netdev_disconnect(netdev);
+
+ /* Just in case something has gone wrong! */
+ zd_usb_disable_rx(usb);
+ zd_usb_disable_int(usb);
+
+ /* If the disconnect has been caused by a removal of the
+ * driver module, the reset allows reloading of the driver. If the
+ * reset will not be executed here, the upload of the firmware in the
+ * probe function caused by the reloading of the driver will fail.
+ */
+ usb_reset_device(interface_to_usbdev(intf));
+
+ /* If somebody still waits on this lock now, this is an error. */
+ zd_netdev_free(netdev);
+ dev_dbg(&intf->dev, "disconnected\n");
+}
This is racy. It allows io to disconnected devices. You must take the
lock and set a flag that you test after you've taken the lock elsewhere.
Regards
Oliver
^ permalink raw reply
* Re: [RFC] TCP limited slow start
From: John Heffner @ 2006-06-03 16:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20060602185403.1549e3c6@localhost.localdomain>
Stephen Hemminger wrote:
> Rolled my sleeve's up and gave this a try...
>
> This is a implementation of Sally Floyd's Limited Slow Start
> for Large Congestion Windows.
Limited slow start is useful as a work-around for bottleneck queues that
are inappropriately short. I don't think it's good to run it all the
time by default (with a max_ssthresh < infinity), because it slows down
flows on healthy paths, and introduces another non-scalable parameter to
TCP.
I see it as potentially useful as a per-route parameter, where you set
it deliberately to work around some known problematic path. A sysctl
with a default value of infinity might be okay as well.
Practically speaking, we've had this in the Web100 patch for a long time
(and still do, look for WAD_MaxSsthresh), but I've never found it all
that useful. If the bottleneck queue is too short, you usually end up
getting screwed other ways too.
-John
^ permalink raw reply
* Re: r8169+NAPI soft lockup
From: Richard Gregory @ 2006-06-03 15:05 UTC (permalink / raw)
To: Francois Romieu, netdev
In-Reply-To: <20060510215004.GA25395@electric-eye.fr.zoreil.com>
A little more info to the dead thread...
The machine died this morning, network and serial console were
unresponsive. On rebooting, the only unusual message in logs were the
last two:
Jun 3 01:58:39 loft -- MARK --
Jun 3 02:03:39 loft -- MARK --
Jun 3 02:08:40 loft -- MARK --
Jun 3 02:10:26 loft smartd[18830]: Device: /dev/hda, starting scheduled
Short Self-Test.
Jun 3 02:10:27 loft smartd[18830]: Device: /dev/hdc, starting scheduled
Short Self-Test.
Jun 3 02:10:27 loft smartd[18830]: Device: /dev/hde, starting scheduled
Short Self-Test.
Jun 3 02:10:28 loft smartd[18830]: Device: /dev/hdg, starting scheduled
Short Self-Test.
Jun 3 02:10:28 loft smartd[18830]: Device: /dev/hdi, starting scheduled
Short Self-Test.
Jun 3 02:10:29 loft smartd[18830]: Device: /dev/hdk, starting scheduled
Short Self-Test.
Jun 3 02:10:30 loft smartd[18830]: Device: /dev/hdm, starting scheduled
Short Self-Test.
Jun 3 02:10:31 loft smartd[18830]: Device: /dev/hdo, starting scheduled
Short Self-Test.
Jun 3 02:10:32 loft smartd[18830]: Device: /dev/hdq, starting scheduled
Short Self-Test.
Jun 3 02:10:32 loft smartd[18830]: Device: /dev/hds, starting scheduled
Short Self-Test.
Jun 3 02:13:26 loft kernel: hdo: lost interrupt
Jun 3 02:13:46 loft kernel: hdo: dma_timer_expiry: dma status == 0x21
'lost interrupt' has never been seen before in the logs.
I guess this more strongly implicates the it821x driver.
Richard
^ permalink raw reply
* Fwd: notice
From: Callie Thurman @ 2006-06-03 13:28 UTC (permalink / raw)
To: netdev
Life Should be Full of Luxuries....
http://blessthathomepleasee.com/
Yet, only a handful of people can afford the finest products, the luxuries of the elite.
But, here at "Luxury Replica" we are committed to bringing you the finest products, at prices incomparably lower.
All of the top designer brands for Watches, Ties, Handbags and even Mont Blanc.
http://newgunforsalejoke.com/
The finest of products, at the lowest of prices, only a click away:
http://newgunforsalejoke.com/
Regards,
Callie Thurman
^ permalink raw reply
* Re: OLPC (One Laptop Per Child) Developer's program.
From: David Woodhouse @ 2006-06-03 11:49 UTC (permalink / raw)
To: jg; +Cc: netdev, OLPC Developer's List
In-Reply-To: <1149025377.30703.141.camel@localhost.localdomain>
On Tue, 2006-05-30 at 17:42 -0400, Jim Gettys wrote:
> As you know, we've said we were going to have a developer's program. You
> can find more information, including how to apply for boards at:
>
> http://wiki.laptop.org/index.php/Developers_Program
>
> Note that these are bare PC prototype boards, not packaged machines.
> Jim Gettys
ObNetdev:
One thing we really need is NAT-PT or an equivalent for allowing access
to the Legacy Internet from IPv6-only hosts. As soon as I finish playing
with JFFS2 improvements, I plan to start looking at that.
Not that we really need the actual prototype boards for working on that,
of course.
--
dwmw2
^ permalink raw reply
* [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Daniel Drake @ 2006-06-03 11:20 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Ulrich Kunitz, USB development list
I tried to submit this patch yesterday, but it doesn't appear to have
been delivered. The patch is probably a bit on the large side, so I'll
try again over http:
http://dev.gentoo.org/~dsd/kernel/zd1211rw.patch
Any comments appreciated.
[PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
There are 60+ USB wifi adapters available on the market based on the
ZyDAS ZD1211 chip.
Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so
most data operations are coordinated by the device driver. The ZD1211
chip sits alongside an RF transceiver which is also controlled by the
driver. Our driver currently supports 2 RF types, we know of one other
available in a few marketed products which we will be supporting soon.
Our driver also supports the newer revision of ZD1211, called ZD1211B.
The initialization and RF operations are slightly different for the new
revision, but the main difference is 802.11e support. Our driver does
not support the QoS features yet, but we think we know how to use them.
This driver is based on ZyDAS's own GPL driver available from
www.zydas.com.tw. ZyDAS engineers have been responsive and supportive of
our efforts, so thumbs up to them. Additionally, the firmware is
redistributable and they have provided device specs.
This driver has been written primarily by Ulrich Kunitz and myself.
Graham Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed.
The developers of ieee80211 and softmac have made our lives so much
easier- thanks!
We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite
If there is enough time for review, we would like to aim for inclusion
in 2.6.18. The driver works nicely as a STA, and can connect to both
open and encrypted networks (we are using software-based encryption for
now). We will work towards supporting more advanced features in the
future (ad-hoc, master mode, 802.11a, ...).
Signed-off-by: Daniel Drake <dsd@gentoo.org>
^ permalink raw reply
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: Herbert Xu @ 2006-06-03 11:07 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: bugme-daemon, davem, netdev
In-Reply-To: <20060603.195123.77471511.yoshfuji@linux-ipv6.org>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On Sat, Jun 03, 2006 at 07:51:23PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> I think that people will start thinking why we cannot
> skb_pull(skb, len) if skb_headlen(skb) == len; some comment needed...
Good idea. Here is a better one.
[TCP]: Avoid skb_pull if possible when trimming head
Trimming the head of an skb by calling skb_pull can cause the packet
to become unaligned if the length pulled is odd. Since the length is
entirely arbitrary for a FIN packet carrying data, this is actually
quite common.
Unaligned data is not the end of the world, but we should avoid it if
it's easily done. In this case it is trivial. Since we're discarding
all of the head data it doesn't matter whether we move skb->data forward
or back.
However, it is still possible to have unaligned skb->data in general.
So network drivers should be prepared to handle it instead of crashing.
This patch also adds an unlikely marking on len < headlen since partial
ACKs on head data are extremely rare in the wild. As the return value
of __pskb_trim_head is no longer ever NULL that has been removed.
Signed-off-by: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Thanks,
--
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
[-- Attachment #2: tcp-trim-head-2.patch --]
[-- Type: text/plain, Size: 1203 bytes --]
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 743016b..f33c9dd 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -642,7 +642,7 @@ int tcp_fragment(struct sock *sk, struct
* eventually). The difference is that pulled data not copied, but
* immediately discarded.
*/
-static unsigned char *__pskb_trim_head(struct sk_buff *skb, int len)
+static void __pskb_trim_head(struct sk_buff *skb, int len)
{
int i, k, eat;
@@ -667,7 +667,6 @@ static unsigned char *__pskb_trim_head(s
skb->tail = skb->data;
skb->data_len -= len;
skb->len = skb->data_len;
- return skb->tail;
}
int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
@@ -676,12 +675,11 @@ int tcp_trim_head(struct sock *sk, struc
pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
return -ENOMEM;
- if (len <= skb_headlen(skb)) {
+ /* If len == headlen, we avoid __skb_pull to preserve alignment. */
+ if (unlikely(len < skb_headlen(skb)))
__skb_pull(skb, len);
- } else {
- if (__pskb_trim_head(skb, len-skb_headlen(skb)) == NULL)
- return -ENOMEM;
- }
+ else
+ __pskb_trim_head(skb, len - skb_headlen(skb));
TCP_SKB_CB(skb)->seq += len;
skb->ip_summed = CHECKSUM_HW;
^ permalink raw reply related
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-03 10:51 UTC (permalink / raw)
To: herbert; +Cc: bugme-daemon, davem, netdev, yoshfuji
In-Reply-To: <20060603095442.GA373@gondor.apana.org.au>
In article <20060603095442.GA373@gondor.apana.org.au> (at Sat, 3 Jun 2006 19:54:42 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> [TCP]: Avoid skb_pull if possible when trimming head
>
> Trimming the head of an skb by calling skb_pull can cause the packet
> to become unaligned if the length pulled is odd. Since the length is
> entirely arbitrary for a FIN packet carrying data, this is actually
> quite common.
I think that people will start thinking why we cannot
skb_pull(skb, len) if skb_headlen(skb) == len; some comment needed...
--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