[PATCH 2.6.19-rc2] [REVISED] net/ipv4/multipath_wrandom.c: check kmalloc() return value.
Description: Check the return value of kmalloc() in function wrandom_set_nhinfo(), in file net/ipv4/multipath_wrandom.c. Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]> diff --git a/net/ipv4/multipath_wrandom.c b/net/ipv4/multipath_wrandom.c index 92b0482..bcdb1f1 100644 --- a/net/ipv4/multipath_wrandom.c +++ b/net/ipv4/multipath_wrandom.c @@ -242,6 +242,9 @@ static void wrandom_set_nhinfo(__be32 ne target_route = (struct multipath_route *) kmalloc(size_rt, GFP_ATOMIC); + if (!target_route) + goto error; + target_route->gw = nh->nh_gw; target_route->oif = nh->nh_oif; memset(&target_route->rcu, 0, sizeof(struct rcu_head)); @@ -263,6 +266,9 @@ static void wrandom_set_nhinfo(__be32 ne target_dest = (struct multipath_dest*) kmalloc(size_dst, GFP_ATOMIC); + if (!target_dest) + goto error; + target_dest->nh_info = nh; target_dest->network = network; target_dest->netmask = netmask; @@ -275,6 +281,7 @@ static void wrandom_set_nhinfo(__be32 ne * we are finished */ + error: spin_unlock_bh(&state[state_idx].lock); } - 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: [PATCH 2.6.19-rc2] [REVISED] net/ipv4/multipath_wrandom.c: check kmalloc() return value.
On Sun, 22 Oct 2006, Amit Choudhary wrote: > Description: Check the return value of kmalloc() in function > wrandom_set_nhinfo(), in file net/ipv4/multipath_wrandom.c. > > Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]> Acked-by: James Morris <[EMAIL PROTECTED]> > @@ -242,6 +242,9 @@ static void wrandom_set_nhinfo(__be32 ne > target_route = (struct multipath_route *) > kmalloc(size_rt, GFP_ATOMIC); It'd be nice to see these casts removed in a future cleanup. - James -- James Morris <[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: [PATCH 1/4][CRYPTO][IPsec] pass the flags to the internal tfm allocation
On Sun, 22 Oct 2006 14:53:57 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > On Wed, Oct 18, 2006 at 11:26:06AM +0900, Kazunori MIYAZAWA wrote: > > XCBC needs to allocate the tfm as CBC mode to use > > "xor" function in the tfm. > > I'm sorry but this isn't going to fly. The mode argument is obsolete > and incompatible with the new bit-field flags setup. So I'm not going > to add any new code that uses it. > > In the medium term this code should be converted to use the block-cipher > interface. For now, please either make a local copy of the xor function > or just export the one from crypto/cbc.c. > Hello Herbert, Thank you for your review. I send the patch which does not use the CBC mode. I chose the short term solution and copied the function. This patch does not need the patch of [PATCH 1/4]. Should I re-send [PATCH 3/4] and [PATCH 4/4]? Or could you re-use them? Thank you, -- Kazunori Miyazawa Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]> --- crypto/Kconfig | 10 ++ crypto/Makefile |1 crypto/xcbc.c | 346 +++ 3 files changed, 357 insertions(+), 0 deletions(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index cbae839..9e69643 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -39,6 +39,16 @@ config CRYPTO_HMAC HMAC: Keyed-Hashing for Message Authentication (RFC2104). This is required for IPSec. +config CRYPTO_XCBC +tristate "XCBC support" +depends on CRYPTO && EXPERIMENTAL + select CRYPTO_MANAGER +help + XCBC: Keyed-Hashing with encryption algorithm +http://www.ietf.org/rfc/rfc3566.txt +http://csrc.nist.gov/encryption/modes/proposedmodes/ + xcbc-mac/xcbc-mac-spec.pdf + config CRYPTO_NULL tristate "Null algorithms" select CRYPTO_ALGAPI diff --git a/crypto/Makefile b/crypto/Makefile index 7236620..aba9625 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_CRYPTO_HASH) += crypto_hash obj-$(CONFIG_CRYPTO_MANAGER) += cryptomgr.o obj-$(CONFIG_CRYPTO_HMAC) += hmac.o +obj-$(CONFIG_CRYPTO_XCBC) += xcbc.o obj-$(CONFIG_CRYPTO_NULL) += crypto_null.o obj-$(CONFIG_CRYPTO_MD4) += md4.o obj-$(CONFIG_CRYPTO_MD5) += md5.o diff --git a/crypto/xcbc.c b/crypto/xcbc.c new file mode 100644 index 000..82387f0 --- /dev/null +++ b/crypto/xcbc.c @@ -0,0 +1,346 @@ +/* + * Copyright (C)2006 USAGI/WIDE Project + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * Author: + * Kazunori Miyazawa <[EMAIL PROTECTED]> + */ + +#include +#include +#include +#include +#include +#include +#include +#include "internal.h" + +u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101, + 0x02020202, 0x02020202, 0x02020202, 0x02020202, + 0x03030303, 0x03030303, 0x03030303, 0x03030303}; +/* + * + + * | + * + + * | crypto_xcbc_ctx + * + + * | odds (block size) + * + + * | prev (block size) + * + + * | key (block size) + * + + * | consts (block size * 3) + * + + */ +struct crypto_xcbc_ctx { + struct crypto_tfm *child; + u8 *odds; + u8 *prev; + u8 *key; + u8 *consts; + void (*xor)(u8 *a, const u8 *b, unsigned int bs); + unsigned int keylen; + unsigned int len; +}; + +static void xor_128(u8 *a, const u8 *b, unsigned int bs) +{ + ((u32 *)a)[0] ^= ((u32 *)b)[0]; + ((u32 *)a)[1] ^= ((u32 *)b)[1]; + ((u32 *)a)[2] ^= ((u32 *)b)[2]; + ((u32 *)a)[3] ^= ((u32 *)b)[3]; +} + +static int _crypto_xcbc_digest_setkey(struct crypto_hash *parent, + struct crypto_xcbc_ctx *ctx) +{ + int bs = crypto_hash_blocksize(parent); + int err = 0; + u8 key1[bs]; + + if ((err = crypto_cipher_setkey(ctx->child, ctx->key, ctx->keylen))) + return err; + + ctx->child->__crt_alg->cra_cipher.cia_encrypt(ctx->child, key1, + ctx->consts); + + return crypto_cipher_setkey(ctx->child, key1, bs); +} + +static int crypto_xcbc_digest_setkey(struct crypto_hash *parent, +
Re: [PATCH 1/4][CRYPTO][IPsec] pass the flags to the internal tfm allocation
On Mon, Oct 23, 2006 at 07:08:39PM +0900, Kazunori MIYAZAWA wrote: > > I send the patch which does not use the CBC mode. > I chose the short term solution and copied the function. Thanks Miyazawa-san! > This patch does not need the patch of [PATCH 1/4]. > > Should I re-send [PATCH 3/4] and [PATCH 4/4]? > Or could you re-use them? They should be fine. I'll let you know if I run into any problems applying them :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - 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: [PATCH REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
On Thu, 2006-10-19 at 16:38 +0200, Patrick McHardy wrote: > I still think this patch shouldn't go in. There's no point in doing the > same thing twice, and I haven't heard a compelling argument why it has > to be done in a way that only helps qdiscs using rtabs while ignoring > statistics and estimators (I even provided a patch to show how to do > it without these limitations). As far as I can see one patch changes the way the kernel calculates packet lengths, and the other modifies RTAB. I can not see the significant overlap between the patches that you talk about. As for why haven't got a new patch from me that addresses the "doing the same thing twice" issue - it is because I can see no such issue. I have asked you repeatedly to explain it further, but you have not done so. As for "providing a patch" - I believe at the time you called it something you were working on. As far as I know you still are working on it. Besides, even if you did intend me to take it further, I am not particularly interested in the packet length issue as it does not effect the real world performance of any of the qdiscs I use. > Besides that: > > +static inline u32 qdisc_l2t(struct qdisc_rate_table* rtab, int pktlen) > +{ > + int slot = pktlen + rtab->rate.cell_align; > + if (slot < 0) > + slot = 0; > > Why would it go negative? A negative cell_align doesn't make sense I > guess. A negative cell align is possible, and in fact is typical. If slot ended up being less than 0 then the configuration parameters passed to "tc" would of been wrong - they could not of matched the actual traffic. The error can't be detected in "tc", but it can't be allowed to cause the kernel to index off the end of an array either. > + slot >>= rtab->rate.cell_log; > + if (slot > 255) > + return rtab->data[255] + 1; > > Whats the point of this? Is it just to keep htb giant statistics > working? Yes. - 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: [PATCH 2.6.19-rc2] [REVISED] net/ipv4/multipath_wrandom.c: check kmalloc() return value.
Amit Choudhary wrote: > Description: Check the return value of kmalloc() in function > wrandom_set_nhinfo(), in file net/ipv4/multipath_wrandom.c. > > Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]> > > diff --git a/net/ipv4/multipath_wrandom.c b/net/ipv4/multipath_wrandom.c > index 92b0482..bcdb1f1 100644 > --- a/net/ipv4/multipath_wrandom.c > +++ b/net/ipv4/multipath_wrandom.c > @@ -242,6 +242,9 @@ static void wrandom_set_nhinfo(__be32 ne > target_route = (struct multipath_route *) > kmalloc(size_rt, GFP_ATOMIC); > > + if (!target_route) > + goto error; > + > target_route->gw = nh->nh_gw; > target_route->oif = nh->nh_oif; > memset(&target_route->rcu, 0, sizeof(struct rcu_head)); > @@ -263,6 +266,9 @@ static void wrandom_set_nhinfo(__be32 ne > target_dest = (struct multipath_dest*) > kmalloc(size_dst, GFP_ATOMIC); > > + if (!target_dest) > + goto error; > + > > target_dest->nh_info = nh; > target_dest->network = network; > target_dest->netmask = netmask; > @@ -275,6 +281,7 @@ static void wrandom_set_nhinfo(__be32 ne >* we are finished >*/ > > + error: > spin_unlock_bh(&state[state_idx].lock); > } Thats slightly better than before, but since no errors are propagated back to the routing code I think it would still crash later on. A better idea would be to mark this crap BROKEN until it is really fixed, so people won't accidentally enable it (which is enough to cause problems). Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig index 5572071..9ff5616 100644 --- a/net/ipv4/Kconfig +++ b/net/ipv4/Kconfig @@ -124,8 +124,8 @@ config IP_ROUTE_MULTIPATH if a matching packet arrives. config IP_ROUTE_MULTIPATH_CACHED - bool "IP: equal cost multipath with caching support (EXPERIMENTAL)" - depends on IP_ROUTE_MULTIPATH + bool "IP: equal cost multipath with caching support (BROKEN)" + depends on IP_ROUTE_MULTIPATH && BROKEN help Normally, equal cost multipath routing is not supported by the routing cache. If you say Y here, alternative routes are cached
Re: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Fri, 20 Oct 2006 17:19:36 +0800, Hong Liu wrote: > --- a/include/net/d80211.h > +++ b/include/net/d80211.h > @@ -176,6 +176,7 @@ struct ieee80211_tx_control { > */ > int icv_len:8; /* Length of the ICV/MIC field in octets */ > int iv_len:8; /* Length of the IV field in octets */ > + u8 rc4key[16]; /* generated RC4 key for hw TKIP */ I don't like extending ieee80211_tx_control by 16 more bytes. The driver is required to store a copy of each ieee80211_tx_control (because it's copied to ieee80211_tx_status). I don't have a better idea, though. Anybody? > @@ -476,6 +477,12 @@ struct ieee80211_hw { > /* Force software encryption for TKIP packets if WMM is enabled. */ > unsigned int no_tkip_wmm_hwaccel:1; > > + /* Do TKIP key mixing in stack, send the generated RC4 key with > + * with each TX frame */ > + unsigned int tkip_include_rc4key:1; > + /* calculate michael MIC in stack */ > + unsigned int tkip_include_mmic:1; Please write more descriptive comments (e.g. there should be stated that tkip_include_mmic is relevant only when using hw crypto). Also, it would help if you don't use bitfileds and rebase your patch on top of http://www.spinics.net/lists/netdev/msg17316.html and http://www.spinics.net/lists/netdev/msg17314.html; but I can do it for you when applying the patch. > +void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, > +u8 *rc4key, u8* ta) Put the destination buffer (rc4key) as the last parameter. Thanks, Jiri -- Jiri Benc SUSE Labs - 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: [PATCH REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
Russell Stuart wrote: > On Thu, 2006-10-19 at 16:38 +0200, Patrick McHardy wrote: > >>I still think this patch shouldn't go in. There's no point in doing the >>same thing twice, and I haven't heard a compelling argument why it has >>to be done in a way that only helps qdiscs using rtabs while ignoring >>statistics and estimators (I even provided a patch to show how to do >>it without these limitations). > > > As far as I can see one patch changes the way the > kernel calculates packet lengths, and the other modifies > RTAB. I can not see the significant overlap between the > patches that you talk about. The implementation may be different, but the intention and the result is the same. I probably would mind less if it wouldn't affect userspace compatibility, but we need to carry this stuff for ever even if we add another implementation that covers all qdiscs. > As for why haven't got a new patch from me that addresses > the "doing the same thing twice" issue - it is because I > can see no such issue. I have asked you repeatedly to > explain it further, but you have not done so. What do I need to explain further? As I stated several times, I would like to see a patch that handles all qdiscs. And it should probably not have hardcoded ATM values, there is other media that behaves similar. > As for "providing a patch" - I believe at the time you > called it something you were working on. As far as I > know you still are working on it. Besides, even if you > did intend me to take it further, I am not particularly > interested in the packet length issue as it does not > effect the real world performance of any of the qdiscs > I use. No, I'm not working on it currently, it was more meant for demonstration purposes. If you're not interested in taking the opinion of people working on the code into account thats your problem. >>Besides that: >> >>+static inline u32 qdisc_l2t(struct qdisc_rate_table* rtab, int pktlen) >>+{ >>+ int slot = pktlen + rtab->rate.cell_align; >>+ if (slot < 0) >>+ slot = 0; >> >>Why would it go negative? A negative cell_align doesn't make sense I >>guess. > > > A negative cell align is possible, and in fact is typical. > If slot ended up being less than 0 then the configuration > parameters passed to "tc" would of been wrong - they could > not of matched the actual traffic. The error can't be > detected in "tc", but it can't be allowed to cause the > kernel to index off the end of an array either. I'm not sure I understand what you're saying here. The transmission time gets _smaller_ by transmitting over ATM? Does this have anything to do with the off-by-one during rate table calculation you or Jesper noticed? >>+ slot >>= rtab->rate.cell_log; >>+ if (slot > 255) >>+ return rtab->data[255] + 1; >> >>Whats the point of this? Is it just to keep htb giant statistics >>working? > > > Yes. TBF and policers already make sure this can never happen, this is what HTB should do as well. If it is also needed for CBQ it is a bugfix and should be done seperately. - 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: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Mon, 2006-10-23 at 14:40 +0200, Jiri Benc wrote: > I don't like extending ieee80211_tx_control by 16 more bytes. The > driver is required to store a copy of each ieee80211_tx_control > (because it's copied to ieee80211_tx_status). I don't have a better > idea, though. Anybody? A pointer that goes somewhere else? I suppose it could even be in the skb's cb field. > Please write more descriptive comments (e.g. there should be stated > that tkip_include_mmic is relevant only when using hw crypto). Also, something I just came to think of, bcm43xx does phase2 mixing in hw and requires phase1 in software. Do we handle that with or without this patch? If not, it'd be nice to fix it up together. johannes - 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 2.6.18] defxx: Big-endian hosts support
The PDQ DMA engine requires a different byte-swapping mode for big-endian hosts; also the MAC address which is read from a register through PIO has to be byte-swapped. These changes have been verified with DEFPA-DC (PCI) boards and a Broadcom BCM91250A (MIPS CPU based) host. Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]> --- Please apply. Maciej patch-mips-2.6.18-20060920-defxx-eb-3 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c linux-mips-2.6.18-20060920/drivers/net/defxx.c --- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c2006-09-20 20:50:22.0 + +++ linux-mips-2.6.18-20060920/drivers/net/defxx.c 2006-10-23 00:43:03.0 + @@ -192,6 +192,7 @@ * 04 Aug 2003 macro Converted to the DMA API. * 14 Aug 2004 macro Fix device names reported. * 14 Jun 2005 macro Use irqreturn_t. + * 23 Oct 2006 macro Big-endian host support. */ /* Include files */ @@ -218,8 +219,8 @@ /* Version information string should be updated prior to each new release! */ #define DRV_NAME "defxx" -#define DRV_VERSION "v1.08" -#define DRV_RELDATE "2005/06/14" +#define DRV_VERSION "v1.09" +#define DRV_RELDATE "2006/10/23" static char version[] __devinitdata = DRV_NAME ": " DRV_VERSION " " DRV_RELDATE @@ -860,6 +861,7 @@ static int __devinit dfx_driver_init(str print_name); return(DFX_K_FAILURE); } + data = cpu_to_le32(data); memcpy(&bp->factory_mac_addr[0], &data, sizeof(u32)); if (dfx_hw_port_ctrl_req(bp, PI_PCTRL_M_MLA, PI_PDATA_A_MLA_K_HI, 0, @@ -868,6 +870,7 @@ static int __devinit dfx_driver_init(str print_name); return(DFX_K_FAILURE); } + data = cpu_to_le32(data); memcpy(&bp->factory_mac_addr[4], &data, sizeof(u16)); /* @@ -1086,27 +1089,23 @@ static int dfx_adap_init(DFX_board_t *bp } /* -* Set base address of Descriptor Block and bring adapter to DMA_AVAILABLE state +* Set the base address of Descriptor Block and bring adapter +* to DMA_AVAILABLE state. * -* Note: We also set the literal and data swapping requirements in this -* command. Since this driver presently runs on Intel platforms -* which are Little Endian, we'll tell the adapter to byte swap -* data only. This code will need to change when we support -* Big Endian systems (eg. PowerPC). +* Note: We also set the literal and data swapping requirements +* in this command. * -* Assumption: 32-bit physical address of descriptor block is 8Kbyte -* aligned. That is, bits 0-12 of the address must be zero. +* Assumption: 32-bit physical address of descriptor block +* is 8Kbyte aligned. */ - - if (dfx_hw_port_ctrl_req(bp, - PI_PCTRL_M_INIT, - (u32) (bp->descr_block_phys | PI_PDATA_A_INIT_M_BSWAP_DATA), - 0, - NULL) != DFX_K_SUCCESS) - { - printk("%s: Could not set descriptor block address!\n", bp->dev->name); - return(DFX_K_FAILURE); - } + if (dfx_hw_port_ctrl_req(bp, PI_PCTRL_M_INIT, +(u32)(bp->descr_block_phys | + PI_PDATA_A_INIT_M_BSWAP_INIT), +0, NULL) != DFX_K_SUCCESS) { + printk("%s: Could not set descriptor block address!\n", + bp->dev->name); + return DFX_K_FAILURE; + } /* Set transmit flush timeout value */ diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/net/defxx.h linux-mips-2.6.18-20060920/drivers/net/defxx.h --- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.h2004-11-16 05:57:00.0 + +++ linux-mips-2.6.18-20060920/drivers/net/defxx.h 2006-10-23 00:27:28.0 + @@ -25,6 +25,7 @@ * macros to DEFXX.C. * 12-Sep-96 LVS Removed packet request header pointers. * 04 Aug 2003 macro Converted to the DMA API. + * 23 Oct 2006 macro Big-endian host support. */ #ifndef _DEFXX_H_ @@ -1344,7 +1345,7 @@ typedef struct /* Register definition structures are defined for both big and little endian systems */ -#ifndef BIG_ENDIAN +#ifndef __BIG_ENDIAN /* Little endian format of Type 1 Producer register */ @@ -1402,7 +1403,
Re: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Mon, 23 Oct 2006 14:48:00 +0200, Johannes Berg wrote: > On Mon, 2006-10-23 at 14:40 +0200, Jiri Benc wrote: > > I don't like extending ieee80211_tx_control by 16 more bytes. The > > driver is required to store a copy of each ieee80211_tx_control > > (because it's copied to ieee80211_tx_status). I don't have a better > > idea, though. Anybody? > > A pointer that goes somewhere else? I suppose it could even be in the > skb's cb field. Yes, that could work. Thanks! > Also, something I just came to think of, bcm43xx does phase2 mixing in > hw and requires phase1 in software. Do we handle that with or without > this patch? If not, it'd be nice to fix it up together. It's not supported now. And it's really a good idea to extend the patch to support the bcm43xx case as well. Jiri -- Jiri Benc SUSE Labs - 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: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Mon, Oct 23, 2006 at 02:40:28PM +0200, Jiri Benc wrote: > > int icv_len:8; /* Length of the ICV/MIC field in octets */ > > int iv_len:8; /* Length of the IV field in octets */ > > + u8 rc4key[16]; /* generated RC4 key for hw TKIP */ > > I don't like extending ieee80211_tx_control by 16 more bytes. The > driver is required to store a copy of each ieee80211_tx_control > (because it's copied to ieee80211_tx_status). I don't have a better > idea, though. Anybody? If the key isn't passed directly in via the tx_control structure, there needs to be a way for the driver to be able to get the key for that packet. Many chipsets won't care, but many expect the encryption key to be passed in with each packet. (For WEP, TKIP, or AES-CCMP) Instead of expanding tx_control, adding an API call might suffice. with TKIP all you need to do the RC4 mixing is already in the packet (macaddr, EIV (keynum+PN), and payload. The stack just needs to be able to look up the PTK given the macaddr+keyidx, and the chipset driver can then derive whatever key it needs and stuff the hardware with it. Crypto is the main way where wireless chipsets make life difficult for a common stack.. - Solomon -- Solomon Peachy pizza at shaftnet dot org Melbourne, FL ^^ (mail/jabber/gtalk) ^^ Quidquid latine dictum sit, altum viditur. ICQ: 1318344 pgp3YPhdswmRf.pgp Description: PGP signature
Re: [PATCH 2.6.18] defxx: Big-endian hosts support
On Mon, Oct 23, 2006 at 01:53:17PM +0100, Maciej W. Rozycki wrote: > + data = cpu_to_le32(data); This is rather ugly and not provable by static typechecking. Please always use spearate variables/structs for device and host endian values, and run the resulting driver through sparse to make sure everything is correct. - 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: [PATCH 0/8] e100, e1000: Fixes for netdev-2.6#upstream-fixes
Jeff Garzik wrote: Kok, Auke wrote: Hi, The following fixes targeted to netdev-2.6#upstream-fixes are available through git: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes hrm. since another e100 fixes got applied, can you either (a) update the above URL for that change, or (b) provide separate e100 and e1000 pull urls? I dropped the e100 patch from the series, it now contains (at the above url) only the e1000 changes. Cheers, Auke - 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: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Mon, Oct 23, 2006 at 02:40:28PM +0200, Jiri Benc wrote: > On Fri, 20 Oct 2006 17:19:36 +0800, Hong Liu wrote: > > --- a/include/net/d80211.h > > +++ b/include/net/d80211.h > > @@ -176,6 +176,7 @@ struct ieee80211_tx_control { > > */ > > int icv_len:8; /* Length of the ICV/MIC field in octets */ > > int iv_len:8; /* Length of the IV field in octets */ > > + u8 rc4key[16]; /* generated RC4 key for hw TKIP */ > > I don't like extending ieee80211_tx_control by 16 more bytes. The > driver is required to store a copy of each ieee80211_tx_control > (because it's copied to ieee80211_tx_status). I don't have a better > idea, though. Anybody? We could be more selective about what the driver is required to return in ieee80211_tx_status, the rc4key isn't particularily interesting to ieee80211_tx_status(). I expect there are other uninteresting fields (tx_rate, rts_cts_rate, come to mind, for example). We could put the fields we are interested in directly in ieee80211_tx_status, or have a new structure rather than re-using ieee80211_tx_control inside ieee80211_tx_status. -David - 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: [PATCH] atm: fix horizon init section usage
David Miller wrote: From: "Randy.Dunlap" <[EMAIL PROTECTED]> Date: Sun, 22 Oct 2006 21:32:20 -0700 David Miller wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Date: Sun, 22 Oct 2006 19:13:09 -0700 From: Randy Dunlap <[EMAIL PROTECTED]> hrz_init() is called from the probe function, which is __devinit and could be called after init. WARNING: drivers/atm/horizon.o - Section mismatch: reference to .init.text:.hrz_init from .text between '.hrz_probe' (at offset 0x4054) and '.hrz_remove_one' Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> It is only called from hrz_init() and thus shouldn't it be thus marked __devinit as well? That seems to be the right way to fix this one. Oops, I agree. Want me to send another patch? No need, I'll take care of it, thanks Randy. David, FYI: read_bia() also needs to be changed from __init to __devinit since it's called from hrz_init(). -- ~Randy - 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: [patch 1/2]d80211: hardware TKIP support for ipw3945
On Mon, 23 Oct 2006 08:29:31 -0700, David Kimdon wrote: > We could be more selective about what the driver is required to return > in ieee80211_tx_status, the rc4key isn't particularily interesting to > ieee80211_tx_status(). I expect there are other uninteresting fields > (tx_rate, rts_cts_rate, come to mind, for example). We could put the > fields we are interested in directly in ieee80211_tx_status, or have a > new structure rather than re-using ieee80211_tx_control inside > ieee80211_tx_status. Something like this? Jiri --- drivers/net/wireless/d80211/adm8211/adm8211.c |7 + include/net/d80211.h | 28 --- net/d80211/ieee80211.c| 98 +- net/d80211/ieee80211_scan.c |4 - net/d80211/ieee80211_sta.c|4 - 5 files changed, 73 insertions(+), 68 deletions(-) --- dscape.orig/drivers/net/wireless/d80211/adm8211/adm8211.c +++ dscape/drivers/net/wireless/d80211/adm8211/adm8211.c @@ -439,7 +439,7 @@ static void adm8211_interrupt_tci(struct pci_unmap_single(priv->pdev, priv->tx_buffers[entry].mapping, priv->tx_buffers[entry].skb->len, PCI_DMA_TODEVICE); - if ((priv->tx_buffers[entry].tx_status.control.flags & + if ((priv->tx_buffers[entry].tx_status.common.flags & IEEE80211_TXCTL_REQ_TX_STATUS) || !is_multicast_ether_addr(ieee80211_get_DA(&priv->tx_buffers[entry].hdr))) { struct ieee80211_hdr *hdr; @@ -1780,7 +1780,8 @@ static void adm8211_tx_raw(struct net_de priv->tx_buffers[entry].skb = skb; priv->tx_buffers[entry].mapping = mapping; - memcpy(&priv->tx_buffers[entry].tx_status.control, control, sizeof(*control)); + memcpy(&priv->tx_buffers[entry].tx_status.common, &control->common, + sizeof(control->common)); memcpy(&priv->tx_buffers[entry].hdr, hdr, sizeof(*hdr)); priv->tx_ring[entry].buffer1 = cpu_to_le32(mapping); @@ -1862,7 +1863,7 @@ static int adm8211_tx(struct net_device if (short_preamble) txhdr->header_control |= cpu_to_le16(ADM8211_TXHDRCTL_SHORT_PREAMBLE); - if (control->flags & IEEE80211_TXCTL_USE_RTS_CTS) + if (control->common.flags & IEEE80211_TXCTL_USE_RTS_CTS) txhdr->header_control |= cpu_to_le16(ADM8211_TXHDRCTL_ENABLE_RTS); if (fc & IEEE80211_FCTL_PROTECTED) --- dscape.orig/include/net/d80211.h +++ dscape/include/net/d80211.h @@ -134,13 +134,7 @@ struct ieee80211_low_level_stats { * the hardware to use given values (depending on what is supported). */ #define HW_KEY_IDX_INVALID -1 -struct ieee80211_tx_control { - enum { PKT_NORMAL = 0, PKT_PROBE_RESP } pkt_type; - int tx_rate; /* Transmit rate, given as the hw specific value for the - * rate (from struct ieee80211_rate) */ - int rts_cts_rate; /* Transmit rate for RTS/CTS frame, given as the hw - * specific value for the rate (from - * struct ieee80211_rate) */ +struct ieee80211_tx_ctrl_common { #define IEEE80211_TXCTL_REQ_TX_STATUS (1<<0)/* request TX status callback for * this frame */ @@ -161,6 +155,20 @@ struct ieee80211_tx_control { * the frame */ u16 flags; /* tx control flags defined * above */ + enum { PKT_NORMAL = 0, PKT_PROBE_RESP } pkt_type; + u8 queue; /* hardware queue to use for this frame; +* 0 = highest, hw->queues-1 = lowest */ + int type; /* internal */ + int ifindex;/* internal */ +}; + +struct ieee80211_tx_control { + struct ieee80211_tx_ctrl_common common; + int tx_rate; /* Transmit rate, given as the hw specific value for the + * rate (from struct ieee80211_rate) */ + int rts_cts_rate; /* Transmit rate for RTS/CTS frame, given as the hw + * specific value for the rate (from + * struct ieee80211_rate) */ u16 rts_cts_duration; /* duration field for RTS/CTS frame */ u8 retry_limit; /* 1 = only first attempt, 2 = one retry, .. */ u8 power_level; /* per-packet transmit power level, in dBm */ @@ -169,8 +177,6 @@ struct ieee80211_tx_control { * hw->set_key() */ u8 icv_len; /* length of the ICV/MIC field in octets */ u8 iv_len; /* length of the IV field in octets */ - u8 queue; /* hardware queue to use for this frame; -* 0 = highest, hw->queues-1 = lowest */ u8 sw_retry_attempt;/* number of times hw has tried to
Re: 2.6.18.1 hangs after resuming from apm suspend
On Monday, 23 October 2006 09:47, Christian stahl wrote: > After upgrading from 2.6.16.20 to 2.6.18.1 my Siemens Scenic > Mobile 750AGP Notebook hangs after resuming from suspend. > > However resuming from suspend works properly if: > > - the prism 2.5 WLAN card is removed before suspending > - the prism 2.5 WLAN is removed after resuming This probably is a regression in the prism driver. Well, it looks like you need to file a bug report at bugzilla.kernel.org. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - 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: [PATCH] bcm43xx-softmac: add PCI-E code
Michael Buesch wrote: Please try 2.6.18.1 or wireless-2.6. 2.6.18.1 (with the PCI-E patch) crashes on modprobe: bcm43xx driver ACPI: PCI Interrupt Link [LK1E] enabled at IRQ 11 ACPI: PCI Interrupt :03:00.0[A] -> Link [LK1E] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device :03:00.0 to 64 bcm43xx: Could not determine Chip ID Unable to handle kernel NULL pointer dereference at 0001 RIP: [] :bcm43xx:bcm43xx_pctl_set_crystal+0x121/0x1a5 PGD 7ae20067 PUD 7d606067 PMD 0 Oops: [1] SMP CPU 0 Modules linked in: bcm43xx ieee80211softmac ieee80211 ieee80211_crypt Pid: 6018, comm: modprobe Not tainted 2.6.181 #1 RIP: 0010:[] [] :bcm43xx:bcm43xx_pctl_set_crystal+0x121/0x1a5 RSP: :8100779cfd08 EFLAGS: 00010246 RAX: RBX: RCX: 810002efefc0 RDX: c238 RSI: 0246 RDI: 804ed780 RBP: 8100783d1178 R08: R09: R10: 0001 R11: 0080 R12: R13: 8100783d R14: 42439001 R15: 0900 FS: 2ae4eb4c7ae0() GS:8059e000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0001 CR3: 788a9000 CR4: 06e0 Process modprobe (pid: 6018, threadinfo 8100779ce000, task 81007d0062c0) Stack: 00c0783d1178 ffed 8100783d1178 4710 880175d6 8100779cfd78 80229f8e 810002fd7800 81007de314c0 80515fa0 0246 Call Trace: [] :bcm43xx:bcm43xx_attach_board+0x120f/0x1284 [] __wake_up+0x38/0x4f [] __queue_work+0x4e/0x5e [] queue_work+0x4e/0x58 [] :bcm43xx:bcm43xx_init_one+0x222/0x270 [] pci_device_probe+0x4c/0x75 [] driver_probe_device+0x52/0xa8 [] __driver_attach+0x6d/0xaa [] __driver_attach+0x0/0xaa [] bus_for_each_dev+0x43/0x6e [] bus_add_driver+0x7e/0x130 [] __pci_register_driver+0x57/0x7d [] sys_init_module+0xab/0x1ae [] system_call+0x7e/0x83 - 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: [PATCH] bcm43xx-softmac: add PCI-E code
On Monday 23 October 2006 15:22, Daniel Drake wrote: > Michael Buesch wrote: > > Please try 2.6.18.1 or wireless-2.6. > > > > > 2.6.18.1 (with the PCI-E patch) crashes on modprobe: > > bcm43xx driver > ACPI: PCI Interrupt Link [LK1E] enabled at IRQ 11 > ACPI: PCI Interrupt :03:00.0[A] -> Link [LK1E] -> GSI 11 (level, > low) -> IRQ 11 > PCI: Setting latency timer of device :03:00.0 to 64 > bcm43xx: Could not determine Chip ID Yeah, try to find out why. I can only repeat myself: No developer has got a PCI-E card. If there are problems, everybody has to find out by himself why it does not work. Try to find out why it can not determine the CHIP-ID. -- 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: [PATCH] bcm43xx-softmac: add PCI-E code
Michael Buesch wrote: Please try 2.6.18.1 or wireless-2.6. wireless-2.6.git has the same problems as the earlier reports on 2.6.19-rc2: ifconfig up,down,up fails, plus it's hard to get connectivity. 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: [PATCH] bcm43xx-softmac: add PCI-E code
Michael Buesch wrote: Yeah, try to find out why. I can only repeat myself: No developer has got a PCI-E card. If there are problems, everybody has to find out by himself why it does not work. Try to find out why it can not determine the CHIP-ID. Any point diagnosing this when this does not happen on 2.6.19-rc? I'm sorry that I can't be more useful. The laptop has to head out of the office later today. I may be able to continue playing with it in a few weeks time. 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: [PATCH] bcm43xx-softmac: add PCI-E code
On Monday 23 October 2006 16:35, Daniel Drake wrote: > Michael Buesch wrote: > > Yeah, try to find out why. > > I can only repeat myself: No developer has got a PCI-E card. > > If there are problems, everybody has to find out by himself why > > it does not work. > > Try to find out why it can not determine the CHIP-ID. > > Any point diagnosing this when this does not happen on 2.6.19-rc? Yes. 2.6.19-rc is still older code than 2.6.18.1. The stuff from 2.6.18.1 (which is the same as wireless-2.6) will be merged into 2.6.19-rc soon. > I'm sorry that I can't be more useful. The laptop has to head out of the > office later today. I may be able to continue playing with it in a few > weeks time. ok. -- 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: [PKT_SCHED] netem: Orphan SKB when adding to queue.
Linux Kernel Mailing List wrote: > commit 4e8a5201506423e0241202de1349422af4260296 > tree e562a6cdbee37e3805551af92b264fa93d722c4b > parent 6a43487f43fbd4e03c606dcb62b98374a3af88fc > author David S. Miller <[EMAIL PROTECTED]> 1161576033 -0700 > committer David S. Miller <[EMAIL PROTECTED]> 1161576033 -0700 > > [PKT_SCHED] netem: Orphan SKB when adding to queue. > > The networking emulator can queue SKBs for a very long > time, so if you're using netem on the sender side for > large bandwidth/delay product testing, the SKB socket > send queue sizes become artificially larger. > > Correct this by calling skb_orphan() in netem_enqueue(). > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > drivers/pci/quirks.c |4 ++-- > net/sched/sch_netem.c |2 ++ > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index e8a7f1b..ecf8e4d 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -1634,7 +1634,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_N > * is marked here since the boot video device will be the only enabled > * video device at this point. > */ > - > +#if 0 > static void __devinit fixup_video(struct pci_dev *pdev) > { > struct pci_dev *bridge; > @@ -1663,7 +1663,7 @@ static void __devinit fixup_video(struct > } > } > DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, fixup_video); > - > +#endif This part looks like you accidentally committed it. - 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 1/3] ethtool: marvell register dump
This is a consolidation of earlier marvell register decode patches to ethtool. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- marvell.c | 106 - 1 files changed, 77 insertions(+), 29 deletions(-) diff --git a/marvell.c b/marvell.c index 244bb69..b73addc 100644 --- a/marvell.c +++ b/marvell.c @@ -88,10 +88,12 @@ static void dump_ram(const char *name, c printf("End Address 0x%08X\n", r[1]); printf("Write Pointer0x%08X\n", r[2]); printf("Read Pointer 0x%08X\n", r[3]); - printf("Upper Threshold/Pause Packets0x%08X\n", r[4]); - printf("Lower Threshold/Pause Packets0x%08X\n", r[5]); - printf("Upper Threshold/High Priority0x%08X\n", r[6]); - printf("Lower Threshold/High Priority0x%08X\n", r[7]); + if (*name == 'R') { + printf("Upper Threshold/Pause Packets0x%08X\n", r[4]); + printf("Lower Threshold/Pause Packets0x%08X\n", r[5]); + printf("Upper Threshold/High Priority0x%08X\n", r[6]); + printf("Lower Threshold/High Priority0x%08X\n", r[7]); + } printf("Packet Counter 0x%08X\n", r[8]); printf("Level0x%08X\n", r[9]); printf("Test 0x%08X\n", r[10]); @@ -113,7 +115,7 @@ static void dump_fifo(const char *name, dump_timer("LED", p + 0x20); } -static void dump_gmac_fifo(const void *p) +static void dump_gmac_fifo(const char *name, const void *p) { const u32 *r = p; int i; @@ -133,6 +135,7 @@ static void dump_gmac_fifo(const void *p "FIFO Read Level", }; + printf("\n%s\n", name); for (i = 0; i < sizeof(regs)/sizeof(regs[0]); ++i) printf("%-32s 0x%08X\n", regs[i], r[i]); @@ -140,6 +143,8 @@ static void dump_gmac_fifo(const void *p static void dump_mac(const u8 *r) { + u8 id; + printf("\nMAC Addresses\n"); printf("---\n"); dump_addr(1, r + 0x100); @@ -147,10 +152,30 @@ static void dump_mac(const u8 *r) dump_addr(3, r + 0x110); printf("\n"); - printf("Connector type 0x%02X\n", r[0x118]); - printf("PMD type 0x%02X\n", r[0x119]); - printf("Configuration0x%02X\n", r[0x11a]); - printf("Chip Revision0x%02X\n", r[0x11b]); + printf("Connector type 0x%02X (%c)\n", + r[0x118], (char)r[0x118]); + printf("PMD type 0x%02X (%c)\n", + r[0x119], (char)r[0x119]); + printf("PHY type 0x%02X\n", r[0x11d]); + + id = r[0x11b]; + printf("Chip Id 0x%02X ", id); + switch (id) { + case 0x0a: puts("Genesis");break; + case 0xb0: puts("Yukon"); break; + case 0xb1: puts("Yukon-Lite"); break; + case 0xb2: puts("Yukon-LP"); break; + case 0xb3: puts("Yukon-2 XL"); break; + case 0xb4: puts("Yukon-2 EC Ultra"); break; + case 0xb6: puts("Yukon-2 EC"); break; + case 0xb7: puts("Yukon-2 FE"); break; + default:puts("Unknown"); + } + + printf(" (rev %d)\n", r[0x11a] & 0xf); + + printf("Ram Buffer 0x%02X\n", r[0x11c]); + } static void dump_gma(const char *name, const u8 *r) @@ -181,21 +206,43 @@ static void dump_gmac(const char *name, dump_gma("Physical", data + 0x28); } +static void dump_pci(const u8 *cfg) +{ + int i; + + printf("\nPCI config\n--\n"); + for(i = 0; i < 0x80; i++) { + if (!(i & 15)) + printf("%02x:", i); + printf(" %02x", cfg[i]); + if ((i & 15) == 15) + putchar('\n'); + } + putchar('\n'); +} + +static void dump_control(u8 *r) +{ + printf("Control Registers\n"); + printf("-\n"); + + printf("Register Access Port 0x%02X\n", *r); + printf("LED Control/Status 0x%08X\n", *(u32 *) (r + 4)); + + printf("Interrupt Source 0x%08X\n", *(u32 *) (r + 8)); + printf("Interrupt Mask 0x%08X\n", *(u32 *) (r + 0xc)); + printf("Interrupt Hardware Error Source 0x%08X\n", *(u32 *) (r + 0x10)); + printf("Interrupt Hardware Error Mask0x%08X\n", *(u32 *) (r + 0x14)); +} + int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs) { const u32 *r = (const u32 *) regs->data; int dual = !(regs->data[0x11a] & 1); - printf("Control Registers\n"); - printf("-\n"); + dump_pci(regs->data + 0x380); - p
Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes
On Fri, 20 Oct 2006, Andy Fleming wrote: > I've been trying to figure out this problem since you posted this, and I'm not > sure I understand it fully (And I apologize profusely for the horror that is > the PHY interrupt handling code. I'd love to rewrite it if there's some First of all I don't see much of the need to use soft timers with an interrupt-driven PHY. Most of the state changes could be invoked straight from phy_change(), perhaps with an exception for the autonegotiation timeout. > cleaner way.). But let me see if I can follow the chain of reasoning that led > to this patch, and see if we can figure out a solution that doesn't involve > creating a work queue just for bringing down the PHY. Avoiding a separate work queue was my intent as well. > 1) Invoking phy_stop is meant to stop the system from looking for PHY status > updates. Currently, another PHY sharing the interrupt can cause the HALTED > PHY to reenable interrupts. Checking for HALTED in the interrupt handler > fixes this, but it's incorrect. The phy_interrupt handler does not grab the > lock, and so you could get this: > > phy_stop > lock > clear any pending interrupts > disable interrupts on this PHY > ---> interrupt from another PHY causes this PHY's interrupt handler to be > invoked > HALTED isn't set, so phy_change is scheduled > <--- set HALTED, unlock > > scheduled work is done: > interrupt is reenabled > > Sadly, I think the only way to fix this problem is to have phy_change check > for HALTED, and react appropriately. Please have a look at how I have rewritten phy_stop() to avoid this problem with no need for a lock -- HALTED is set first and only then interrupts are masked and cleared for this PHY. It can be done without locking because the interrupt handler is strictly a consumer and phy_stop() is strictly a producer and we do not care about any other transitions [1]. > 2) The PHY lib doesn't clear out remaining work in the work queue when it's > bringing down a PHY. This is clearly wrong, but I'm confused how *any* driver > does this? It seems to me that any network driver which has a work queue is > going to be unable to flush the pending work when it is brought down. So > what's the solution to this? The only driver that seems to care is tg3.c and it gets away by other means. Note that network drivers can quite easily handle and ignore deferred interrupt work as long as it arrives before they are removed from memory. All that is required is calling flush_scheduled_work() from their module_exit() call at the very latest. > I'm not too enthusiastic about requiring the ethernet drivers to call > phy_disconnect in a separate thread after "close" is called. Assuming there's > not some sort of "squash work queue" function that can be invoked with > rtnl_lock held, I think phy_disconnect should schedule itself to flush the > queue. This would also require that mdiobus_unregister hold off on freeing > phydevs if any of the phys were still waiting for pending flush_pending calls > to finish. Which would, in turn, require mdiobus_unregister to schedule > cleaning up memory for some later time. This could work, indeed. > I'm not enthusiastic about that implementation, either, but it maintains the > abstractions I consider important for this code. The ethernet driver should > not need to know what structures the PHY lib uses to implement its interrupt > handling, and how to work around their failings, IMHO. Agreed. > >@@ -484,6 +487,9 @@ static irqreturn_t phy_interrupt(int irq > > { > > struct phy_device *phydev = phy_dat; > > > >+if (PHY_HALTED == phydev->state) > >+return IRQ_NONE;/* It can't be ours. */ > >+ > > > As I mentioned, this doesn't protect it, since it doesn't grab the lock. And > it can't grab the lock, or we'd have to disable interrupts while doing phy > transactions. And we can't do that, because one design goal is to allow some > bus drivers to use interrupts to signal that the transaction has completed. > Admittedly, this is still quite broken right now. I'm looking into using > semaphores, on the theory that I can sleep when I grab them. But that would > still prevent taking the semaphore in the interrupt controller. This needs to > be moved to phy_change (which you have done, anyway), and we just have to let > the actual handler figure out whether it's safe to do anything. There is no problem with accessing the state here -- see above[1] and below[2]. > >@@ -577,6 +583,13 @@ int phy_stop_interrupts(struct phy_devic > > if (err) > > phy_error(phydev); > > > >+/* > >+ * Finish any pending work; we might have been scheduled > >+ * to be called from keventd ourselves, though. > >+ */ > >+if (!current_is_keventd()) > >+flush_scheduled_work(); > >+ > > > And this is what is making you move your call to phy_disconnect to a work > queue function, right? Does th
[PATCH 2/3] ethtool: flie option to register dump
Add ability to take old raw dumps from a file and decode them. It is kind of limited because you still need to have same device as the raw file, but useful for maintainers to decode raw dumps. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- ethtool.8 | 13 - ethtool.c | 43 +-- 2 files changed, 49 insertions(+), 7 deletions(-) diff --git a/ethtool.8 b/ethtool.8 index 679f6bc..bffde30 100644 --- a/ethtool.8 +++ b/ethtool.8 @@ -126,6 +126,8 @@ ethtool \- Display or change ethernet ca .B ethtool \-d|\-\-register\-dump .I ethX .B2 raw on off +.RB [ file +.IR name ] .B ethtool \-e|\-\-eeprom\-dump .I ethX @@ -244,7 +246,16 @@ queries the specified ethernet device fo .TP .B \-d \-\-register\-dump retrieves and prints a register dump for the specified ethernet device. -When raw is enabled, then it dumps the raw register data to stdout. +The register format for some devices is known and decoded others +are printed in hex. +When +.I raw +is enabled, then it dumps the raw register data to stdout. +If +.I file +is specified, then use contents of previous raw register dump, rather +than reading from the device. + .TP .B \-e \-\-eeprom\-dump retrieves and prints an EEPROM dump for the specified ethernet device. diff --git a/ethtool.c b/ethtool.c index b783248..f004d54 100644 --- a/ethtool.c +++ b/ethtool.c @@ -29,7 +29,9 @@ #endif #include #include #include +#include #include +#include #include #include #include @@ -150,7 +152,9 @@ static struct option { " [ ufo on|off ]\n" " [ gso on|off ]\n" }, { "-i", "--driver", MODE_GDRV, "Show driver information" }, -{ "-d", "--register-dump", MODE_GREGS, "Do a register dump" }, +{ "-d", "--register-dump", MODE_GREGS, "Do a register dump", + " [ raw on|off ]\n" + " [ file FILENAME ]\n" }, { "-e", "--eeprom-dump", MODE_GEEPROM, "Do a EEPROM dump", " [ raw on|off ]\n" " [ offset N ]\n" @@ -251,6 +255,7 @@ static int msglvl_wanted = -1; static int phys_id_time = 0; static int gregs_changed = 0; static int gregs_dump_raw = 0; +static char *gregs_dump_file = NULL; static int geeprom_changed = 0; static int geeprom_dump_raw = 0; static int geeprom_offset = 0; @@ -268,6 +273,7 @@ typedef enum { CMDL_NONE, CMDL_BOOL, CMDL_INT, + CMDL_STR, } cmdline_type_t; struct cmdline_info { @@ -279,6 +285,7 @@ struct cmdline_info { static struct cmdline_info cmdline_gregs[] = { { "raw", CMDL_BOOL, &gregs_dump_raw, NULL }, + { "file", CMDL_STR, &gregs_dump_file, NULL }, }; static struct cmdline_info cmdline_geeprom[] = { @@ -355,20 +362,28 @@ static void parse_generic_cmdline(int ar if (i >= argc) show_usage(1); p = info[idx].wanted_val; - if (info[idx].type == CMDL_BOOL) { + switch (info[idx].type) { + case CMDL_BOOL: if (!strcmp(argp[i], "on")) *p = 1; else if (!strcmp(argp[i], "off")) *p = 0; else show_usage(1); - } else if (info[idx].type == CMDL_INT) { - long v; - v = strtol(argp[i], NULL, 0); + break; + case CMDL_INT: { + long v = strtol(argp[i], NULL, 0); if (v < 0) show_usage(1); *p = (int) v; - } else { + break; + } + case CMDL_STR: { + char **s = info[idx].wanted_val; + *s = strdup(argp[i]); + break; + } + default: show_usage(1); } } @@ -969,6 +984,22 @@ static int dump_regs(struct ethtool_drvi return 0; } + if (gregs_dump_file) { + FILE *f = fopen(gregs_dump_file, "r"); + struct stat st; + + if (!f || fstat(fileno(f), &st) < 0) { + fprintf(stderr, "Can't open '%s': %s\n", +
[PATCH 3/3] ethtool: allow force hex in register dump
Sometimes the device decode logic just gets in the way so add a "force hex" option to register dump. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- ethtool.8 |1 + ethtool.c | 11 +++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/ethtool.8 b/ethtool.8 index bffde30..d247d51 100644 --- a/ethtool.8 +++ b/ethtool.8 @@ -126,6 +126,7 @@ ethtool \- Display or change ethernet ca .B ethtool \-d|\-\-register\-dump .I ethX .B2 raw on off +.B2 hex on off .RB [ file .IR name ] diff --git a/ethtool.c b/ethtool.c index f004d54..06e3675 100644 --- a/ethtool.c +++ b/ethtool.c @@ -255,6 +255,7 @@ static int msglvl_wanted = -1; static int phys_id_time = 0; static int gregs_changed = 0; static int gregs_dump_raw = 0; +static int gregs_dump_hex = 0; static char *gregs_dump_file = NULL; static int geeprom_changed = 0; static int geeprom_dump_raw = 0; @@ -285,6 +286,7 @@ struct cmdline_info { static struct cmdline_info cmdline_gregs[] = { { "raw", CMDL_BOOL, &gregs_dump_raw, NULL }, + { "hex", CMDL_BOOL, &gregs_dump_hex, NULL }, { "file", CMDL_STR, &gregs_dump_file, NULL }, }; @@ -1000,10 +1002,11 @@ static int dump_regs(struct ethtool_drvi fclose(f); } - for (i = 0; i < ARRAY_SIZE(driver_list); i++) - if (!strncmp(driver_list[i].name, info->driver, -ETHTOOL_BUSINFO_LEN)) - return driver_list[i].func(info, regs); + if (!gregs_dump_hex) + for (i = 0; i < ARRAY_SIZE(driver_list); i++) + if (!strncmp(driver_list[i].name, info->driver, +ETHTOOL_BUSINFO_LEN)) + return driver_list[i].func(info, regs); fprintf(stdout, "Offset\tValues\n"); fprintf(stdout, "\t-"); -- 1.4.2.3 - 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 1/1] r8169: perform a PHY reset before any other operation at boot time
Realtek's 8139/810x (0x8136) PCI-E comes with a touchy PHY. A big heavy reset seems to calm it down. Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7378. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> Signed-off-by: Darren Salt <[EMAIL PROTECTED]> --- drivers/net/r8169.c | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index c2c9a86..03c0dc5 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -1442,6 +1442,22 @@ static void rtl8169_release_board(struct free_netdev(dev); } +static void rtl8169_phy_reset(struct net_device *dev, + struct rtl8169_private *tp) +{ + void __iomem *ioaddr = tp->mmio_addr; + int i; + + tp->phy_reset_enable(ioaddr); + for (i = 0; i < 100; i++) { + if (!tp->phy_reset_pending(ioaddr)) + return; + msleep(1); + } + if (netif_msg_link(tp)) + printk(KERN_ERR "%s: PHY reset failed.\n", dev->name); +} + static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp) { void __iomem *ioaddr = tp->mmio_addr; @@ -1470,6 +1486,8 @@ static void rtl8169_init_phy(struct net_ rtl8169_link_option(board_idx, &autoneg, &speed, &duplex); + rtl8169_phy_reset(dev, tp); + rtl8169_set_speed(dev, autoneg, speed, duplex); if ((RTL_R8(PHYstatus) & TBI_Enable) && netif_msg_link(tp)) -- 1.4.2.3 - 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
[no subject]
subscribe - 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: [PATCH REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)
On Mon, 2006-10-23 at 14:39 +0200, Patrick McHardy wrote: > The implementation may be different, but the intention and the > result is the same. I probably would mind less if it wouldn't > affect userspace compatibility, but we need to carry this stuff > for ever even if we add another implementation that covers all > qdiscs. So where is the overlap? Your patch will make qdiscs that use packet length work with ATM. Ours makes the rest, ie those that use Alexy's RTAB, work with ATM. They would probably both apply with minimal conflicts. You have previously said you have no intention of changing the current RTAB implantation with your STAB patch. As an aside non-work conserving qdisc's that do scheduling are the real targets of ATM patch. The rest are not effected by ATM overly. The only one of those that doesn't use Alexy's RTAB is the one you introduced - HFSC. You are the best person to fix things so HFSC does work with ATM, and that is what I thought you were doing with the STAB patch. > What do I need to explain further? As I stated several times, > I would like to see a patch that handles all qdiscs. And it > should probably not have hardcoded ATM values, there is other > media that behaves similar. I am not aware of other media that behaves in a similar way, although I am no expert. What have I missed? The hard coded ATM values don't effect this patch btw, they are a user space thing only. > >>Besides that: > >> > >>+static inline u32 qdisc_l2t(struct qdisc_rate_table* rtab, int pktlen) > >>+{ > >>+ int slot = pktlen + rtab->rate.cell_align; > >>+ if (slot < 0) > >>+ slot = 0; > >> > >>Why would it go negative? A negative cell_align doesn't make sense I > >>guess. > > > > > > A negative cell align is possible, and in fact is typical. > > If slot ended up being less than 0 then the configuration > > parameters passed to "tc" would of been wrong - they could > > not of matched the actual traffic. The error can't be > > detected in "tc", but it can't be allowed to cause the > > kernel to index off the end of an array either. > > I'm not sure I understand what you're saying here. The transmission > time gets _smaller_ by transmitting over ATM? Does this have anything > to do with the off-by-one during rate table calculation you or > Jesper noticed? There is nothing I would describe as an "off-by-one error" in the RTAB calculation, so I can't be sure what you are referring to. The packetisation done by ATM does introduce rounding / truncation errors of up to ((1 << cell_log) - 1). Negative cell alignments is the easiest way to fix that. > >>+ slot >>= rtab->rate.cell_log; > >>+ if (slot > 255) > >>+ return rtab->data[255] + 1; > >> > >>Whats the point of this? Is it just to keep htb giant statistics > >>working? > > > > > > Yes. > > TBF and policers already make sure this can never happen, this is > what HTB should do as well. If it is also needed for CBQ it is > a bugfix and should be done seperately. OK. I will change it. - 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
[RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
The following patches extend 802.11 regulatory domain support of the d80211 wireless stack through two modules: 1. ieee80211_regdomains 2. iso3166-1 These modules provide an interface for management of regulatory domains. Stack support has not been completed as it requires changes which should be discussed here first. The hopes of extending regulatory domains is so we have a consistant method by which all drivers access valid channels and power restrictions which strictly adhere to local regulatory domain constraints. Additionally if in-kernel support of regulatory domains suffices for regulatory agencies this should clear vendors from supporting FOSS wireless drivers as this is the most common excuse not to so. --- Details: 1. ieee80211_regdomains Breaks down regulatory domains into data structures which allow drivers to share channel and power contraints based on stack regulatory domain. This driver adds in-kernel support for common regulatory domains (such as FCC and ETSI), makes updating the regulatory domain database through userspace completely optional which should make it easier to introduce, and adds support for PtMP (Point to MultiPoint) and PtP (Point to Point) type restrictions. 2. iso3166-1 ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names of countries and dependent areas. It was first published in 1974 by the International Organization for Standardization (ISO) and defines three different codes for each area: * ISO 3166-1 alpha-2, a two-letter system with many applications, most notably the Internet top-level domains (ccTLD) for countries. * ISO 3166-1 alpha-3, a three-letter system. * ISO 3166-1 numeric, a three-digit numerical system, which is identical to that defined by the United Nations Statistical Division. Although this would usually be only used in userspace IEEE-802.11d has made use of ISO-3166-1 alpha 3. This mapping was added to enhance stack support for IEEE-802.11d and 802.11 Regulatory Domain control. ieee80211_regdomains makes use of this module by creating a map of iso3166 alpha3 country code to stack regulatory domain. -- Things which need review: Current regulatory domain support is provided statically in ieee80211_ioctl.c through ieee80211_regdom module parameter. This is used to mask channels for scanning through ieee80211_init_client(), which gets called during ieee80211_update_hw() which itself gets called in ieee80211_register_hw(). Note that d80211.h also introduces an unsigned int regulatory_domain in ieee80211_conf struct, this however is never used even by current drivers or stack code. The current setup on d80211.h makes regulatory domains device specific. I believe this should be changed to be stack-specific -- that is, all drivers adhere to the restrictions set by the stack's current regulatory domain. To enforce this though we'd need some central stack-specific structure with stack-speficic settings. Are there other parameters which can be stack-specific and configurable which can be used to introduce a new structure which defines how the stack behaves at a certain point in time? Should we take this approach ieee80211_ioctl.c can then just query the stack regulatory domain instead of a module_param. Comments and patches are more than welcomed. Certain regulatory domains are still being ironed out. Luis - 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/3] adds iso3166-1 support
iso3166-1 ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names of countries and dependent areas. It was first published in 1974 by the International Organization for Standardization (ISO) and defines three different codes for each area: * ISO 3166-1 alpha-2, a two-letter system with many applications, most notably the Internet top-level domains (ccTLD) for countries. * ISO 3166-1 alpha-3, a three-letter system. * ISO 3166-1 numeric, a three-digit numerical system, which is identical to that defined by the United Nations Statistical Division. Although this would usually be only used in userspace IEEE-802.11d has made use of ISO-3166-1 alpha 3. This mapping was added to enhance stack support for IEEE-802.11d and 802.11 Regulatory Domain control. ieee80211_regdomains makes use of this module by creating a map of iso3166 alpha3 country code to stack regulatory domain. diff -Naurp wireless-dev-old/include/net/d80211_iso3166-1.h wireless-dev/include/net/d80211_iso3166-1.h --- wireless-dev-old/include/net/d80211_iso3166-1.h 1969-12-31 19:00:00.0 -0500 +++ wireless-dev/include/net/d80211_iso3166-1.h 2006-10-23 14:36:20.0 -0400 @@ -0,0 +1,65 @@ +#ifndef _ISO3166_1_H +#define _ISO3166_1_H +/* + * Copyright (C) 2006 Luis R. Rodriguez <[EMAIL PROTECTED]> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +/* + * ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names + * of countries and dependent areas. It was first published in 1974 by + * the International Organization for Standardization (ISO) and defines three + * different codes for each area: + * + * * ISO 3166-1 alpha-2, a two-letter system with many applications, + * most notably the Internet top-level domains (ccTLD) for countries. + * * ISO 3166-1 alpha-3, a three-letter system. + * * ISO 3166-1 numeric, a three-digit numerical system, which is + * identical to that defined by the United Nations Statistical Division. + * + * Although this would usually be only used in userspace IEEE-802.11d + * has made use of ISO-3166-1 alpha 3. This mapping was added + * to enhance stack support for IEEE-802.11d and 802.11 Regulatory + * Domain control. + * + */ + +#include + +#define ISO3166_1_VERSION "2006-09-18" +#define ISOCOUNTRYSIZ2 2 +#define ISOCOUNTRYSIZ3 3 +#define ISOCOUNTRYSIZ 50 + +struct iso3166_1_map { + /* ISO-3166-1 numeric */ + u16 numeric; + /* ISO-3166-1 alpha 2 */ + char alpha2[ISOCOUNTRYSIZ2]; + /* ISO-3166-1 alpha 3 */ + char alpha3[ISOCOUNTRYSIZ3]; + /* Country name */ + char country[ISOCOUNTRYSIZ]; + struct list_head list; +}; + +u16 get_iso3166_1_numeric(char *); +char * get_iso3166_1_alpha2(char *); +char * get_iso3166_1_alpha3(int); +char * get_iso3166_1_country(char *); +u16 iso3166_1_exists(char *); + +#endif diff -Naurp wireless-dev-old/net/d80211/iso3166-1.c wireless-dev/net/d80211/iso3166-1.c --- wireless-dev-old/net/d80211/iso3166-1.c 1969-12-31 19:00:00.0 -0500 +++ wireless-dev/net/d80211/iso3166-1.c 2006-10-23 16:13:09.0 -0400 @@ -0,0 +1,626 @@ +/* + * Copyright (C) 2006 Luis R. Rodriguez <[EMAIL PROTECTED]> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include + +#define DRV_NAME"iso3166_1" +#define DRV_DESCRIPTION "ISO 3166-1 support" +#define DRV_VERSION ISO3166_1_VERSION + +MODULE_AUTHOR("Luis R. Rodriguez <[EMAIL PROTECTED]>"); +MODULE_LICENSE("Dual BSD/GPL"); +MODULE_DESCRIPTION(DRV_DESCRIPTION); +MODULE_VERSION(DRV_VERSION); + +LIST_HEAD(iso3166_1_list); + +static inline void setup_iso3166_1_node(struct iso3166_1_map *, u16, + char *, char *, char *); +static void unload_iso3166_1(void); +s
Re: [RFC] [PATCH 3/3] Kconfig update for regulatory domain
These are the current Kconfig changes needed to introduce ieee80211_regdomains to d80211. Each in-kernel regulatory domain is made available as optional. Each country which currently complies to each regulatory domain is listed on the help menu for each available regulatory domain. The mapping between regulatory domains and iso3166-1 alpha3 country code are kept within ieee80211_regdomains. Luis diff -Naurp wireless-dev-old/net/d80211/Kconfig wireless-dev/net/d80211/Kconfig --- wireless-dev-old/net/d80211/Kconfig 2006-10-23 13:56:11.0 -0400 +++ wireless-dev/net/d80211/Kconfig 2006-10-23 17:04:12.0 -0400 @@ -7,6 +7,80 @@ config D80211 This option enables the hardware independent IEEE 802.11 networking stack. +comment "IEEE80211 - Regulatory Domain Support" + +config D80211_REGDOMAIN_ETSI + bool "ETSI Regulatory Domain" + depends on D80211 + ---help--- + This option enables ETSI regulatory domain support to be + built into the kernel. If you live in any of the following countries + you want this: + + * Denmark + * Estonia + * Finland + * Germany + * Iceland + * Ireland + * Italy + * Lithuania + * Luxembourg + * Netherlands + * Norway + * Poland + * Portugal + * Slovenia + * South Africa + * Sweden + * United Kingdom + * France + * Spain + +config D80211_REGDOMAIN_FCC + bool "FCC Regulatory Domain" + depends on D80211 + ---help--- + This option enables FCC regulatory domain support to be + built into the kernel. If you live in any of the following countries + you want this: + + * United States + * Colombia + * Dominican Republic + * Guatemala + * Mexico + * Panama + * Puerto Rico + +config D80211_REGDOMAIN_IC + bool "IC Regulatory Domain" + depends on D80211 + ---help--- + This option enables IC regulatory domain support to be + built into the kernel. If you live in any of the following countries + you want this: + + * Canada + +config D80211_REGDOMAIN_MKK + bool "MKK Regulatory Domain" + depends on D80211 + ---help--- + This option enables MKK regulatory domain support to be + built into the kernel. If you live in any of the following countries + you want this: + + * Japan +comment "" + +#config D80211_REGULATORY_USER +# bool "Regulatory domain userspace support" +# depends on D80211 +# ---help--- +# This option enables updating of regulatory domain database +# through userspace. + config D80211_LEDS bool "Enable LED triggers" depends on D80211 @@ -16,8 +90,6 @@ config D80211_LEDS This option enables a few LED triggers for different packet receive/transmit events. -config D80211_ - config D80211_DEBUG bool "Enable debugging output" depends on D80211
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Mon, 2006-10-23 at 18:41 -0400, Luis R. Rodriguez wrote: > The current setup on d80211.h makes regulatory domains device > specific. I believe this should be changed to be stack-specific -- > that is, all drivers adhere to the restrictions set by the stack's > current regulatory domain. There should be a way to have a certain device restrict that even further, if the driver wants to allow operation only in a domain that the device has been certified for (because it may malfunction otherwise, for example). I'll probably have more comments later, really tired now though. johannes signature.asc Description: This is a digitally signed message part
RFC: Removing busy-spin in pktgen.
I'm planning to re-merge my long-lost pktgen branch with the kernel tree's pktgen. I believe the main difference is that my out-of-tree pktgen does not do the busy-spin, but waits on a queue for the net-device to wake it's tx-queue when over-driving a NIC. To implement this, I added a hook in the netdev-wake-queue logic and let pktgen register itself as interested Is there any interest in adding this sort of feature to the official pktgen? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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
How to grab a block of binary data w/out using ioctls?
Since IOCTLs are out of favor these days, what would be a preferred way to get a block of binary data out of the kernel? I just want to grab a stats structure (well-aligned 32 and 64-bit counters and fixed-length strings) for a pktgen interface. Can you do this with seq-files somehow? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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 3/3] Kconfig update for regulatory domain
This last chunk is broken: . . . Hunk #2 FAILED at 90. > --- wireless-dev-old/net/d80211/Kconfig 2006-10-23 13:56:11.0 > -0400 > +++ wireless-dev/net/d80211/Kconfig 2006-10-23 17:04:12.0 -0400 > @@ -16,8 +90,6 @@ config D80211_LEDS > This option enables a few LED triggers for different > packet receive/transmit events. > > -config D80211_ > - > config D80211_DEBUG > bool "Enable debugging output" > depends on D80211 - 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: How to grab a block of binary data w/out using ioctls?
On Mon, 23 Oct 2006 17:44:24 -0700 Ben Greear wrote: > Since IOCTLs are out of favor these days, what would be > a preferred way to get a block of binary data out of the > kernel? > > I just want to grab a stats structure (well-aligned 32 and 64-bit counters > and fixed-length strings) for a pktgen interface. > > Can you do this with seq-files somehow? seq-files just use printk() for text output. Not well-suited to binary output. Similarly, sysfs is desirable in some circumstances, but not for blocks of binary data. ioctls or netlink or debugfs or relay output (see how blktrace uses relay output) are your choices (I may have missed some. :) ioctls can be OK for some purposes. If you want to avoid them, try debugfs or relay. (I haven't looked at debugfs very much; it may be more text-oriented also...) --- ~Randy - 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: [PKT_SCHED] netem: Orphan SKB when adding to queue.
On Mon, 23 Oct 2006 19:08:17 +0200 Patrick McHardy wrote: > Linux Kernel Mailing List wrote: > > commit 4e8a5201506423e0241202de1349422af4260296 > > tree e562a6cdbee37e3805551af92b264fa93d722c4b > > parent 6a43487f43fbd4e03c606dcb62b98374a3af88fc > > author David S. Miller <[EMAIL PROTECTED]> 1161576033 -0700 > > committer David S. Miller <[EMAIL PROTECTED]> 1161576033 -0700 > > > > [PKT_SCHED] netem: Orphan SKB when adding to queue. > > > > The networking emulator can queue SKBs for a very long > > time, so if you're using netem on the sender side for > > large bandwidth/delay product testing, the SKB socket > > send queue sizes become artificially larger. > > > > Correct this by calling skb_orphan() in netem_enqueue(). > > > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > > > drivers/pci/quirks.c |4 ++-- > > net/sched/sch_netem.c |2 ++ > > 2 files changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > > index e8a7f1b..ecf8e4d 100644 > > --- a/drivers/pci/quirks.c > > +++ b/drivers/pci/quirks.c > > @@ -1634,7 +1634,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_N > > * is marked here since the boot video device will be the only enabled > > * video device at this point. > > */ > > - > > +#if 0 > > static void __devinit fixup_video(struct pci_dev *pdev) > > { > > struct pci_dev *bridge; > > @@ -1663,7 +1663,7 @@ static void __devinit fixup_video(struct > > } > > } > > DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, fixup_video); > > - > > +#endif > > > This part looks like you accidentally committed it. yep, already noticed & corrected on lkml. --- ~Randy - 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: How to grab a block of binary data w/out using ioctls?
On Mon, Oct 23, 2006 at 09:54:48PM -0700, Randy Dunlap wrote: > Similarly, sysfs is desirable in some circumstances, but > not for blocks of binary data. sysfs specifically has APIs for binary data... 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
Re: How to grab a block of binary data w/out using ioctls?
Jeff Garzik wrote: On Mon, Oct 23, 2006 at 09:54:48PM -0700, Randy Dunlap wrote: Similarly, sysfs is desirable in some circumstances, but not for blocks of binary data. sysfs specifically has APIs for binary data... Ack that, sorry about that. -- ~Randy - 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 3/3] Kconfig update for regulatory domain
On 10/23/06, David Kimdon <[EMAIL PROTECTED]> wrote: This last chunk is broken: . . . Hunk #2 FAILED at 90. You can ignore this hunk. > --- wireless-dev-old/net/d80211/Kconfig 2006-10-23 13:56:11.0 -0400 > +++ wireless-dev/net/d80211/Kconfig 2006-10-23 17:04:12.0 -0400 > @@ -16,8 +90,6 @@ config D80211_LEDS > This option enables a few LED triggers for different > packet receive/transmit events. > > -config D80211_ > - > config D80211_DEBUG > bool "Enable debugging output" > depends on D80211 - 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 0/3] Add Regulatory Domain support to d80211
On 10/23/06, Johannes Berg <[EMAIL PROTECTED]> wrote: On Mon, 2006-10-23 at 18:41 -0400, Luis R. Rodriguez wrote: > The current setup on d80211.h makes regulatory domains device > specific. I believe this should be changed to be stack-specific -- > that is, all drivers adhere to the restrictions set by the stack's > current regulatory domain. There should be a way to have a certain device restrict that even further, if the driver wants to allow operation only in a domain that the device has been certified for (because it may malfunction otherwise, for example). Sure good idea -- we can provide a device specific regulatory domain if necessary. We can easily introduce a device_regdomains linked list on the ieee80211_conf which if not empty the driver will use it, else the stack regdomain is used. The ieee80211_regdomains module already provides the interfaces for the manipulation of such list. Pretty easy fix, fortunately. I'll probably have more comments later, really tired now though. Great, thanks. Luis - 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] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
From: Holden Karau <[EMAIL PROTECTED]> http://www.holdenkarau.com I have made a small patch for the zd1211rw driver which uses the boundry channels of the regulatory domain, rather than the hard coded values of 1 & 11. Signed-off-by: Holden Karau <[EMAIL PROTECTED]> http://www.holdenkarau.com --- I'm not entirely sure how useful this patch is, but it seems like a good idea. If its totally misguided, let me know :-) In case the patch gets mangled I've put it up at http://www.holdenkarau.com/~holden/projects/zd1211rw/zd1211rw-use-geo-for-channels.patch And now for the patch: --- a/drivers/net/wireless/zd1211rw/zd_chip.c 2006-10-23 10:07:39.0 -0400 +++ b/drivers/net/wireless/zd1211rw/zd_chip.c 2006-10-23 10:41:51.0 -0400 @@ -38,6 +38,8 @@ void zd_chip_init(struct zd_chip *chip, mutex_init(&chip->mutex); zd_usb_init(&chip->usb, netdev, intf); zd_rf_init(&chip->rf); + /* The chip needs to know which geo it is in */ + chip->geo = ieee80211_get_geo(zd_mac_to_ieee80211(zd_netdev_mac(netdev))); } void zd_chip_clear(struct zd_chip *chip) @@ -606,14 +608,17 @@ static int patch_6m_band_edge(struct zd_ { CR128, 0x14 }, { CR129, 0x12 }, { CR130, 0x10 }, { CR47, 0x1e }, }; + struct ieee80211_geo *geo = chip->geo; if (!chip->patch_6m_band_edge || !chip->rf.patch_6m_band_edge) return 0; - /* FIXME: Channel 11 is not the edge for all regulatory domains. */ - if (channel == 1 || channel == 11) + /* Checks the channel boundry of the region */ + dev_dbg_f("checking boundry == %d || %d\n" , 1 , geo->bg_channels); + if (channel == 1 || channel == geo->bg_channels) ioreqs[0].value = 0x12; + dev_dbg_f(zd_chip_dev(chip), "patching for channel %d\n", channel); return zd_iowrite16a_locked(chip, ioreqs, ARRAY_SIZE(ioreqs)); } --- a/drivers/net/wireless/zd1211rw/zd_chip.h 2006-10-23 10:07:39.0 -0400 +++ b/drivers/net/wireless/zd1211rw/zd_chip.h 2006-10-23 10:39:08.0 -0400 @@ -21,6 +21,8 @@ #include "zd_types.h" #include "zd_rf.h" #include "zd_usb.h" +#include "zd_ieee80211.h" +#include /* Header for the Media Access Controller (MAC) and the Baseband Processor * (BBP). It appears that the ZD1211 wraps the old ZD1205 with USB glue and @@ -669,6 +671,7 @@ struct zd_chip { /* SetPointOFDM in the vendor driver */ u8 ofdm_cal_values[3][E2P_CHANNEL_COUNT]; u16 link_led; + struct ieee80211_geo* geo; unsigned int pa_type:4, patch_cck_gain:1, patch_cr157:1, patch_6m_band_edge:1, new_phy_layout:1, - 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 5/5] netpoll: interface cleanup
Trivial cleanup of netpoll interface. Use constants for size, to make usage clear. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- netpoll.orig/include/linux/netpoll.h +++ netpoll/include/linux/netpoll.h @@ -12,15 +12,14 @@ #include #include -struct netpoll; - struct netpoll { struct net_device *dev; - char dev_name[16], *name; + char dev_name[IFNAMSIZ]; + const char *name; void (*rx_hook)(struct netpoll *, int, char *, int); u32 local_ip, remote_ip; u16 local_port, remote_port; - unsigned char local_mac[6], remote_mac[6]; + u8 local_mac[ETH_ALEN], remote_mac[ETH_ALEN]; }; struct netpoll_info { - 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 2/5] netpoll: cleanup queued transmit
This patch changes the queued transmit path of netpoll, to use similar logic to the non-queued path. We don't want netpoll messages going into NIT and network qdisc logic. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- netpoll.orig/net/core/netpoll.c +++ netpoll/net/core/netpoll.c @@ -51,13 +51,27 @@ static atomic_t trapped; static void zap_completion_queue(void); static void arp_reply(struct sk_buff *skb); +static void queue_process(void *); +static DECLARE_WORK(send_queue, queue_process, NULL); + static void queue_process(void *p) { struct sk_buff *skb; - while ((skb = skb_dequeue(&netpoll_txq))) - dev_queue_xmit(skb); + while ((skb = skb_dequeue(&netpoll_txq))) { + struct net_device *dev = skb->dev; + netif_tx_lock_bh(dev); + if (netif_queue_stopped(dev) || + dev->hard_start_xmit(skb, dev) != NETDEV_TX_OK) { + skb_queue_head(&netpoll_txq, skb); + netif_tx_unlock_bh(dev); + + schedule_delayed_work(&send_queue, 1); + return; + } + netif_tx_unlock_bh(dev); + } } static void queue_purge(struct net_device *dev) @@ -77,8 +91,6 @@ static void queue_purge(struct net_devic spin_unlock_irqrestore(&netpoll_txq.lock, flags); } -static DECLARE_WORK(send_queue, queue_process, NULL); - void netpoll_queue(struct sk_buff *skb) { skb_queue_tail(&netpoll_txq, skb); - 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 3/5] netpoll: cleanup transmit retry logic
Change netpoll transmit logic so: * retries are per attempt not global. don't want to start drop packets just because of temporary blockage. * acquire xmit_lock correctly * if device is not available just drop * always queue if send fails, don't drop Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- netpoll.orig/include/linux/netpoll.h +++ netpoll/include/linux/netpoll.h @@ -27,7 +27,6 @@ struct netpoll { struct netpoll_info { spinlock_t poll_lock; int poll_owner; - int tries; int rx_flags; spinlock_t rx_lock; struct netpoll *rx_np; /* netpoll that registered an rx_hook */ --- netpoll.orig/net/core/netpoll.c +++ netpoll/net/core/netpoll.c @@ -250,50 +250,42 @@ static struct sk_buff * find_skb(struct static void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb) { - int status; - struct netpoll_info *npinfo; - - if (!np || !np->dev || !netif_running(np->dev)) - goto free_skb; + struct net_device *dev = np->dev; + int tries = MAX_RETRIES; - npinfo = np->dev->npinfo; + do { + int status; - /* avoid recursion */ - if (npinfo->poll_owner == smp_processor_id() || - np->dev->xmit_lock_owner == smp_processor_id()) { - if (np->drop) - np->drop(skb); - else + /* if device is offline, give up */ + if (!netif_running(dev) || !netif_device_present(dev)) { __kfree_skb(skb); - return; - } + return; + } - do { - npinfo->tries--; - netif_tx_lock(np->dev); + /* grap tx lock, but avoid recursion problems */ + if (!netif_tx_trylock(dev)) + break; + + /* drivers do not expect to be called if queue is stopped. */ + if (netif_queue_stopped(dev)) + status = NETDEV_TX_BUSY; + else + status = dev->hard_start_xmit(skb, dev); + netif_tx_unlock(dev); - /* -* network drivers do not expect to be called if the queue is -* stopped. -*/ - status = NETDEV_TX_BUSY; - if (!netif_queue_stopped(np->dev)) - status = np->dev->hard_start_xmit(skb, np->dev); - - netif_tx_unlock(np->dev); - - /* success */ - if(!status) { - npinfo->tries = MAX_RETRIES; /* reset */ + /* succesfull send */ + if (status == NETDEV_TX_OK) return; - } - /* transmit busy */ + /* transmit busy, maybe cleaning up will help */ netpoll_poll(np); udelay(50); - } while (npinfo->tries > 0); -free_skb: - __kfree_skb(skb); + } while (--tries > 0); + + if (np->drop) + np->drop(skb); + else + __kfree_skb(skb); } void netpoll_send_udp(struct netpoll *np, const char *msg, int len) @@ -646,7 +638,7 @@ int netpoll_setup(struct netpoll *np) npinfo->rx_np = NULL; spin_lock_init(&npinfo->poll_lock); npinfo->poll_owner = -1; - npinfo->tries = MAX_RETRIES; + spin_lock_init(&npinfo->rx_lock); skb_queue_head_init(&npinfo->arp_tx); } else - 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 4/5] netpoll: move drop hook inline
Rather than have separate drop callback hook, just put the logic inline in netpoll. The code is cleaner and netconsole is the only user of netpoll. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- netpoll.orig/drivers/net/netconsole.c +++ netpoll/drivers/net/netconsole.c @@ -60,7 +60,6 @@ static struct netpoll np = { .local_port = 6665, .remote_port = , .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}, - .drop = netpoll_queue, }; static int configured = 0; --- netpoll.orig/include/linux/netpoll.h +++ netpoll/include/linux/netpoll.h @@ -18,7 +18,6 @@ struct netpoll { struct net_device *dev; char dev_name[16], *name; void (*rx_hook)(struct netpoll *, int, char *, int); - void (*drop)(struct sk_buff *skb); u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; --- netpoll.orig/net/core/netpoll.c +++ netpoll/net/core/netpoll.c @@ -91,13 +91,6 @@ static void queue_purge(struct net_devic spin_unlock_irqrestore(&netpoll_txq.lock, flags); } -void netpoll_queue(struct sk_buff *skb) -{ - skb_queue_tail(&netpoll_txq, skb); - - schedule_work(&send_queue); -} - static int checksum_udp(struct sk_buff *skb, struct udphdr *uh, unsigned short ulen, u32 saddr, u32 daddr) { @@ -282,10 +275,10 @@ static void netpoll_send_skb(struct netp udelay(50); } while (--tries > 0); - if (np->drop) - np->drop(skb); - else - __kfree_skb(skb); + /* if transmitter is busy, try send later. */ + skb_queue_tail(&netpoll_txq, skb); + + schedule_work(&send_queue); } void netpoll_send_udp(struct netpoll *np, const char *msg, int len) @@ -784,4 +777,3 @@ EXPORT_SYMBOL(netpoll_setup); EXPORT_SYMBOL(netpoll_cleanup); EXPORT_SYMBOL(netpoll_send_udp); EXPORT_SYMBOL(netpoll_poll); -EXPORT_SYMBOL(netpoll_queue); - 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 1/5] netpoll: use sk_buff_head for txq
This is the 3rd version of the netpoll patches. The first patch switches from open-coded skb list to using a skb_buff_head. It also flushes packets from queue when device is removed from netpoll. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- netpoll.orig/net/core/netpoll.c +++ netpoll/net/core/netpoll.c @@ -37,10 +37,7 @@ #define MAX_RETRIES 2 static struct sk_buff_head netpoll_pool; - -static DEFINE_SPINLOCK(queue_lock); -static int queue_depth; -static struct sk_buff *queue_head, *queue_tail; +static struct sk_buff_head netpoll_txq; static atomic_t trapped; @@ -56,44 +53,35 @@ static void arp_reply(struct sk_buff *sk static void queue_process(void *p) { - unsigned long flags; struct sk_buff *skb; - while (queue_head) { - spin_lock_irqsave(&queue_lock, flags); - - skb = queue_head; - queue_head = skb->next; - if (skb == queue_tail) - queue_head = NULL; + while ((skb = skb_dequeue(&netpoll_txq))) + dev_queue_xmit(skb); - queue_depth--; +} - spin_unlock_irqrestore(&queue_lock, flags); +static void queue_purge(struct net_device *dev) +{ + struct sk_buff *skb, *next; + unsigned long flags; - dev_queue_xmit(skb); + spin_lock_irqsave(&netpoll_txq.lock, flags); + for (skb = (struct sk_buff *)netpoll_txq.next; +skb != (struct sk_buff *)&netpoll_txq; skb = next) { + next = skb->next; + if (skb->dev == dev) { + skb_unlink(skb, &netpoll_txq); + kfree_skb(skb); + } } + spin_unlock_irqrestore(&netpoll_txq.lock, flags); } static DECLARE_WORK(send_queue, queue_process, NULL); void netpoll_queue(struct sk_buff *skb) { - unsigned long flags; - - if (queue_depth == MAX_QUEUE_DEPTH) { - __kfree_skb(skb); - return; - } - - spin_lock_irqsave(&queue_lock, flags); - if (!queue_head) - queue_head = skb; - else - queue_tail->next = skb; - queue_tail = skb; - queue_depth++; - spin_unlock_irqrestore(&queue_lock, flags); + skb_queue_tail(&netpoll_txq, skb); schedule_work(&send_queue); } @@ -745,6 +733,7 @@ int netpoll_setup(struct netpoll *np) } static int __init netpoll_init(void) { + skb_queue_head_init(&netpoll_txq); skb_queue_head_init(&netpoll_pool); return 0; } @@ -752,20 +741,22 @@ core_initcall(netpoll_init); void netpoll_cleanup(struct netpoll *np) { - struct netpoll_info *npinfo; + struct net_device *dev = np->dev; unsigned long flags; - if (np->dev) { - npinfo = np->dev->npinfo; + if (dev) { + struct netpoll_info *npinfo = dev->npinfo; + if (npinfo && npinfo->rx_np == np) { spin_lock_irqsave(&npinfo->rx_lock, flags); npinfo->rx_np = NULL; npinfo->rx_flags &= ~NETPOLL_RX_ENABLED; spin_unlock_irqrestore(&npinfo->rx_lock, flags); } - dev_put(np->dev); - } + dev_put(dev); + queue_purge(dev); + } np->dev = NULL; } - 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: [PATCH] sky2: 88E803X transmit lockup
Stephen Hemminger wrote: The reason sky2 driver was locking up on transmit on the Yukon-FE chipset is that it was misconfiguring the internal RAM buffer so the transmitter and receiver were sharing the same space. The code assumed there was 16K of RAM on Yukon-FE (taken from vendor driver sk98lin which is even more f*cked up on this). Then it assigned based on that. The giveaway was that the registers would only hold 9bits so both RX/TX had 0..1ff for space. It is a wonder it worked at all! This patch addresses this, and fixes an easily reproducible hang on Transmit. Only the Yukon-FE chip is Marvell 88E803X (10/100 only) are affected. [snip] This patch works great - without it, I get only a few minutes of use from my home dir over NFS4 before the NIC stops transmitting. This is on a recent Yonah Sony VGN-SZ notebook w/ 88E8036 Marvel Sk-Y2. Thanks again Stephen! -- Daniel J Blueman - 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: [PATCH 1/5] netpoll: use sk_buff_head for txq
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Mon, 23 Oct 2006 12:02:53 -0700 > + spin_lock_irqsave(&netpoll_txq.lock, flags); > + for (skb = (struct sk_buff *)netpoll_txq.next; > + skb != (struct sk_buff *)&netpoll_txq; skb = next) { > + next = skb->next; > + if (skb->dev == dev) { > + skb_unlink(skb, &netpoll_txq); > + kfree_skb(skb); > + } > } > + spin_unlock_irqrestore(&netpoll_txq.lock, flags); IRQ's are disabled, I think we can't call kfree_skb() in such a context. That's why zap_completion_queue() has all of these funny skb->destructor checks and such, all of this stuff potentially runs in IRQ context. - 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: [PATCH] bcm43xx-softmac: add PCI-E code
Michael Buesch wrote: Yes. 2.6.19-rc is still older code than 2.6.18.1. The stuff from 2.6.18.1 (which is the same as wireless-2.6) will be merged into 2.6.19-rc soon. 2.6.18.1 produced the oops in the earlier mail wireless-2.6 did *not* produce the oops, instead I get the behavior of plain 2.6.19-rc2 plus PCI-E patch (i.e. _almost_ works) 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: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
Holden Karau wrote: From: Holden Karau <[EMAIL PROTECTED]> http://www.holdenkarau.com I have made a small patch for the zd1211rw driver which uses the boundry channels of the regulatory domain, rather than the hard coded values of 1 & 11. Signed-off-by: Holden Karau <[EMAIL PROTECTED]> http://www.holdenkarau.com Thanks for the patch! Please always look up the MAINTAINERS entry for the code you are modifying and CC the developers on patches. Comments below, all minor points. I'm not entirely sure how useful this patch is, but it seems like a good idea. If its totally misguided, let me know :-) In case the patch gets mangled I've put it up at http://www.holdenkarau.com/~holden/projects/zd1211rw/zd1211rw-use-geo-for-channels.patch Your mailer ate tabs and wrapped long lines. You're going to need to fix that. --- a/drivers/net/wireless/zd1211rw/zd_chip.c2006-10-23 10:07:39.0 -0400 +++ b/drivers/net/wireless/zd1211rw/zd_chip.c2006-10-23 10:41:51.0 -0400 @@ -38,6 +38,8 @@ void zd_chip_init(struct zd_chip *chip, mutex_init(&chip->mutex); zd_usb_init(&chip->usb, netdev, intf); zd_rf_init(&chip->rf); +/* The chip needs to know which geo it is in */ +chip->geo = ieee80211_get_geo(zd_mac_to_ieee80211(zd_netdev_mac(netdev))); There is no need to store a geo reference here. You can use zd_chip_to_mac() to go from chip to mac, then mac-to-ieee80211 is easy. } void zd_chip_clear(struct zd_chip *chip) @@ -606,14 +608,17 @@ static int patch_6m_band_edge(struct zd_ { CR128, 0x14 }, { CR129, 0x12 }, { CR130, 0x10 }, { CR47, 0x1e }, }; +struct ieee80211_geo *geo = chip->geo; if (!chip->patch_6m_band_edge || !chip->rf.patch_6m_band_edge) return 0; -/* FIXME: Channel 11 is not the edge for all regulatory domains. */ -if (channel == 1 || channel == 11) +/* Checks the channel boundry of the region */ +dev_dbg_f("checking boundry == %d || %d\n" , 1 , geo->bg_channels); +if (channel == 1 || channel == geo->bg_channels) Typo, you mean boundary. Also, I think the debug message can go once you're confident it's working correctly. ioreqs[0].value = 0x12; + This added line could go as well. dev_dbg_f(zd_chip_dev(chip), "patching for channel %d\n", channel); return zd_iowrite16a_locked(chip, ioreqs, ARRAY_SIZE(ioreqs)); } I think that after the above changes, your modifications to zd_chip.h can be removed. --- a/drivers/net/wireless/zd1211rw/zd_chip.h2006-10-23 10:07:39.0 -0400 +++ b/drivers/net/wireless/zd1211rw/zd_chip.h2006-10-23 10:39:08.0 -0400 @@ -21,6 +21,8 @@ #include "zd_types.h" #include "zd_rf.h" #include "zd_usb.h" +#include "zd_ieee80211.h" +#include /* Header for the Media Access Controller (MAC) and the Baseband Processor * (BBP). It appears that the ZD1211 wraps the old ZD1205 with USB glue and @@ -669,6 +671,7 @@ struct zd_chip { /* SetPointOFDM in the vendor driver */ u8 ofdm_cal_values[3][E2P_CHANNEL_COUNT]; u16 link_led; + struct ieee80211_geo* geo; unsigned int pa_type:4, patch_cck_gain:1, patch_cr157:1, patch_6m_band_edge:1, new_phy_layout:1, - 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