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 <[EMAIL PROTECTED]> Date: Sat, 3 Jun 2006 21:07:11 +1000 > 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 Applied, thanks a lot Herbert. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless (was Re: 2.6.18 -mm merge plans)
On Sun, 4 Jun 2006 21:06:36 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote: > > acx1xx-wireless-driver.patch > > fix-tiacx-on-alpha.patch > > tiacx-fix-attribute-packed-warnings.patch > > tiacx-pci-build-fix.patch > > tiacx-ia64-fix.patch > > > > It is about time we did something with this large and presumably useful > > wireless driver. > > I've never had technical objections to merging this, just AFAIK it had a > highly questionable origin, namely being reverse-engineered in a > non-clean-room environment that might leave Linux legally vulnerable. I never knew that. I still don't know that. Denis, do you know the details? > If we can clear that hurdle, by all means pass it on to John Linville > and get it moving towards upstream. OK, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
wireless (was Re: 2.6.18 -mm merge plans)
On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote: > acx1xx-wireless-driver.patch > fix-tiacx-on-alpha.patch > tiacx-fix-attribute-packed-warnings.patch > tiacx-pci-build-fix.patch > tiacx-ia64-fix.patch > > It is about time we did something with this large and presumably useful > wireless driver. I've never had technical objections to merging this, just AFAIK it had a highly questionable origin, namely being reverse-engineered in a non-clean-room environment that might leave Linux legally vulnerable. If we can clear that hurdle, by all means pass it on to John Linville and get it moving towards upstream. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hush noisy ieee80211 CCMP printks
Don't swamp syslog with
CCMP: decrypt failed: STA=00:12:17:3a:e2:c7
and
CCMP: replay detected: STA=00:12:17:3a:e2:c7 previous PN 0004 received
PN 0004
messages.
These both seem to be completely normal in regular use, especially
'decrypt failed' whenever another wpa-using station on the same AP is
within range.
These events are still being counted in the statistics.
Signed-off-by: Jason Lunz <[EMAIL PROTECTED]>
---
net/ieee80211/ieee80211_crypt_ccmp.c | 11 ---
1 file changed, 11 deletions(-)
Index: linux-2.6.17-rc5-git11/net/ieee80211/ieee80211_crypt_ccmp.c
===
--- linux-2.6.17-rc5-git11.orig/net/ieee80211/ieee80211_crypt_ccmp.c
+++ linux-2.6.17-rc5-git11/net/ieee80211/ieee80211_crypt_ccmp.c
@@ -326,13 +326,6 @@
pos += 8;
if (memcmp(pn, key->rx_pn, CCMP_PN_LEN) <= 0) {
- if (net_ratelimit()) {
- printk(KERN_DEBUG "CCMP: replay detected: STA=" MAC_FMT
- " previous PN %02x%02x%02x%02x%02x%02x "
- "received PN %02x%02x%02x%02x%02x%02x\n",
- MAC_ARG(hdr->addr2), MAC_ARG(key->rx_pn),
- MAC_ARG(pn));
- }
key->dot11RSNAStatsCCMPReplays++;
return -4;
}
@@ -357,10 +350,6 @@
}
if (memcmp(mic, a, CCMP_MIC_LEN) != 0) {
- if (net_ratelimit()) {
- printk(KERN_DEBUG "CCMP: decrypt failed: STA="
- MAC_FMT "\n", MAC_ARG(hdr->addr2));
- }
key->dot11RSNAStatsCCMPDecryptErrors++;
return -5;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Rami Rosen wrote: It is mentioned there that these definitions are taken from the ZYDAS driver and not all of them are relevant for the rewrite driver; however, it seems to me that removing them may be thought of. They are mostly relevant, not all come from the vendor driver directly, some will be used later, many are useful for documenting the bits and bobs that we *do* know about the CR registers (not a lot). I don't think there are any readability issues while all defines are kept out of the way from the code. Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
John Que wrote:
I had noticed that the zd1211 driver does call request_irq() in
zd1205_open(),
file zd1205.c;
Look at it in context:
#ifndef HOST_IF_USB
if ((rc = request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name,
dev)) != 0) {
printk(KERN_ERR "zd1205: failed to request_irq\n");
The ZD1211 vendor driver appears to be an adapted version of another
ZyDAS driver which supports a PCI wifi chip, presumably there are some
similarities. There are many such headaches when trying to read through
this driver...
request_irq never happens because HOST_IF_USB gets defined.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: quiet down log spam from set_security
John, please queue for 2.6.18.
--
From: Jason Lunz <[EMAIL PROTECTED]>
The debug logging in bcm43xx_ieee80211_set_security() is pretty noisy.
Make it more silent.
Signed-off-by: Jason Lunz <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
diff -ur linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c
--- linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-05-29 12:33:56.0 -0400
+++ linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-06-04 14:51:09.0 -0400
@@ -3568,7 +3568,7 @@
unsigned long flags;
int keyidx;
- dprintk(KERN_INFO PFX "set security called\n");
+ dprintk(KERN_INFO PFX "set security called");
bcm43xx_lock_mmio(bcm, flags);
@@ -3581,24 +3581,25 @@
if (sec->flags & SEC_ACTIVE_KEY) {
secinfo->active_key = sec->active_key;
- dprintk(KERN_INFO PFX " .active_key = %d\n", sec->active_key);
+ dprintk(", .active_key = %d", sec->active_key);
}
if (sec->flags & SEC_UNICAST_GROUP) {
secinfo->unicast_uses_group = sec->unicast_uses_group;
- dprintk(KERN_INFO PFX " .unicast_uses_group = %d\n",
sec->unicast_uses_group);
+ dprintk(", .unicast_uses_group = %d", sec->unicast_uses_group);
}
if (sec->flags & SEC_LEVEL) {
secinfo->level = sec->level;
- dprintk(KERN_INFO PFX " .level = %d\n", sec->level);
+ dprintk(", .level = %d", sec->level);
}
if (sec->flags & SEC_ENABLED) {
secinfo->enabled = sec->enabled;
- dprintk(KERN_INFO PFX " .enabled = %d\n", sec->enabled);
+ dprintk(", .enabled = %d", sec->enabled);
}
if (sec->flags & SEC_ENCRYPT) {
secinfo->encrypt = sec->encrypt;
- dprintk(KERN_INFO PFX " .encrypt = %d\n", sec->encrypt);
+ dprintk(", .encrypt = %d", sec->encrypt);
}
+ dprintk("\n");
if (bcm->initialized && !bcm->ieee->host_encrypt) {
if (secinfo->enabled) {
/* upload WEP keys to hardware */
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Am Sonntag, 4. Juni 2006 20:22 schrieb John Que: > Hello Oliver, > > I am sorry, but I think I don't understand , > You said: > >A USB driver never will request an irq. Interrupt handling is done in > > the core usb layer. Individual drivers have no business there. > > but in the zd1211 driver (not the rewrite version) I found this > call to request an irq: > request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name, dev) > > Also when looking in the linux tree, I see some request_irq() calls in USB > drivers, for exmaple in some drivers under usb/gadgaets, and more. > > Can you please elaborate a bit ? What do you mean by saying > "A USB driver never will request an irq"? The architecture is as follows: device driver <---> USB core <---> host driver <=== USB ===> gadget driver <---> function driver Only those drivers that deal with the hardware directly request interrupts. A device driver submits URBs and deals with callbacks. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Hello Oliver, I am sorry, but I think I don't understand , You said: A USB driver never will request an irq. Interrupt handling is done in the core usb layer. Individual drivers have no business there. but in the zd1211 driver (not the rewrite version) I found this call to request an irq: request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name, dev) Also when looking in the linux tree, I see some request_irq() calls in USB drivers, for exmaple in some drivers under usb/gadgaets, and more. Can you please elaborate a bit ? What do you mean by saying "A USB driver never will request an irq"? -- John On 6/4/06, Oliver Neukum <[EMAIL PROTECTED]> wrote: Am Sonntag, 4. Juni 2006 18:29 schrieb John Que: > I had noticed that the zd1211 driver does call request_irq() in zd1205_open(), > file zd1205.c; grepping for request_irq() in the rewrite driver yields > no results. > (I looked at the rewrite version from a week ago but in this point it > is probably the > same). > Why is this so ? I assume that the softmac layer does not call request_irq() on > behalf of the driver because this is not supposed to be like it, as I understand > its functionality. Can anybody briefly calrify this point ? A USB driver never will request an irq. Interrupt handling is done in the core usb layer. Individual drivers have no business there. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Hi, While I did not yet review fully the code , I saw some definitions which are not in use. (more than 150 such definitions, in one file) I think it may be better to remove this #define statements to make the code more readable. In case there will be a need in the future, the needed #define statements can be returned. The definitions which are not in use are from zd_chip.h. It is mentioned there that these definitions are taken from the ZYDAS driver and not all of them are relevant for the rewrite driver; however, it seems to me that removing them may be thought of. Anyhow you did a great job and I hope I will find time to really delve into the code. The definitions I am talking about are: (see zd_chip.h) CR_RF_IF_CLK CR_RF_IF_DATA CR_PE1_PE2 CR_PE2_DLY CR_LE1 CR_LE2 CR_RADIO_PD CR_RF2948_PD CR_ENABLE_PS_MANUAL_AGC CR_SA2400_SER_AP CR_I2C_WRITE CR_SA2400_SER_RP CR_RADIO_PE CR_RST_BUS_MASTER CR_HSTSCHG CR_PHY_ON CR_RX_DELAY CR_GPIO_1 CR_GPIO_2 CR_EncryBufMux CR_MAC_PS_STATE INT_TX_COMPLETE INT_RX_COMPLETE INT_RETRY_FAIL INT_WAKEUP INT_DTIM_NOTIFY INT_CFG_NEXT_BCN INT_BUS_ABORT INT_TX_FIFO_READY INT_UART INT_TX_COMPLETE_EN INT_RX_COMPLETE_EN INT_RETRY_FAIL_EN INT_WAKEUP_EN INT_DTIM_NOTIFY_EN INT_CFG_NEXT_BCN_EN INT_BUS_ABORT_EN INT_TX_FIFO_READY_EN INT_UART_EN CR_TSF_LOW_PART CR_TSF_HIGH_PART CR_UART_RBR_THR_DLL CR_UART_DLM_IER CR_UART_IIR_FCR CR_UART_LCR CR_UART_MCR CR_UART_LSR CR_UART_MSR CR_UART_ECR CR_UART_STATUS CR_PCI_TX_ADDR_P1 CR_PCI_TX_AddR_P2 CR_PCI_RX_AddR_P1 CR_PCI_RX_AddR_P2 CR_BSSID_P1 CR_BSSID_P2 CR_RX_TIMEOUT CR_RATE_9M CR_RATE_18M CR_RATE_36M CR_RATE_48M CR_RATE_54M CR_RX_OFFSET CR_PHY_DELAY CR_BCN_FIFO CR_DEVICE_STATE CR_UNDERRUN_CNT CR_BCN_FIFO_SEMAPHORE CR_IFS_VALUE CR_RX_TIME_OUT CR_TOTAL_RX_FRM CR_CRC32_CNT CR_CRC16_CNT CR_DECRYPTION_ERR_UNI CR_RX_FIFO_OVERRUN CR_DECRYPTION_ERR_MUL CR_NAV_CNT CR_NAV_CCA CR_RETRY_CNT CR_READ_TCB_ADDR CR_READ_RFD_ADDR CR_TOTAL_TX_FRM CR_CAM_MODE CR_CAM_ROLL_TB_LOW CR_CAM_ROLL_TB_HIGH CR_CAM_ADDRESS CR_CAM_DATA CR_ROMDIR CR_DECRY_ERR_FLG_LOW CR_DECRY_ERR_FLG_HIGH CR_WEPKEY0 CR_WEPKEY1 CR_WEPKEY2 CR_WEPKEY3 CR_WEPKEY4 CR_WEPKEY5 CR_WEPKEY6 CR_WEPKEY7 CR_WEPKEY8 CR_WEPKEY9 CR_WEPKEY10 CR_WEPKEY11 CR_WEPKEY12 CR_WEPKEY13 CR_WEPKEY14 CR_WEPKEY15 CR_TKIP_MODE CR_EEPROM_PROTECT0 CR_EEPROM_PROTECT1 CR_DBG_FIFO_RD CR_DBG_SELECT CR_FIFO_Length CR_RSSI_MGC CR_PON CR_RX_ON CR_TX_ON CR_CHIP_EN CR_LO_SW CR_TXRX_SW CR_S_MD CR_USB_DEBUG_PORT STA_RX_FILTER E2P_PWR_CAL_VALUE2 E2P_PWR_CAL_VALUE3 E2P_PWR_CAL_VALUE4 E2P_PWR_INT_VALUE2 E2P_PWR_INT_VALUE3 E2P_PWR_INT_VALUE4 E2P_ALLOWED_CHANNEL E2P_DEVICE_VER E2P_36M_CAL_VALUE2 E2P_36M_CAL_VALUE3 E2P_36M_CAL_VALUE4 E2P_11A_INT_VALUE1 E2P_11A_INT_VALUE2 E2P_11A_INT_VALUE3 E2P_11A_INT_VALUE4 E2P_48M_CAL_VALUE2 E2P_48M_CAL_VALUE3 E2P_48M_CAL_VALUE4 E2P_48M_INT_VALUE1 E2P_48M_INT_VALUE2 E2P_48M_INT_VALUE3 E2P_48M_INT_VALUE4 E2P_54M_CAL_VALUE2 E2P_54M_CAL_VALUE3 E2P_54M_CAL_VALUE4 E2P_54M_INT_VALUE1 E2P_54M_INT_VALUE2 E2P_54M_INT_VALUE3 E2P_54M_INT_VALUE4 FW_SOFT_RESET FW_FLASH_CHK Regards, Rami Rosen On 6/4/06, Oliver Neukum <[EMAIL PROTECTED]> wrote: Am Sonntag, 4. Juni 2006 18:29 schrieb John Que: > I had noticed that the zd1211 driver does call request_irq() in zd1205_open(), > file zd1205.c; grepping for request_irq() in the rewrite driver yields > no results. > (I looked at the rewrite version from a week ago but in this point it > is probably the > same). > Why is this so ? I assume that the softmac layer does not call request_irq() on > behalf of the driver because this is not supposed to be like it, as I understand > its functionality. Can anybody briefly calrify this point ? A USB driver never will request an irq. Interrupt handling is done in the core usb layer. Individual drivers have no business there. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Am Sonntag, 4. Juni 2006 18:29 schrieb John Que: > I had noticed that the zd1211 driver does call request_irq() in > zd1205_open(), > file zd1205.c; grepping for request_irq() in the rewrite driver yields > no results. > (I looked at the rewrite version from a week ago but in this point it > is probably the > same). > Why is this so ? I assume that the softmac layer does not call request_irq() > on > behalf of the driver because this is not supposed to be like it, as I > understand > its functionality. Can anybody briefly calrify this point ? A USB driver never will request an irq. Interrupt handling is done in the core usb layer. Individual drivers have no business there. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Hello,
I must confess I don't know much about the ZyDas driver and the rewrite
dirver, but folliowing this post I looked a bit at the code (of both
zd1211 and the rewrite version) and I have a little question; this may
be
seen as a (little) off topic but I will be happy if somebody will
raise this coin.
I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
file zd1205.c; grepping for request_irq() in the rewrite driver yields
no results.
(I looked at the rewrite version from a week ago but in this point it
is probably the
same).
Why is this so ? I assume that the softmac layer does not call request_irq() on
behalf of the driver because this is not supposed to be like it, as I understand
its functionality. Can anybody briefly calrify this point ?
Regards,
John
On 6/4/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH SB1250 NAPI support
A while ago I submitted this patch for NAPI support for SB1250 / SB1480. I have tested it again on the recent (6/3/06) linux-mips kernel. Tom Below is the original posting. This patch adds NAPI support for the Broadcom Sibyte SB1xxx family. The changes are limited to adding a new config key SBMAC_NAPI to the drivers/ net/Kconfig and by adding the poll op and interrupt support to drivers/ net/sb1250-mac.c. This patch also has a fix to drivers/net/sb1250-mac.c, the dma descriptor table ptr is allocated, aligned and the aligned ptr is freed. If the ptr was not already aligned (usually is) then the free would not work of what was returned by the kmalloc. A variable was added to store the unaligned pointer so that it could be properly freed. I have tested this patch on a BCM91250A-SWARM Pass 2 / An. Mark Mason from Broadcom was very helpful and tested this patch on at least a 1480. Tom On Thu, 25 May 2006 08:35:05 -0500, Martin Michlmayr <[EMAIL PROTECTED]> wrote: * Tom Rix <[EMAIL PROTECTED]> [2006-05-25 08:06]: I am busy now but will get to it sometime. It will require retesting with the latest kernel source. Is there a particular maintainer(s) that I should cc on this patch? [EMAIL PROTECTED] He just reminded people that the merge window for 2.6.18 will open soon (and that he's collecting patches for that already) so now would be an excellent time. Thanks. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ mips-sb1250-mac-NAPI-3.patch Description: Binary data
Re: OLPC (One Laptop Per Child) Developer's program.
On Sat, 03 Jun 2006 12:49:05 +0100, David Woodhouse wrote: > 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. Wouldn't miredo mostly fit the bill? It won't get through Symmetric NATs (by design) but those are supposed to be uncommon. Cheers, Anand - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
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 ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 pgpgdSv0yliKV.pgp Description: PGP signature
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx-d80211: Fix 64bit compiler warnings
Fix all 64bit compiler warnings.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx-d80211: add DMA rx poll workaround to DMA4
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 <[EMAIL PROTECTED]>
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 = 0x;
+ 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) == 0x);
@@ -640,16 +643,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x:
+ 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 >= 1)) {
+ 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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
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 <[EMAIL PROTECTED]> > > 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 pgpX6cEmYlayM.pgp Description: PGP signature
