[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 linux/crypto.h
+#include linux/err.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/rtnetlink.h
+#include linux/slab.h
+#include linux/scatterlist.h
+#include internal.h
+
+u_int32_t ks[12] = {0x01010101, 0x01010101, 0x01010101, 0x01010101,
+ 0x02020202, 0x02020202, 0x02020202, 0x02020202,
+ 0x03030303, 0x03030303, 0x03030303, 0x03030303};
+/*
+ * +
+ * | parent tfm
+ * +
+ * | 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);
+}
+
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 ~{PmVHI~} [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,11 @@ typedef union
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 (10)/* 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
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
[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);
- printf(Register Access Port 0x%08X\n, r[0]);
- printf(LED Control/Status 0x%08X\n,
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 this make it so phy_stop_interrupts (and anything
that calls it) can't be called with rtnl_lock held?
[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 sys/types.h
#include string.h
#include stdlib.h
+#include sys/types.h
#include sys/ioctl.h
+#include sys/stat.h
#include stdio.h
#include string.h
#include errno.h
@@ -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) {
+
[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 linux/list.h
+
+#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 linux/module.h
+#include net/d80211_iso3166-1.h
+
+#define DRV_NAMEiso3166_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 *);
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 linux/wireless.h
/* 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 linux/rcupdate.h
#include linux/list.h
-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] 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 linux/wireless.h
/* 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
