Re: [PATCH] NET : change layout of ehash table
David Miller [EMAIL PROTECTED] writes: I've applied this, but I _REALLY_ don't like the new multiply instructions that are used now in the hash indexing paths when CONFIG_SMP is set. I think that's a higher cost than the memory waste. You're serious? multiply on a modern CPU is _much_ cheaper than a cache miss e.g. a K8 can do a arbitary 64bit multiplication in 3-7 cycles. Any cache miss will be in the three to four digits at least. -Andi - 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][IPSEC][4/6] changing ipip tunnel and xfrm4_tunnel to the API change
Kazunori MIYAZAWA wrote: Thank you Patrick for your review. I'll fix and send again. Thanks. BTW, I'm going to use separete xfrm_tunnel_handler to solve the issue which you pointed at the moment. But why does register twice corrupt the list even if I use separate lists for the address family. The next pointer in xfrm_tunnel_handler will get overwritten on the second registration. - 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] NET : change layout of ehash table
From: Andi Kleen [EMAIL PROTECTED] Date: 09 Feb 2007 10:18:03 +0100 David Miller [EMAIL PROTECTED] writes: I've applied this, but I _REALLY_ don't like the new multiply instructions that are used now in the hash indexing paths when CONFIG_SMP is set. I think that's a higher cost than the memory waste. You're serious? multiply on a modern CPU is _much_ cheaper than a cache miss e.g. a K8 can do a arbitary 64bit multiplication in 3-7 cycles. Any cache miss will be in the three to four digits at least. I'm not thinking of modern CPUs, I'm think of the little guys :-) - 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] NET : change layout of ehash table
On Friday 09 February 2007 09:40, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: 09 Feb 2007 10:18:03 +0100 David Miller [EMAIL PROTECTED] writes: I've applied this, but I _REALLY_ don't like the new multiply instructions that are used now in the hash indexing paths when CONFIG_SMP is set. I think that's a higher cost than the memory waste. You're serious? multiply on a modern CPU is _much_ cheaper than a cache miss e.g. a K8 can do a arbitary 64bit multiplication in 3-7 cycles. Any cache miss will be in the three to four digits at least. I'm not thinking of modern CPUs, I'm think of the little guys :-) Even for them it's true, although the ratios are smaller (unless you go back to m68000 or VAX days) -Andi - 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] NET : change layout of ehash table
On Friday 09 February 2007 09:40, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: 09 Feb 2007 10:18:03 +0100 David Miller [EMAIL PROTECTED] writes: I've applied this, but I _REALLY_ don't like the new multiply instructions that are used now in the hash indexing paths when CONFIG_SMP is set. I think that's a higher cost than the memory waste. You're serious? multiply on a modern CPU is _much_ cheaper than a cache miss e.g. a K8 can do a arbitary 64bit multiplication in 3-7 cycles. Any cache miss will be in the three to four digits at least. I'm not thinking of modern CPUs, I'm think of the little guys :-) Yes, but a decent C compiler for such targets should not use a multiply instruction to perform a (idx * 12) operation... :) - 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] NET : change layout of ehash table
From: Eric Dumazet [EMAIL PROTECTED] Date: Fri, 9 Feb 2007 10:06:24 +0100 Yes, but a decent C compiler for such targets should not use a multiply instruction to perform a (idx * 12) operation... :) Good point. Actually, I could never get GCC to avoid a divide on sparc64 for certain kinds of pointer arithmetic when the elements were not a power of two. It probably has something to do with signedness. I think I narrowed is down to the fact that you can't legally replace a signed divide with shift/add/subtract. But I could be remembering things wrong. - 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] NET : change layout of ehash table
On Friday 09 February 2007 10:15, David Miller wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Fri, 9 Feb 2007 10:06:24 +0100
Yes, but a decent C compiler for such targets should not use a
multiply instruction to perform a (idx * 12) operation... :)
Good point.
Actually, I could never get GCC to avoid a divide on sparc64 for
certain kinds of pointer arithmetic when the elements were not
a power of two. It probably has something to do with signedness.
I think I narrowed is down to the fact that you can't legally replace
a signed divide with shift/add/subtract. But I could be remembering
things wrong.
Thats strange, because pointer arithmetic is unsigned...
I dont know when gcc started to use reciprocal division, maybe your gcc was
very old ?
$ cat div.c
struct s1 {int pad[3];};
unsigned long diffptr(struct s1 *a, struct s1 *b)
{
return a - b;
}
If compiled on i386 , gcc-4.1.1 :
$ gcc -O2 -fomit-frame-pointer -S div.c
diffptr:
movl4(%esp), %eax
subl8(%esp), %eax
sarl$2, %eax
imull $-1431655765, %eax, %eax
ret
If compiled on x86_64 , gcc-4.1.1:
diffptr:
subq%rsi, %rdi
movabsq $-6148914691236517205, %rax
sarq$2, %rdi
imulq %rax, %rdi
movq%rdi, %rax
ret
-
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] NET : change layout of ehash table
From: Eric Dumazet [EMAIL PROTECTED] Date: Fri, 9 Feb 2007 10:36:58 +0100 Thats strange, because pointer arithmetic is unsigned... I dont know when gcc started to use reciprocal division, maybe your gcc was very old ? Yep, it was only on older gcc's. And as the sparc gcc backend co-maintainer, I remember what the problem was. The insn costs for multiply and divide were not set properly on UltraSPARC, so it used the defaults, which made gcc think divides were very cheap :-) Current gcc does the right thing, even for weird sizes like 56 and 52 which expands to many IALU operations. - 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] NET : change layout of ehash table
On Friday 09 February 2007 10:43, David Miller wrote: Current gcc does the right thing, even for weird sizes like 56 and 52 which expands to many IALU operations. ... except if you use -Os, which at least on x86* is default and is what distros ship with. -Andi - 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/5] [RFC] AF_RXRPC socket family implementation
In article [EMAIL PROTECTED] (at Fri, 09 Feb 2007 10:31:34 +), David
Howells [EMAIL PROTECTED] says:
YOSHIFUJI Hideaki [EMAIL PROTECTED] wrote:
This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
sure to align on 64-bit word.
That won't work. That would then make the address larger than the maximum
size (ie: sizeof(struct sockaddr_storage)).
sockaddr{}, then...
--yoshfuji
-
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] Add PCBC crypto template support
Herbert Xu [EMAIL PROTECTED] wrote: This is already in the crypto-2.6 tree that I pushed yesterday. Thanks. However, I'll continue to include the patches in my set until they reach Linus's tree. 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 0/5] [RFC] AF_RXRPC socket family implementation
YOSHIFUJI Hideaki [EMAIL PROTECTED] wrote:
and make it sure to align on 64-bit word.
The first part of sockaddr_rxrpc is exactly 64 bits; then comes the transport
address, so that's okay.
This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
Please use sockaddr_storage{} (or sockaddr{}, maybe),
Why can't I include sockaddr_in and sockaddr_in6 in sockaddr_rxrpc, btw?
That won't work. That would then make the address larger than the maximum
size (ie: sizeof(struct sockaddr_storage)).
sockaddr{}, then...
But that's not big enough to hold a sockaddr_in6...
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 0/5] [RFC] AF_RXRPC socket family implementation
In article [EMAIL PROTECTED] (at Fri, 09 Feb 2007 12:31:23 +), David
Howells [EMAIL PROTECTED] says:
YOSHIFUJI Hideaki [EMAIL PROTECTED] wrote:
and make it sure to align on 64-bit word.
The first part of sockaddr_rxrpc is exactly 64 bits; then comes the transport
address, so that's okay.
This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
Please use sockaddr_storage{} (or sockaddr{}, maybe),
Why can't I include sockaddr_in and sockaddr_in6 in sockaddr_rxrpc, btw?
Because it is protocol (such as ipv4 or ipv6) dependent.
You cannot use different sturcture for one address family.
You could use union, maybe.
That won't work. That would then make the address larger than the maximum
size (ie: sizeof(struct sockaddr_storage)).
sockaddr{}, then...
But that's not big enough to hold a sockaddr_in6...
struct sockaddr_rxrpc {
...
union {
struct sockaddr rxrpc_sa;
struct sockaddr_in rxrpc_sin;
struct sockaddr_in6 rxrpc_sin6;
} __attribute__((__aligned(8)__));
};
Another option would be to introduce new transport protocol such as
dccp or sctp, no?
--yoshfuji
-
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] ucc_geth: Change private immrbar_virt_to_phys to generic iopa
Li Yang-r58472 wrote: No, we don't know if the BD ring is in MURAM or main memory as it is configurable. iopa() is best choice to handle both case, IMHO. The above code would only be used if the BD is in MURAM. The if bd_mem_part == MEM_PART_MURAM would stay. If the BD ring can be in main memory, then I don't think we should be using a function called iopa to get its physical address. It's conceivable that one day, iopa() will only work on memory that's been ioremap'ed. - 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 0/2] NetXen: 1G/10G Ethernet Driver updates
Hi All, I will be sending NetXen: 1G/10G Ethernet Driver updates with respect to netdev #upstream in the subsequent emails. Thanks, --Amit ~ - 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/2] NetXen: Fixes for ppc architecture.
NetXen: Fixes for ppc architecture.
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
---
netxen_nic_hw.c |2 ++
netxen_nic_init.c |4 ++--
netxen_nic_main.c |3 ++-
netxen_nic_niu.c |2 +-
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index f263232..7195af3 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -420,6 +420,7 @@ static int netxen_get_flash_block(struct
for (i = 0; i size / sizeof(u32); i++) {
if (netxen_rom_fast_read(adapter, addr, ptr32) == -1)
return -1;
+ *ptr32 = cpu_to_le32(*ptr32);
ptr32++;
addr += sizeof(u32);
}
@@ -428,6 +429,7 @@ static int netxen_get_flash_block(struct
if (netxen_rom_fast_read(adapter, addr, local) == -1)
return -1;
+ local = cpu_to_le32(local);
memcpy(ptr32, local, (char *)buf + size - (char *)ptr32);
}
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index f7bb8c9..c243c16 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -1246,7 +1246,7 @@ int netxen_process_cmd_ring(unsigned lon
* the netdev which is associated with that device.
*/
- consumer = *(adapter-cmd_consumer);
+ consumer = le32_to_cpu(*(adapter-cmd_consumer));
if (last_consumer == consumer) {/* Ring is empty*/
DPRINTK(INFO, last_consumer %d == consumer %d\n,
last_consumer, consumer);
@@ -1340,7 +1340,7 @@ int netxen_process_cmd_ring(unsigned lon
if (adapter-last_cmd_consumer == consumer
(((adapter-cmd_producer + 1) %
adapter-max_tx_desc_count) == adapter-last_cmd_consumer)) {
- consumer = *(adapter-cmd_consumer);
+ consumer = le32_to_cpu(*(adapter-cmd_consumer));
}
done = (adapter-last_cmd_consumer == consumer);
diff --git a/drivers/net/netxen/netxen_nic_main.c
b/drivers/net/netxen/netxen_nic_main.c
index 69c1b9d..c2da7ec 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -434,12 +434,13 @@ #endif
adapter-port_count++;
adapter-port[i] = port;
}
-
+#ifndef CONFIG_PPC64
writel(0, NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
netxen_pinit_from_rom(adapter, 0);
udelay(500);
netxen_load_firmware(adapter);
netxen_phantom_init(adapter, NETXEN_NIC_PEG_TUNE);
+#endif
/*
* delay a while to ensure that the Pegs are up running.
* Otherwise, we might see some flaky behaviour.
diff --git a/drivers/net/netxen/netxen_nic_niu.c
b/drivers/net/netxen/netxen_nic_niu.c
index 40d7003..d5d9507 100644
--- a/drivers/net/netxen/netxen_nic_niu.c
+++ b/drivers/net/netxen/netxen_nic_niu.c
@@ -458,7 +458,7 @@ int netxen_niu_gbe_init_port(struct netx
int netxen_niu_xg_init_port(struct netxen_adapter *adapter, int port)
{
- long reg = 0, ret = 0;
+ u32 reg = 0, ret = 0;
if (adapter-ahw.boardcfg.board_type ==
NETXEN_BRDTYPE_P2_SB31_10G_IMEZ) {
netxen_crb_writelit_adapter(adapter,
-
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/5] [RFC] AF_RXRPC socket family implementation
YOSHIFUJI Hideaki [EMAIL PROTECTED] wrote:
Because it is protocol (such as ipv4 or ipv6) dependent.
Hmmm... I had thought of RxRPC being very transport dependent, being rather
tied to UDPv4, though probably simply extensible to UDPv6. However, as long
as the transport-layer header is removed on received packets before the main
part of the code sees them, there shouldn't be any problem supporting non-UDP
protocols, apart from, possibly, network error (ICMP) handling.
Some of the AFS operations, however, only deal in IPv4 addresses. I believe
there is work afoot to deal with this, but I as far as I know it hasn't been
dealt with yet.
Currently RxRPC is *only* available over UDPv4 in OpenAFS as far as I know.
You cannot use different sturcture for one address family.
You could use union, maybe.
I am using a union:
struct sockaddr_rxrpc {
sa_family_t srx_family;
u16 srx_service;
u16 transport_type;
u16 transport_len;
union {
sa_family_t family;
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
} transport;
};
I can add the alignment restrictor to the union though.
Another option would be to introduce new transport protocol such as
dccp or sctp, no?
It's not my choice. My code must interoperate with the other RxRPC/AFS
implementations that are already out there and have been around for many
years.
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
[PATCH 2/2] NetXen: Updates for ethtool support
NetXen: Updates for ethtool support.
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
---
netxen_nic.h |1 +
netxen_nic_ethtool.c |9 +
netxen_nic_init.c|8
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 3f3896e..e021a30 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -1040,6 +1040,7 @@ int netxen_flash_unlock(struct netxen_ad
int netxen_backup_crbinit(struct netxen_adapter *adapter);
int netxen_flash_erase_secondary(struct netxen_adapter *adapter);
int netxen_flash_erase_primary(struct netxen_adapter *adapter);
+void netxen_halt_pegs(struct netxen_adapter *adapter);
int netxen_rom_fast_write(struct netxen_adapter *adapter, int addr, int data);
int netxen_rom_se(struct netxen_adapter *adapter, int addr);
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index cc0efe2..6252e9a 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -402,7 +402,7 @@ netxen_nic_get_wol(struct net_device *de
wol-wolopts = 0;
}
-static u32 netxen_nic_get_link(struct net_device *dev)
+static u32 netxen_nic_test_link(struct net_device *dev)
{
struct netxen_port *port = netdev_priv(dev);
struct netxen_adapter *adapter = port-adapter;
@@ -459,6 +459,7 @@ netxen_nic_set_eeprom(struct net_device
int ret;
if (flash_start == 0) {
+ netxen_halt_pegs(adapter);
ret = netxen_flash_unlock(adapter);
if (ret 0) {
printk(KERN_ERR %s: Flash unlock failed.\n,
@@ -712,7 +713,7 @@ netxen_nic_diag_test(struct net_device *
{
if (eth_test-flags == ETH_TEST_FL_OFFLINE) { /* offline tests */
/* link test */
- if (!(data[4] = (u64) netxen_nic_get_link(dev)))
+ if (!(data[4] = (u64) netxen_nic_test_link(dev)))
eth_test-flags |= ETH_TEST_FL_FAILED;
if (netif_running(dev))
@@ -727,7 +728,7 @@ netxen_nic_diag_test(struct net_device *
dev-open(dev);
} else {/* online tests */
/* link test */
- if (!(data[4] = (u64) netxen_nic_get_link(dev)))
+ if (!(data[4] = (u64) netxen_nic_test_link(dev)))
eth_test-flags |= ETH_TEST_FL_FAILED;
/* other tests pass by default */
@@ -783,7 +784,7 @@ struct ethtool_ops netxen_nic_ethtool_op
.get_regs_len = netxen_nic_get_regs_len,
.get_regs = netxen_nic_get_regs,
.get_wol = netxen_nic_get_wol,
- .get_link = netxen_nic_get_link,
+ .get_link = ethtool_op_get_link,
.get_eeprom_len = netxen_nic_get_eeprom_len,
.get_eeprom = netxen_nic_get_eeprom,
.set_eeprom = netxen_nic_set_eeprom,
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index c243c16..2f32436 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -717,6 +717,14 @@ netxen_flash_erase_primary(struct netxen
return ret;
}
+void netxen_halt_pegs(struct netxen_adapter *adapter)
+{
+netxen_crb_writelit_adapter(adapter, NETXEN_CRB_PEG_NET_0 + 0x3c, 1);
+netxen_crb_writelit_adapter(adapter, NETXEN_CRB_PEG_NET_1 + 0x3c, 1);
+netxen_crb_writelit_adapter(adapter, NETXEN_CRB_PEG_NET_2 + 0x3c, 1);
+netxen_crb_writelit_adapter(adapter, NETXEN_CRB_PEG_NET_3 + 0x3c, 1);
+}
+
int netxen_flash_unlock(struct netxen_adapter *adapter)
{
int ret = 0;
-
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
[NET]: Fix whitespace errors
Hello. Please pull 2.6.20-net-2.6-20070209-whitespace branch at git://git.linux-ipv6.org/gitroot/yoshfuji/linux-2.6-dev.git to fix trivial whitespace errors: - convert leading sequences of whitespace with tab(s). - remove whitespace at the end of line. under net. Tree is on top of current net-2.6 tree. Here is the diffstat. --- net/802/fc.c | 24 - net/802/fddi.c | 26 + net/802/hippi.c| 20 - net/802/psnap.c|2 net/802/tr.c | 136 +++-- net/8021q/vlan.c | 52 +- net/8021q/vlan.h | 12 net/8021q/vlan_dev.c | 42 +- net/8021q/vlanproc.c | 36 + net/appletalk/aarp.c | 14 - net/appletalk/atalk_proc.c |2 net/appletalk/ddp.c| 218 net/appletalk/dev.c|8 net/atm/atm_sysfs.c| 14 - net/atm/br2684.c |4 net/atm/common.c | 34 + net/atm/common.h |2 net/atm/ioctl.c|2 net/atm/lec.c | 20 - net/atm/lec.h |4 net/atm/mpc.c | 130 +++-- net/atm/mpc.h | 44 +- net/atm/mpoa_caches.c |4 net/atm/mpoa_caches.h | 98 ++-- net/atm/mpoa_proc.c| 88 ++- net/atm/proc.c | 58 +- net/atm/pvc.c |4 net/atm/raw.c |6 net/atm/resources.c| 16 - net/atm/signaling.h|4 net/atm/svc.c | 48 +- net/ax25/af_ax25.c | 114 ++-- net/ax25/ax25_addr.c |6 net/ax25/ax25_ip.c | 94 ++-- net/ax25/ax25_route.c |8 net/ax25/ax25_std_timer.c |2 net/ax25/ax25_subr.c |4 net/ax25/ax25_uid.c|2 net/bluetooth/af_bluetooth.c | 16 - net/bluetooth/bnep/bnep.h | 18 - net/bluetooth/bnep/core.c | 52 +- net/bluetooth/bnep/netdev.c| 34 + net/bluetooth/bnep/sock.c | 26 + net/bluetooth/cmtp/capi.c | 14 - net/bluetooth/cmtp/cmtp.h | 12 net/bluetooth/cmtp/core.c | 14 - net/bluetooth/cmtp/sock.c | 14 - net/bluetooth/hci_conn.c | 20 - net/bluetooth/hci_core.c | 36 + net/bluetooth/hci_event.c | 26 + net/bluetooth/hci_sock.c | 28 + net/bluetooth/hidp/core.c | 14 - net/bluetooth/hidp/hidp.h | 12 net/bluetooth/hidp/sock.c | 14 - net/bluetooth/l2cap.c | 26 + net/bluetooth/lib.c| 12 net/bluetooth/rfcomm/core.c| 56 +- net/bluetooth/rfcomm/sock.c| 20 - net/bluetooth/rfcomm/tty.c | 46 +- net/bluetooth/sco.c| 30 + net/bridge/br_device.c |8 net/bridge/br_fdb.c| 34 + net/bridge/br_forward.c|4 net/bridge/br_if.c | 26 + net/bridge/br_input.c |4 net/bridge/br_ioctl.c | 18 - net/bridge/br_netfilter.c | 14 - net/bridge/br_notify.c | 10 net/bridge/br_private.h|4 net/bridge/br_stp.c| 24 - net/bridge/br_stp_bpdu.c |2 net/bridge/br_stp_if.c |4 net/bridge/br_stp_timer.c | 20 - net/bridge/br_sysfs_br.c |8 net/bridge/netfilter/ebt_802_3.c |6 net/bridge/netfilter/ebt_among.c |6 net/bridge/netfilter
Re: [NET]: Fix whitespace errors
On Feb 9, 2007, at 8:41 AM, YOSHIFUJI Hideaki / 吉藤英明 wrote: Hello. Please pull 2.6.20-net-2.6-20070209-whitespace branch at git://git.linux-ipv6.org/gitroot/yoshfuji/linux-2.6-dev.git to fix trivial whitespace errors: - convert leading sequences of whitespace with tab(s). - remove whitespace at the end of line. under net. Tree is on top of current net-2.6 tree. Do you have a script that did this? And is this type of cleanup something that is desired? I noticed a asm/powerpc header that had whitespace issues and was going to commit a patch, but figured I should than cleanup all the headers. I wasn't sure if cleaning up whitespace issues wholesale like this was desirable or not. - k- 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: [NET]: Fix whitespace errors
Hello.
In article [EMAIL PROTECTED] (at Fri, 9 Feb 2007 09:47:27 -0600), Kumar Gala
[EMAIL PROTECTED] says:
to fix trivial whitespace errors:
- convert leading sequences of whitespace with tab(s).
- remove whitespace at the end of line.
under net.
Tree is on top of current net-2.6 tree.
Do you have a script that did this?
-8-
#!/bin/sh
TEMP=$(mktemp -t spacecheck.XX)
unexpand $1 | sed -e 's/[[:space:]][[:space:]]*$//' ${TEMP}
cat ${TEMP} $1
rm ${TEMP}
-8-
Then, git-reset and git-commit.
--yoshfuji
-
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] ucc_geth: Change private immrbar_virt_to_phys to generic iopa
Dan Malek wrote: On Feb 8, 2007, at 8:35 AM, Timur Tabi wrote: That's what the original code did, kinda. It called virt_to_phys() if it is main memory, and it called immrbar_virt_to_phys() if it is MURAM. immrbar_virt_to_phys() did pointer math to extract the physical address. You've got to be kidding. You created yet another function to determine the physical address from a virtual one! LOL! Plus, you need logic in the code to first determine which one to call? Everyone is OK with this? The whole point behind the patch that we posted a couple days ago is to get rid of this function. The patch replaced it with a call to iopa(), but Kumar nack'd that. -- Timur Tabi Linux Kernel Developer @ Freescale - 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] ucc_geth: Change private immrbar_virt_to_phys to generic iopa
On Feb 8, 2007, at 8:35 AM, Timur Tabi wrote: That's what the original code did, kinda. It called virt_to_phys() if it is main memory, and it called immrbar_virt_to_phys() if it is MURAM. immrbar_virt_to_phys() did pointer math to extract the physical address. You've got to be kidding. You created yet another function to determine the physical address from a virtual one! LOL! Plus, you need logic in the code to first determine which one to call? Everyone is OK with this? -- Dan - 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] NET : UDP can use sk_hash to speedup lookups
In a prior patch, I introduced a sk_hash field (__sk_common.skc_hash) to let
tcp lookups use one cache line per unmatched entry instead of two.
We can also use sk_hash to speedup UDP part as well. We store in sk_hash the
hnum value, and use sk-sk_hash (same cache line than 'next' pointer),
instead of inet-num (different cache line)
Note : We still have a false sharing problem for SMP machines, because
sock_hold(sock) dirties the cache line containing the 'next' pointer. Not
counting the udp_hash_lock rwlock. (did someone mentioned RCU ? :) )
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
--- linux-2.6.20/net/ipv4/udp.c 2007-02-09 19:17:28.0 +0100
+++ linux-2.6.20-ed/net/ipv4/udp.c 2007-02-09 19:21:07.0 +0100
@@ -120,7 +120,7 @@ static inline int __udp_lib_lport_inuse(
struct hlist_node *node;
sk_for_each(sk, node, udptable[num (UDP_HTABLE_SIZE - 1)])
- if (inet_sk(sk)-num == num)
+ if (sk-sk_hash == num)
return 1;
return 0;
}
@@ -191,7 +191,7 @@ gotit:
head = udptable[snum (UDP_HTABLE_SIZE - 1)];
sk_for_each(sk2, node, head)
- if (inet_sk(sk2)-num == snum
+ if (sk2-sk_hash == snum
sk2 != sk
(!sk2-sk_reuse|| !sk-sk_reuse)
(!sk2-sk_bound_dev_if || !sk-sk_bound_dev_if
@@ -200,6 +200,7 @@ gotit:
goto fail;
}
inet_sk(sk)-num = snum;
+ sk-sk_hash = snum;
if (sk_unhashed(sk)) {
head = udptable[snum (UDP_HTABLE_SIZE - 1)];
sk_add_node(sk, head);
@@ -247,7 +248,7 @@ static struct sock *__udp4_lib_lookup(__
sk_for_each(sk, node, udptable[hnum (UDP_HTABLE_SIZE - 1)]) {
struct inet_sock *inet = inet_sk(sk);
- if (inet-num == hnum !ipv6_only_sock(sk)) {
+ if (sk-sk_hash == hnum !ipv6_only_sock(sk)) {
int score = (sk-sk_family == PF_INET ? 1 : 0);
if (inet-rcv_saddr) {
if (inet-rcv_saddr != daddr)
@@ -296,7 +297,7 @@ static inline struct sock *udp_v4_mcast_
sk_for_each_from(s, node) {
struct inet_sock *inet = inet_sk(s);
- if (inet-num != hnum ||
+ if (s-sk_hash != hnum ||
(inet-daddr inet-daddr != rmt_addr)||
(inet-dport != rmt_port inet-dport)||
(inet-rcv_saddr inet-rcv_saddr != loc_addr)||
--- linux-2.6.20/net/ipv6/udp.c 2007-02-09 19:17:28.0 +0100
+++ linux-2.6.20-ed/net/ipv6/udp.c 2007-02-09 19:17:28.0 +0100
@@ -71,7 +71,7 @@ static struct sock *__udp6_lib_lookup(st
sk_for_each(sk, node, udptable[hnum (UDP_HTABLE_SIZE - 1)]) {
struct inet_sock *inet = inet_sk(sk);
- if (inet-num == hnum sk-sk_family == PF_INET6) {
+ if (sk-sk_hash == hnum sk-sk_family == PF_INET6) {
struct ipv6_pinfo *np = inet6_sk(sk);
int score = 0;
if (inet-dport) {
@@ -309,7 +309,7 @@ static struct sock *udp_v6_mcast_next(st
sk_for_each_from(s, node) {
struct inet_sock *inet = inet_sk(s);
- if (inet-num == num s-sk_family == PF_INET6) {
+ if (s-sk_hash == num s-sk_family == PF_INET6) {
struct ipv6_pinfo *np = inet6_sk(s);
if (inet-dport) {
if (inet-dport != rmt_port)
Re: [Bugme-new] [Bug 7962] New: oops in port_carrier_check
On Fri, 9 Feb 2007 08:42:11 +0100
Jarek Poplawski [EMAIL PROTECTED] wrote:
On 07-02-2007 23:09, Stephen Hemminger wrote:
On Wed, 7 Feb 2007 12:52:16 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
...
Feb 7 21:20:18 plop kernel: BUG: unable to handle kernel paging request at
virtual address 6b6b6b6b
Feb 7 21:20:18 plop kernel: printing eip:
Feb 7 21:20:18 plop kernel: *pde =
Feb 7 21:20:18 plop kernel: Oops: [#1]
Feb 7 21:20:18 plop kernel: CPU:0
Feb 7 21:20:19 plop kernel: EIP:0060:[pg0+814360305/1067136000]Not
tainted VLI
Feb 7 21:20:19 plop kernel: EIP:0060:[f0eed6f1]Not tainted VLI
Feb 7 21:20:19 plop kernel: EFLAGS: 00010202 (2.6.20.0.rc7-1mdv #1)
Feb 7 21:20:19 plop kernel: EIP is at port_carrier_check+0x22/0x75
[bridge]
Feb 7 21:20:19 plop kernel: eax: 6b6b6b6b ebx: 6b6b6b6b ecx:
I think it's caused by pending delayed workqueue
trying to use dev after kfree (POISON_FREE in eax, ebx).
static void port_carrier_check(struct work_struct *work)
{
struct net_bridge_port *p;
struct net_device *dev;
struct net_bridge *br;
dev = container_of(work, struct net_bridge_port,
carrier_check.work)-dev;
work_release(work);
rtnl_lock();
p = dev-br_port;
if (!p)
goto done;
br = p-br;
if (netif_carrier_ok(dev))
p-path_cost = port_cost(dev);
if (br-dev-flags IFF_UP) {
My investigation seems to point at this line (p == ebx
but not NULL because of mem debugging on, probably).
The carrier_check is canceled by removal of port from bridge.
Perhaps there is something broken in rcu assumptions under Qemu
-
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] phy devices: use same arg types
On Feb 5, 2007, at 12:44, Randy Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
sparse complains about differing types from prototype to
definition, so change the u32 to phy_interface_t:
drivers/net/phy/phy_device.c:140:19: error: symbol 'phy_connect'
redeclared with different type (originally declared at include/
linux/phy.h:362) - incompatible argument 5 (different signedness)
drivers/net/phy/phy_device.c:190:19: error: symbol 'phy_attach'
redeclared with different type (originally declared at include/
linux/phy.h:360) - incompatible argument 4 (different signedness)
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
Acked-by: Andy Fleming [EMAIL PROTECTED]
Oops, I thought I had fixed that before submission.
---
drivers/net/phy/phy_device.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2620-pv.orig/drivers/net/phy/phy_device.c
+++ linux-2620-pv/drivers/net/phy/phy_device.c
@@ -139,7 +139,7 @@ void phy_prepare_link(struct phy_device
*/
struct phy_device * phy_connect(struct net_device *dev, const char
*phy_id,
void (*handler)(struct net_device *), u32 flags,
- u32 interface)
+ phy_interface_t interface)
{
struct phy_device *phydev;
@@ -188,7 +188,7 @@ static int phy_compare_id(struct device
}
struct phy_device *phy_attach(struct net_device *dev,
- const char *phy_id, u32 flags, u32 interface)
+ const char *phy_id, u32 flags, phy_interface_t interface)
{
struct bus_type *bus = mdio_bus_type;
struct phy_device *phydev;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7962] New: oops in port_carrier_check
2007/2/9, Stephen Hemminger [EMAIL PROTECTED]: The carrier_check is canceled by removal of port from bridge. Perhaps there is something broken in rcu assumptions under Qemu If that can help: I started /stopped qemu several times. Maybe I started /stopped qemu several times as I was testing new PXE support in qemu with different virtual nic. Each time, a tun device was created by qemu at startup and added to the bridge, and destroyed on exit. - 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/7] [S390]: Introduction of AF_IUCV sockets support
On Thu, Feb 08, 2007 at 02:00:22PM -0800, David Miller wrote: From: Frank Pavlic [EMAIL PROTECTED] Date: Fri, 2 Feb 2007 13:05:28 +0100 The patch set consists of following patches: [1/7] [S390]: Rewrite of the IUCV base code, part 1 [2/7] [S390]: Rewrite of the IUCV base code, part 2 [3/7] [S390]: Adapt monreader driver to new IUCV API [4/7] [S390]: Adapt vmlogrdr driver to new IUCV API [5/7] [S390]: Adapt netiucv driver to new IUCV API [6/7] [S390]: Adapt special message interface to new IUCV API [7/7] [S390]: Add AF_IUCV socket support I've applied all of this, although some of the driver conversions (notable, patches #5 and #6) didn't apply cleanly so I applied them by hand. Thanks for this , I figured that out today by myself and started to make a new set of patches. You saved me a lot of time and work once again ;-) Watch out for any fallout from this when Linus pulls these changes in. Thanks. I'll do so ... - 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: 2.6.20 crash in tcp_tso_segment()
Mike Accetta [EMAIL PROTECTED] wrote:
Obviously the code believes it can assume that there are always multiple
sk_buff's in the chain. The stack trace seems to implicate iptables in
the scenario (twice) if that means anything. Any ideas about what may
be going wrong here? There is indeed a private module loaded at the time
but it does no networking and I doubt it is the culprit.
Yeah we should never get here if we only have one segment.
Could you get it to print out the value of skb-gso_*?
Thanks,
--
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
Please pull upstream branch of wireless-2.6
On Wed, Feb 07, 2007 at 04:11:17PM -0500, John W. Linville wrote:
On Tue, Feb 06, 2007 at 07:06:07PM -0500, Jeff Garzik wrote:
Would you mind rebasing resending, kind sir?
By your command! :-)
And once more, now with feeling! :-)
---
The following changes since commit 62d0cfcb27cf755cebdc93ca95dabc83608007cd:
Linus Torvalds (1):
Linux 2.6.20
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
Daniel Drake (1):
zd1211rw: Remove noisy debug message
Larry Finger (5):
bcm43xx: Fix problem with 1 GB RAM
bcm43xx: Fix scaling error for 'iwlist rate' information
bcm43xx: Fix scaling error for 'iwlist freq' information
bcm43xx: Check error returns in initialization routines
ieee80211: Fix sparse warning
Maxime Austruy (1):
zd1211rw: fix potential leak in usb_init
Michael Buesch (1):
bcm43xx: Enable fwpostfix in nondebug bcm43xx
Robert P. J. Day (2):
Rename IPW2100 debugging macros to not look like config options.
Replace incorrect macro name WIRELESS_EXT with CONFIG_WIRELESS_EXT
Ulrich Kunitz (3):
zd1211rw: Reset device in the probe call
zd1211rw: Fixed array size issue in reset_mode
zd1211rw: Added error stats update
drivers/net/wireless/bcm43xx/bcm43xx.h |1 +
drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 171 +++
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 25 +++--
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 28 ++--
drivers/net/wireless/ipw2100.c | 16 ++--
drivers/net/wireless/zd1211rw/zd_mac.c | 44 ++--
drivers/net/wireless/zd1211rw/zd_usb.c | 12 ++
net/core/net-sysfs.c|4 +-
net/ieee80211/ieee80211_tx.c|3 -
9 files changed, 210 insertions(+), 94 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h
b/drivers/net/wireless/bcm43xx/bcm43xx.h
index 8286678..4168b1a 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -766,6 +766,7 @@ struct bcm43xx_private {
* This is currently always BCM43xx_BUSTYPE_PCI
*/
u8 bustype;
+ u64 dma_mask;
u16 board_vendor;
u16 board_type;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index 978ed09..6e0dc76 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -145,16 +145,14 @@ dma_addr_t map_descbuffer(struct bcm43xx_dmaring *ring,
int tx)
{
dma_addr_t dmaaddr;
+ int direction = PCI_DMA_FROMDEVICE;
- if (tx) {
- dmaaddr = dma_map_single(ring-bcm-pci_dev-dev,
-buf, len,
-DMA_TO_DEVICE);
- } else {
- dmaaddr = dma_map_single(ring-bcm-pci_dev-dev,
+ if (tx)
+ direction = PCI_DMA_TODEVICE;
+
+ dmaaddr = pci_map_single(ring-bcm-pci_dev,
buf, len,
-DMA_FROM_DEVICE);
- }
+direction);
return dmaaddr;
}
@@ -166,13 +164,13 @@ void unmap_descbuffer(struct bcm43xx_dmaring *ring,
int tx)
{
if (tx) {
- dma_unmap_single(ring-bcm-pci_dev-dev,
+ pci_unmap_single(ring-bcm-pci_dev,
addr, len,
-DMA_TO_DEVICE);
+PCI_DMA_TODEVICE);
} else {
- dma_unmap_single(ring-bcm-pci_dev-dev,
+ pci_unmap_single(ring-bcm-pci_dev,
addr, len,
-DMA_FROM_DEVICE);
+PCI_DMA_FROMDEVICE);
}
}
@@ -183,8 +181,8 @@ void sync_descbuffer_for_cpu(struct bcm43xx_dmaring *ring,
{
assert(!ring-tx);
- dma_sync_single_for_cpu(ring-bcm-pci_dev-dev,
- addr, len, DMA_FROM_DEVICE);
+ pci_dma_sync_single_for_cpu(ring-bcm-pci_dev,
+ addr, len, PCI_DMA_FROMDEVICE);
}
static inline
@@ -194,8 +192,8 @@ void sync_descbuffer_for_device(struct bcm43xx_dmaring
*ring,
{
assert(!ring-tx);
- dma_sync_single_for_device(ring-bcm-pci_dev-dev,
- addr, len, DMA_FROM_DEVICE);
+ pci_dma_sync_single_for_cpu(ring-bcm-pci_dev,
+ addr, len, PCI_DMA_TODEVICE);
}
/* Unmap and free a descriptor buffer. */
@@ -214,17 +212,53 @@ void free_descriptor_buffer(struct bcm43xx_dmaring *ring,
static int alloc_ringmemory(struct bcm43xx_dmaring *ring)
{
- struct device *dev = (ring-bcm-pci_dev-dev);
-
- ring-descbase = dma_alloc_coherent(dev,
Re: [PATCH 1/2] NetXen: Fixes for ppc architecture.
Amit S. Kale wrote: NetXen: Fixes for ppc architecture. Signed-off-by: Amit S. Kale [EMAIL PROTECTED] applied 1-2 - 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: Please pull upstream branch of wireless-2.6
John W. Linville wrote: On Wed, Feb 07, 2007 at 04:11:17PM -0500, John W. Linville wrote: On Tue, Feb 06, 2007 at 07:06:07PM -0500, Jeff Garzik wrote: Would you mind rebasing resending, kind sir? By your command! :-) And once more, now with feeling! :-) --- The following changes since commit 62d0cfcb27cf755cebdc93ca95dabc83608007cd: Linus Torvalds (1): Linux 2.6.20 are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream Daniel Drake (1): zd1211rw: Remove noisy debug message Larry Finger (5): bcm43xx: Fix problem with 1 GB RAM bcm43xx: Fix scaling error for 'iwlist rate' information bcm43xx: Fix scaling error for 'iwlist freq' information bcm43xx: Check error returns in initialization routines ieee80211: Fix sparse warning Maxime Austruy (1): zd1211rw: fix potential leak in usb_init Michael Buesch (1): bcm43xx: Enable fwpostfix in nondebug bcm43xx Robert P. J. Day (2): Rename IPW2100 debugging macros to not look like config options. Replace incorrect macro name WIRELESS_EXT with CONFIG_WIRELESS_EXT Ulrich Kunitz (3): zd1211rw: Reset device in the probe call zd1211rw: Fixed array size issue in reset_mode zd1211rw: Added error stats update drivers/net/wireless/bcm43xx/bcm43xx.h |1 + drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 171 +++ drivers/net/wireless/bcm43xx/bcm43xx_main.c | 25 +++-- drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 28 ++-- drivers/net/wireless/ipw2100.c | 16 ++-- drivers/net/wireless/zd1211rw/zd_mac.c | 44 ++-- drivers/net/wireless/zd1211rw/zd_usb.c | 12 ++ net/core/net-sysfs.c|4 +- net/ieee80211/ieee80211_tx.c|3 - 9 files changed, 210 insertions(+), 94 deletions(-) pulled, thanks - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ethtool: flie option to register dump
Stephen Hemminger wrote: 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(-) applied 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
Re: [PATCH] ethtool: fix long statistics name
Stephen Hemminger wrote: Fix handling of statistics where the label is exactly 32 (ETH_GSTRING_LEN) characters long (observed with chelsio 10G driver). Before it would print garbage because of going by end of string. Don't need to copy string, just use formats properly. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- ethtool.c | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) applied - 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: e1000: update device ID table for register dumps
Auke Kok wrote: e1000: update device ID table for register dumps with new devices From: Auke Kok [EMAIL PROTECTED] The register dump routine of e1000 was missing several newer chipsets. I reimported the mac detection code from the linux e1000 driver. This fixes newer NIC's reporting that their bus type is PCI instead of PCI-e. Signed-off-by: Auke Kok [EMAIL PROTECTED] --- e1000.c | 154 ++- 1 files changed, 103 insertions(+), 51 deletions(-) applied - 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 ethtool] marvell chip decode formatting
Stephen Hemminger wrote: Fix some typo's and formatting on Marvell ethtool output. If sync transmit queue is not used, don't print settings. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- marvell.c | 37 - 1 files changed, 24 insertions(+), 13 deletions(-) applied - 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] phy layer: add kernel-doc + DocBook
Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Convert function documentation in drivers/net/phy/ to kernel-doc and add it to DocBook. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- Documentation/DocBook/kernel-api.tmpl |6 + drivers/net/phy/mdio_bus.c| 19 ++- drivers/net/phy/phy.c | 192 -- drivers/net/phy/phy_device.c | 114 +--- 4 files changed, 234 insertions(+), 97 deletions(-) ACK but patch does not support to linux-2.6.git - 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] phy devices: use same arg types
Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] sparse complains about differing types from prototype to definition, so change the u32 to phy_interface_t: drivers/net/phy/phy_device.c:140:19: error: symbol 'phy_connect' redeclared with different type (originally declared at include/linux/phy.h:362) - incompatible argument 5 (different signedness) drivers/net/phy/phy_device.c:190:19: error: symbol 'phy_attach' redeclared with different type (originally declared at include/linux/phy.h:360) - incompatible argument 4 (different signedness) Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/net/phy/phy_device.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) applied - 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][RESPIN] gianfar: Convert network devices to use struct device instead of class_device
Convert network devices to use struct device instead of class_device. Greg
missed this one in his cleanup path.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Here's a respin of the patch against a recent linus.git tree. If this
doesnt apply I'm at a loss.
- k
commit b8fa75ada71d54a75c85fb7d3200419f790328b2
tree f67387b120c45e2c4ae17e5aeabd529c58b58113
parent eaefd5fb7d793c9c1bcef1b0c0d5ec3824a85b91
author Kumar Gala [EMAIL PROTECTED] Fri, 09 Feb 2007 15:30:00 -0600
committer Kumar Gala [EMAIL PROTECTED] Fri, 09 Feb 2007 15:30:00 -0600
drivers/net/gianfar_sysfs.c | 108 ++-
1 files changed, 55 insertions(+), 53 deletions(-)
diff --git a/drivers/net/gianfar_sysfs.c b/drivers/net/gianfar_sysfs.c
index 9dd387f..6e2166a 100644
--- a/drivers/net/gianfar_sysfs.c
+++ b/drivers/net/gianfar_sysfs.c
@@ -39,13 +39,15 @@
#include gianfar.h
#define GFAR_ATTR(_name) \
-static ssize_t gfar_show_##_name(struct class_device *cdev, char *buf); \
-static ssize_t gfar_set_##_name(struct class_device *cdev, \
+static ssize_t gfar_show_##_name(struct device *dev, \
+struct device_attribute *attr, char *buf); \
+static ssize_t gfar_set_##_name(struct device *dev, \
+ struct device_attribute *attr, \
const char *buf, size_t count); \
-static CLASS_DEVICE_ATTR(_name, 0644, gfar_show_##_name, gfar_set_##_name)
+static DEVICE_ATTR(_name, 0644, gfar_show_##_name, gfar_set_##_name)
#define GFAR_CREATE_FILE(_dev, _name) \
- class_device_create_file(_dev-class_dev, class_device_attr_##_name)
+ device_create_file(_dev-dev, dev_attr_##_name)
GFAR_ATTR(bd_stash);
GFAR_ATTR(rx_stash_size);
@@ -54,29 +56,28 @@ GFAR_ATTR(fifo_threshold);
GFAR_ATTR(fifo_starve);
GFAR_ATTR(fifo_starve_off);
-#define to_net_dev(cd) container_of(cd, struct net_device, class_dev)
-
-static ssize_t gfar_show_bd_stash(struct class_device *cdev, char *buf)
+static ssize_t gfar_show_bd_stash(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
- return sprintf(buf, %s\n, priv-bd_stash_en? on : off);
+ return sprintf(buf, %s\n, priv-bd_stash_en ? on : off);
}
-static ssize_t gfar_set_bd_stash(struct class_device *cdev,
- const char *buf, size_t count)
+static ssize_t gfar_set_bd_stash(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
int new_setting = 0;
u32 temp;
unsigned long flags;
/* Find out the new setting */
- if (!strncmp(on, buf, count-1) || !strncmp(1, buf, count-1))
+ if (!strncmp(on, buf, count - 1) || !strncmp(1, buf, count - 1))
new_setting = 1;
- else if (!strncmp(off, buf, count-1) || !strncmp(0, buf, count-1))
+ else if (!strncmp(off, buf, count - 1)
+|| !strncmp(0, buf, count - 1))
new_setting = 0;
else
return count;
@@ -100,19 +101,19 @@ static ssize_t gfar_set_bd_stash(struct class_device
*cdev,
return count;
}
-static ssize_t gfar_show_rx_stash_size(struct class_device *cdev, char *buf)
+static ssize_t gfar_show_rx_stash_size(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
return sprintf(buf, %d\n, priv-rx_stash_size);
}
-static ssize_t gfar_set_rx_stash_size(struct class_device *cdev,
- const char *buf, size_t count)
+static ssize_t gfar_set_rx_stash_size(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
unsigned int length = simple_strtoul(buf, NULL, 0);
u32 temp;
unsigned long flags;
@@ -146,21 +147,21 @@ static ssize_t gfar_set_rx_stash_size(struct class_device
*cdev,
return count;
}
-
/* Stashing will only be enabled when rx_stash_size != 0 */
-static ssize_t gfar_show_rx_stash_index(struct class_device *cdev, char *buf)
+static ssize_t gfar_show_rx_stash_index(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
- struct
Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
cond_resched() called from softirq, amongst other problems. On Fri, 9 Feb 2007 08:23:44 -0800 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=7974 Summary: BUG: scheduling while atomic: swapper/0x1100/0 Kernel Version: 2.6.20 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] The machine hangs in normal boot with 2.6.19 and 2.6.20 after network starts. If I boot in single mode and start the services manually, the machine and network works fine, but I see this on dmesg: Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.0 20060515 (Red Hat 4.1.0-18)) #6 SMP Mon Feb 5 15:14:30 BRST 2007 Command line: ro root=/dev/sda2 vga=791 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 0010 - 3f7c (usable) BIOS-e820: 3f7c - 3f7cfc00 (ACPI data) BIOS-e820: 3f7cfc00 - 3f7ff000 (reserved) BIOS-e820: 3f80 - 4000 (reserved) BIOS-e820: e000 - fed00400 (reserved) BIOS-e820: fed13000 - feda (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) Entering add_active_range(0, 0, 160) 0 entries of 256 used Entering add_active_range(0, 256, 260032) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 DELL ) @ 0x000fd690 ACPI: RSDT (v001 DELL PE8000x0001 MSFT 0x010a) @ 0x000fd6a4 ACPI: FADT (v001 DELL PE8000x0001 MSFT 0x010a) @ 0x000fd6dc ACPI: MADT (v001 DELL PE8000x0001 MSFT 0x010a) @ 0x000fd750 ACPI: SPCR (v001 DELL PE8000x0001 MSFT 0x010a) @ 0x000fd7c4 ACPI: HPET (v001 DELL PE8000x0001 MSFT 0x010a) @ 0x000fd814 ACPI: MCFG (v001 DELL PE8000x0001 MSFT 0x010a) @ 0x000fd84c ACPI: DSDT (v001 DELL PE8000x0001 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 160) 0 entries of 256 used Entering add_active_range(0, 256, 260032) 1 entries of 256 used Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 160 0: 256 - 260032 On node 0 totalpages: 259936 DMA zone: 56 pages used for memmap DMA zone: 1279 pages reserved DMA zone: 2665 pages, LIFO batch:0 DMA32 zone: 3499 pages used for memmap DMA32 zone: 252437 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfec8] gsi_base[32]) IOAPIC[1]: apic_id 3, address 0xfec8, GSI 32-55 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x base: 0xfed0 Using ACPI (MADT) for SMP configuration information Nosave address range: 000a - 0010 Allocating PCI resources starting at 5000 (gap: 4000:a000) PERCPU: Allocating 33024 bytes of per cpu data Built 1 zonelists. Total pages: 255102 Kernel command line: ro root=/dev/sda2 vga=791 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... Memory: 1017476k/1040128k available (3075k kernel code, 21768k reserved, 1225k data, 248k init) Calibrating delay using timer specific routine.. 6406.66 BogoMIPS (lpj=12813334) Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM1) Freeing SMP alternatives: 32k freed ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12500392 Detected 12.500 MHz APIC timer. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 6400.14 BogoMIPS (lpj=12800283) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0
Re: [PATCH 1/5] Add PCBC crypto template support
From: David Howells [EMAIL PROTECTED] Date: Fri, 09 Feb 2007 11:18:01 + Herbert Xu [EMAIL PROTECTED] wrote: This is already in the crypto-2.6 tree that I pushed yesterday. Thanks. However, I'll continue to include the patches in my set until they reach Linus's tree. They are in Linus's tree. - 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] MAINTAINERS: no DMFE maintainer
From: Randy Dunlap [EMAIL PROTECTED] Tobias wrote that he no longer maintains this driver and requested to be removed from MAINTAINERS. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- MAINTAINERS |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- linux-2.6.20-git5.orig/MAINTAINERS +++ linux-2.6.20-git5/MAINTAINERS @@ -1112,10 +1112,8 @@ T: git kernel.org:/pub/scm/linux/kernel/ S: Supported DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER -P: Tobias Ringstrom -M: [EMAIL PROTECTED] L: netdev@vger.kernel.org -S: Maintained +S: Orphan DOCBOOK FOR DOCUMENTATION P: Randy Dunlap - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
Andrew Morton [EMAIL PROTECTED] : cond_resched() called from softirq, amongst other problems. Seems too simple to be right. Btw calling dev_set_mac_address may hurt some tg3: - tg3_set_mac_addr - tg3_netif_stop (depending on the content of their sram): - netif_poll_disable - schedule_timeout_interruptible diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index e76539a..a4bcfe2 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -673,7 +673,7 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change) struct sk_buff *skb; int err = -ENOBUFS; - skb = nlmsg_new(if_nlmsg_size(0), GFP_KERNEL); + skb = nlmsg_new(if_nlmsg_size(0), GFP_ATOMIC); if (skb == NULL) goto errout; @@ -681,7 +681,7 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change) /* failure implies BUG in if_nlmsg_size() */ BUG_ON(err 0); - err = rtnl_notify(skb, 0, RTNLGRP_LINK, NULL, GFP_KERNEL); + err = rtnl_notify(skb, 0, RTNLGRP_LINK, NULL, GFP_ATOMIC); errout: if (err 0) rtnl_set_sk_err(RTNLGRP_LINK, err); - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Hello, James! On Fri, 2007-02-09 at 13:12 -0800, James Ketrenos wrote: You can find the new driver, and additional information about it, here: http://intellinuxwireless.org/iwlwifi. I cannot get it through git: $ git-clone http://intellinuxwireless.org/repos/iwlwifi.git Initialized empty Git repository in /home/proski/src/iwlwifi/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? Perhaps git is right? There is no info/refs there. You can find that package at: http://intellinuxwireless.org/d80211 I appreciate that you are doing this. But it doesn't compile against kernels compiled outside the tree: grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file or directory Apparently it should be looking into /lib/modules/2.6.20/source as well. That was a problem with the official ipw3945 drivers as well. -- Regards, Pavel Roskin - 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] MAINTAINERS: no DMFE maintainer
Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Tobias wrote that he no longer maintains this driver and requested to be removed from MAINTAINERS. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- MAINTAINERS |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) Levitsky Maxim [EMAIL PROTECTED] just posted a bunch of patches to the dmfe driver, maybe you could ping him? 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: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
On Fri, 2007-02-09 at 23:35 +0100, Francois Romieu wrote: Andrew Morton [EMAIL PROTECTED] : cond_resched() called from softirq, amongst other problems. Seems too simple to be right. Btw calling dev_set_mac_address may hurt some tg3: - tg3_set_mac_addr - tg3_netif_stop (depending on the content of their sram): - netif_poll_disable - schedule_timeout_interruptible Yes, known problem. Bonding calls dev_set_mac_address from unsleepable 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] MAINTAINERS: no DMFE maintainer
On Fri, 09 Feb 2007 17:45:12 -0500 Jeff Garzik wrote: Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Tobias wrote that he no longer maintains this driver and requested to be removed from MAINTAINERS. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- MAINTAINERS |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) Levitsky Maxim [EMAIL PROTECTED] just posted a bunch of patches to the dmfe driver, maybe you could ping him? Hi Maxim, What do you think about this patch to the MAINTAINERS file based on your recent DMFE patch history? --- From: Randy Dunlap [EMAIL PROTECTED] Tobias wrote that he no longer maintains this driver and requested to be removed from MAINTAINERS. However, Levitsky Maxim has been active on DMFE recently. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.20-git5.orig/MAINTAINERS +++ linux-2.6.20-git5/MAINTAINERS @@ -1112,8 +1112,8 @@ T:git kernel.org:/pub/scm/linux/kernel/ S: Supported DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER -P: Tobias Ringstrom -M: [EMAIL PROTECTED] +P: Levitsky Maxim +M: [EMAIL PROTECTED] L: netdev@vger.kernel.org S: Maintained - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Pavel Roskin wrote: Hello, James! On Fri, 2007-02-09 at 13:12 -0800, James Ketrenos wrote: You can find the new driver, and additional information about it, here: http://intellinuxwireless.org/iwlwifi. I cannot get it through git: $ git-clone http://intellinuxwireless.org/repos/iwlwifi.git Initialized empty Git repository in /home/proski/src/iwlwifi/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? Perhaps git is right? There is no info/refs there. Updated and tested 'git clone' and its working now (I use cg-clone) grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file or directory Apparently it should be looking into /lib/modules/2.6.20/source as well. That was a problem with the official ipw3945 drivers as well. I'll look into it. Does it work if you explicitly set KSRC to point to your kernel sources? $ make KSRC=/lib/modules/2.6.20/source ? Thanks, James - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Fri, 2007-02-09 at 14:18 -0800, James Ketrenos wrote: Updated and tested 'git clone' and its working now (I use cg-clone) Thanks. It's working for me too. grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file or directory Apparently it should be looking into /lib/modules/2.6.20/source as well. That was a problem with the official ipw3945 drivers as well. I'll look into it. Does it work if you explicitly set KSRC to point to your kernel sources? $ make KSRC=/lib/modules/2.6.20/source That works. At least it doesn't report errors. But it doesn't create a single object file. Anyway, I'm cheating here - my kernel does include d80211 support. build is still hardcoded in iwlwifi's Makefile. It's interesting that D80211_INC is defined twice in Makefile. That must be wrong. I'm going to try everything on a more traditional build in the tree and without d80211. And then I'll try to break some assumptions. -- Regards, Pavel Roskin - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Pavel Roskin wrote: On Fri, 2007-02-09 at 14:18 -0800, James Ketrenos wrote: grep: /lib/modules/2.6.20/build//include/linux/netdevice.h: No such file or directory ... I'll look into it. Does it work if you explicitly set KSRC to point to your kernel sources? $ make KSRC=/lib/modules/2.6.20/source That works. At least it doesn't report errors. But it doesn't create a single object file. 'make' builds a set of sources compatible with the running kernel (or the one pointed to via KSRC=). 'make patch_kernel' will then install the sources into your kernel tree. You then build d80211 as part of your main kernel (either as a module or static) The changes 'patch_kernel' makes do not require a full kernel rebuild (you can just build the 80211 modules). We'll want to add the ability to build as out-of-tree .ko's (similar to what iwlwifi does) but I wanted to get the project announced. build is still hardcoded in iwlwifi's Makefile. It's interesting that D80211_INC is defined twice in Makefile. That must be wrong. Now that you point it out, I hadn't tried using KSRC w/ the iwlwifi build, just d80211. I'll have to fix that :) Thanks, James - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: Fix loss of association after resume
After a suspend/resume cycle, bcm43xx-softmac has lost its association with
the AP and requires manual intervention. This situation is fixed by making
one of softmac's internal routines public and calling it.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -4278,6 +4278,7 @@ static int bcm43xx_resume(struct pci_dev
{
struct net_device *net_dev = pci_get_drvdata(pdev);
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ struct ieee80211softmac_device *mac = ieee80211_priv(net_dev);
int err = 0;
dprintk(KERN_INFO PFX Resuming...\n);
@@ -4299,6 +4300,9 @@ static int bcm43xx_resume(struct pci_dev
}
netif_device_attach(net_dev);
+ if (mac-associnfo.associated)
+ ieee80211softmac_try_reassoc(mac);
+
dprintk(KERN_INFO PFX Device resumed.\n);
return 0;
Index: linux-2.6/include/net/ieee80211softmac.h
===
--- linux-2.6.orig/include/net/ieee80211softmac.h
+++ linux-2.6/include/net/ieee80211softmac.h
@@ -254,6 +254,7 @@ struct ieee80211softmac_device {
};
extern void ieee80211softmac_scan_finished(struct ieee80211softmac_device *sm);
+extern void ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac);
static inline void * ieee80211softmac_priv(struct net_device *dev)
{
Index: linux-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- linux-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -441,6 +441,7 @@ ieee80211softmac_try_reassoc(struct ieee
schedule_delayed_work(mac-associnfo.work, 0);
spin_unlock_irqrestore(mac-lock, flags);
}
+EXPORT_SYMBOL_GPL(ieee80211softmac_try_reassoc);
int
ieee80211softmac_handle_disassoc(struct net_device * dev,
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: Fix code for spec changes of 2/7/2007
The specifications for the bcm43xx driver have been modified. This patch
incorporates these changes in the code, which results in the BCM4311 and
BCM4312 working. The name of one of the PHY parameters, previously known
as version, has been changed to analog core version .
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
John,
I hope this fix makes it into 2.6.21. As you have seen from the list, it is a
biggie!
Larry
---
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -542,7 +542,7 @@ struct bcm43xx_lopair {
struct bcm43xx_phyinfo {
/* Hardware Data */
- u8 version;
+ u8 analog;
u8 type;
u8 rev;
u16 antenna_diversity;
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -205,8 +205,8 @@ static void bcm43xx_phy_init_pctl(struct
(bcm-board_type == 0x0416))
return;
- bcm43xx_write16(bcm, 0x03E6, bcm43xx_read16(bcm, 0x03E6) 0xFFDF);
bcm43xx_phy_write(bcm, 0x0028, 0x8018);
+ bcm43xx_write16(bcm, 0x03E6, bcm43xx_read16(bcm, 0x03E6) 0xFFDF);
if (phy-type == BCM43xx_PHYTYPE_G) {
if (!phy-connected)
@@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
u16 offset;
+ u16 value;
+ u8 old_channel;
- if (phy-version == 1
- radio-version == 0x2050) {
+ if (phy-analog == 1)
bcm43xx_radio_write16(bcm, 0x007A,
bcm43xx_radio_read16(bcm, 0x007A)
| 0x0050);
- }
if ((bcm-board_vendor != PCI_VENDOR_ID_BROADCOM)
(bcm-board_type != 0x0416)) {
+ value = 0x2120;
for (offset = 0x00A8 ; offset 0x00C7; offset++) {
- bcm43xx_phy_write(bcm, offset,
- (bcm43xx_phy_read(bcm, offset) +
0x2020)
- 0x3F3F);
+ bcm43xx_phy_write(bcm, offset, value);
+ value += 0x0202;
}
}
bcm43xx_phy_write(bcm, 0x0035,
@@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_phy_read(bcm,
BCM43xx_PHY_RADIO_BITFIELD) | (1 11));
}
- if (phy-version == 1 radio-version == 0x2050) {
+ if (phy-analog == 1) {
bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
bcm43xx_phy_write(bcm, 0x0021, 0x3763);
bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
@@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
bcm43xx_write16(bcm, 0x03EC, 0x3F22);
- if (phy-version == 1 radio-version == 0x2050)
+ if (phy-analog == 1)
bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
else
bcm43xx_phy_write(bcm, 0x0020, 0x301C);
- if (phy-version == 0)
+ if (phy-analog == 0)
bcm43xx_write16(bcm, 0x03E4, 0x3000);
+ old_channel = radio-channel;
/* Force to channel 7, even if not supported. */
bcm43xx_radio_selectchannel(bcm, 7, 0);
@@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) |
0x0007);
- bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
+ bcm43xx_radio_selectchannel(bcm, old_channel, 0);
bcm43xx_phy_write(bcm, 0x0014, 0x0080);
bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
- bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
+ bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
bcm43xx_radio_set_txpower_bg(bcm, 0x, 0x, 0x);
@@ -933,6 +934,8 @@ static void bcm43xx_phy_initb6(struct bc
bcm43xx_phy_read(bcm, 0x0802) | 0x0100);
bcm43xx_phy_write(bcm, 0x042B,
bcm43xx_phy_read(bcm, 0x042B) | 0x2000);
+ bcm43xx_phy_write(bcm, 0x5B, 0x);
+ bcm43xx_phy_write(bcm, 0x5C, 0x);
}
/* Force to channel 7, even if not supported. */
@@ -976,10 +979,12 @@ static void bcm43xx_phy_initb6(struct bc
bcm43xx_radio_write16(bcm, 0x005D, 0x000D);
}
- if (phy-rev == 4)
- bcm43xx_phy_write(bcm, 0x0002, (bcm43xx_phy_read(bcm, 0x0002)
0xFFC0) | 0x0004);
- else
+ if (phy-analog == 4){
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Friday 09 February 2007 17:18, Larry Finger wrote:
After a suspend/resume cycle, bcm43xx-softmac has lost its association with
the AP and requires manual intervention. This situation is fixed by making
one of softmac's internal routines public and calling it.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Ack, this is good as workaround.
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -4278,6 +4278,7 @@ static int bcm43xx_resume(struct pci_dev
{
struct net_device *net_dev = pci_get_drvdata(pdev);
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
+ struct ieee80211softmac_device *mac = ieee80211_priv(net_dev);
int err = 0;
dprintk(KERN_INFO PFX Resuming...\n);
@@ -4299,6 +4300,9 @@ static int bcm43xx_resume(struct pci_dev
}
netif_device_attach(net_dev);
+ if (mac-associnfo.associated)
+ ieee80211softmac_try_reassoc(mac);
+
dprintk(KERN_INFO PFX Device resumed.\n);
return 0;
Index: linux-2.6/include/net/ieee80211softmac.h
===
--- linux-2.6.orig/include/net/ieee80211softmac.h
+++ linux-2.6/include/net/ieee80211softmac.h
@@ -254,6 +254,7 @@ struct ieee80211softmac_device {
};
extern void ieee80211softmac_scan_finished(struct ieee80211softmac_device
*sm);
+extern void ieee80211softmac_try_reassoc(struct ieee80211softmac_device
*mac);
static inline void * ieee80211softmac_priv(struct net_device *dev)
{
Index: linux-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- linux-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -441,6 +441,7 @@ ieee80211softmac_try_reassoc(struct ieee
schedule_delayed_work(mac-associnfo.work, 0);
spin_unlock_irqrestore(mac-lock, flags);
}
+EXPORT_SYMBOL_GPL(ieee80211softmac_try_reassoc);
int
ieee80211softmac_handle_disassoc(struct net_device * dev,
-
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: Fix code for spec changes of 2/7/2007
On Friday 09 February 2007 17:32, Larry Finger wrote:
The specifications for the bcm43xx driver have been modified. This patch
incorporates these changes in the code, which results in the BCM4311 and
BCM4312 working. The name of one of the PHY parameters, previously known
as version, has been changed to analog core version .
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
@@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
u16 offset;
+ u16 value;
+ u8 old_channel;
- if (phy-version == 1
- radio-version == 0x2050) {
Why do you delete the check to radio version.
It's still there in latest specs:
http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5
+ if (phy-analog == 1)
bcm43xx_radio_write16(bcm, 0x007A,
bcm43xx_radio_read16(bcm, 0x007A)
| 0x0050);
- }
if ((bcm-board_vendor != PCI_VENDOR_ID_BROADCOM)
(bcm-board_type != 0x0416)) {
+ value = 0x2120;
for (offset = 0x00A8 ; offset 0x00C7; offset++) {
- bcm43xx_phy_write(bcm, offset,
- (bcm43xx_phy_read(bcm, offset) +
0x2020)
-0x3F3F);
+ bcm43xx_phy_write(bcm, offset, value);
+ value += 0x0202;
}
I don't see how this matches specs.
}
bcm43xx_phy_write(bcm, 0x0035,
@@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_phy_read(bcm,
BCM43xx_PHY_RADIO_BITFIELD) | (1 11));
}
- if (phy-version == 1 radio-version == 0x2050) {
Dito.
+ if (phy-analog == 1) {
bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
bcm43xx_phy_write(bcm, 0x0021, 0x3763);
bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
@@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
bcm43xx_write16(bcm, 0x03EC, 0x3F22);
- if (phy-version == 1 radio-version == 0x2050)
Dito.
+ if (phy-analog == 1)
bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
else
bcm43xx_phy_write(bcm, 0x0020, 0x301C);
- if (phy-version == 0)
+ if (phy-analog == 0)
bcm43xx_write16(bcm, 0x03E4, 0x3000);
+ old_channel = radio-channel;
/* Force to channel 7, even if not supported. */
bcm43xx_radio_selectchannel(bcm, 7, 0);
@@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) |
0x0007);
- bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
+ bcm43xx_radio_selectchannel(bcm, old_channel, 0);
bcm43xx_phy_write(bcm, 0x0014, 0x0080);
bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
- bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
+ bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
Well, this seems correct, but specs are still different. From where did you get
this?
Well, I don't review the rest until you say to which specs you did the changes.
;)
--
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: Fix code for spec changes of 2/7/2007
Well, I don't review the rest until you say to which specs you did the changes. ;) http://bcm-specs.sipsolutions.net/B5PHY Larry was working from the old specs, so when I updated it, I only updated the old specs. I'll fix the v4 specs soon. -Joe - 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: Fix code for spec changes of 2/7/2007
dprintk(KERN_INFO PFX Detected PHY: Version: %x, Type %x, Revision %x\n, You should change this too, the Version text should read Analog instead. -Joe - 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: Fix code for spec changes of 2/7/2007
On Friday 09 February 2007 23:22, Joseph Jezak wrote: Well, I don't review the rest until you say to which specs you did the changes. ;) http://bcm-specs.sipsolutions.net/B5PHY Larry was working from the old specs, so when I updated it, I only updated the old specs. I'll fix the v4 specs soon. Ah, ok. I think we should decide on which specs carry most recent information. I think v3 specs should be considered obsolete and new information/ fixes should go into v4. It is already too confusing where to find newest information to a certain thing. -- 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: Fix code for spec changes of 2/7/2007
Michael,
Michael Buesch wrote:
On Friday 09 February 2007 17:32, Larry Finger wrote:
The specifications for the bcm43xx driver have been modified. This patch
incorporates these changes in the code, which results in the BCM4311 and
BCM4312 working. The name of one of the PHY parameters, previously known
as version, has been changed to analog core version .
Signed-off-by: Larry Finger[EMAIL PROTECTED]
---
@@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
u16 offset;
+u16 value;
+u8 old_channel;
-if (phy-version == 1
-radio-version == 0x2050) {
Why do you delete the check to radio version.
It's still there in latest specs:
http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5
As I have no real understanding of the differences between V3 and V4 firmware,
I only follow the V3
specs at http://bcm-specs.sipsolutions.net. My usage of the V4 specs is to
checking if they can
clean a point of confusion in the V3 spec. The radio version check is
eliminated at the beginning of
the phy_initb5 routine in http://bcm-specs.sipsolutions.net/B5PHY. As there are
radio version checks
later in the routine, I think it was meant to be removed here.
+if (phy-analog == 1)
bcm43xx_radio_write16(bcm, 0x007A,
bcm43xx_radio_read16(bcm, 0x007A)
| 0x0050);
-}
if ((bcm-board_vendor != PCI_VENDOR_ID_BROADCOM)
(bcm-board_type != 0x0416)) {
+value = 0x2120;
for (offset = 0x00A8 ; offset 0x00C7; offset++) {
-bcm43xx_phy_write(bcm, offset,
- (bcm43xx_phy_read(bcm, offset) +
0x2020)
- 0x3F3F);
+bcm43xx_phy_write(bcm, offset, value);
+value += 0x0202;
}
I don't see how this matches specs.
See step 2 of http://bcm-specs.sipsolutions.net/B5PHY.
}
bcm43xx_phy_write(bcm, 0x0035,
@@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_phy_read(bcm,
BCM43xx_PHY_RADIO_BITFIELD) | (1 11));
}
-if (phy-version == 1 radio-version == 0x2050) {
Dito.
Ibid Step 7.
+if (phy-analog == 1) {
bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
bcm43xx_phy_write(bcm, 0x0021, 0x3763);
bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
@@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
bcm43xx_write16(bcm, 0x03EC, 0x3F22);
-if (phy-version == 1 radio-version == 0x2050)
Dito.
Step 11.
+if (phy-analog == 1)
bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
else
bcm43xx_phy_write(bcm, 0x0020, 0x301C);
-if (phy-version == 0)
+if (phy-analog == 0)
bcm43xx_write16(bcm, 0x03E4, 0x3000);
+old_channel = radio-channel;
/* Force to channel 7, even if not supported. */
bcm43xx_radio_selectchannel(bcm, 7, 0);
@@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) |
0x0007);
-bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
+bcm43xx_radio_selectchannel(bcm, old_channel, 0);
bcm43xx_phy_write(bcm, 0x0014, 0x0080);
bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
-bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
+bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
Well, this seems correct, but specs are still different. From where did you
get this?
Steps 14 - 26 of http://bcm-specs.sipsolutions.net/B5PHY
Well, I don't review the rest until you say to which specs you did the
changes. ;)
As I said earlier, everything came from http://bcm-specs.sipsolutions.net.
Larry
-
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: Fix code for spec changes of 2/7/2007
Michael Buesch wrote: On Friday 09 February 2007 23:22, Joseph Jezak wrote: Well, I don't review the rest until you say to which specs you did the changes. ;) http://bcm-specs.sipsolutions.net/B5PHY Larry was working from the old specs, so when I updated it, I only updated the old specs. I'll fix the v4 specs soon. Ah, ok. I think we should decide on which specs carry most recent information. I think v3 specs should be considered obsolete and new information/ fixes should go into v4. It is already too confusing where to find newest information to a certain thing. I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware. Larry - 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: Fix code for spec changes of 2/7/2007
On Friday 09 February 2007 17:32, Larry Finger wrote:
The specifications for the bcm43xx driver have been modified. This patch
incorporates these changes in the code, which results in the BCM4311 and
BCM4312 working. The name of one of the PHY parameters, previously known
as version, has been changed to analog core version .
Signed-off-by: Larry Finger[EMAIL PROTECTED]
if ((bcm-board_vendor != PCI_VENDOR_ID_BROADCOM)
(bcm-board_type != 0x0416)) {
+ value = 0x2120;
for (offset = 0x00A8 ; offset 0x00C7; offset++) {
- bcm43xx_phy_write(bcm, offset,
- (bcm43xx_phy_read(bcm, offset) +
0x2020)
-0x3F3F);
+ bcm43xx_phy_write(bcm, offset, value);
The specs are unclear at this point:
Write the value to the offset
Offset in which register type?
@@ -933,6 +934,8 @@ static void bcm43xx_phy_initb6(struct bc
bcm43xx_phy_read(bcm, 0x0802) | 0x0100);
bcm43xx_phy_write(bcm, 0x042B,
bcm43xx_phy_read(bcm, 0x042B) | 0x2000);
+ bcm43xx_phy_write(bcm, 0x5B, 0x);
+ bcm43xx_phy_write(bcm, 0x5C, 0x);
}
/* Force to channel 7, even if not supported. */
Backup and reset old_channel later here, too.
Also, look at this:
# If the current channel is 8 or greater
1. Set the channel to 1
# Otherwise
1. Set the channel to 13
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1393,11 +1393,12 @@ u16 bcm43xx_radio_init2050(struct bcm43x
backup[12] = bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT);
// Initialization
- if (phy-version == 0) {
+ if (phy-analog == 0) {
bcm43xx_write16(bcm, 0x03E6, 0x0122);
} else {
- if (phy-version = 2)
- bcm43xx_write16(bcm, 0x03E6, 0x0040);
+ if (phy-analog = 2)
+ bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm,
0x0003)
+ 0xFFBF) | 0x0040);
I think here is a specs bug.
bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT,
(bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT)
| 0x2000));
}
--
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: Fix code for spec changes of 2/7/2007
On Friday 09 February 2007 19:21, Larry Finger wrote: Michael Buesch wrote: On Friday 09 February 2007 23:22, Joseph Jezak wrote: Well, I don't review the rest until you say to which specs you did the changes. ;) http://bcm-specs.sipsolutions.net/B5PHY Larry was working from the old specs, so when I updated it, I only updated the old specs. I'll fix the v4 specs soon. Ah, ok. I think we should decide on which specs carry most recent information. I think v3 specs should be considered obsolete and new information/ fixes should go into v4. It is already too confusing where to find newest information to a certain thing. I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware. Well, the difference between v3 and v4 is: * The SHM API. * v4 may include less BPHY stuff, as broadcom's v4 drivers don't include BHY anymore. So I'd say for everything bug BPHY the v4 specs should be considered latest. -- 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: Fix code for spec changes of 2/7/2007
I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware. That's also part of the problem. With the v4 driver, Broadcom dropped support for a number of older BPHY devices (4301/4303 and some 4306 revisions). Do we still want to support those? Should I continue writing the specs for the uCode revision it's based on or should I combine them? -Joe - 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: Fix code for spec changes of 2/7/2007
The specs are unclear at this point:
Write the value to the offset
Offset in which register type?
PHY Register. I've clarified it in the specs, I think this was said
before, I made it worse when I cleaned it up.
// Initialization
- if (phy-version == 0) {
+ if (phy-analog == 0) {
bcm43xx_write16(bcm, 0x03E6, 0x0122);
} else {
- if (phy-version = 2)
- bcm43xx_write16(bcm, 0x03E6, 0x0040);
+ if (phy-analog = 2)
+ bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm,
0x0003)
+0xFFBF) | 0x0040);
I think here is a specs bug.
This is correct. Why do you think it's a specs bug?
-Joe
-
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: Fix code for spec changes of 2/7/2007
On Friday 09 February 2007 20:05, Joseph Jezak wrote: I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware. That's also part of the problem. With the v4 driver, Broadcom dropped support for a number of older BPHY devices (4301/4303 and some 4306 revisions). Do we still want to support those? Should I continue writing the specs for the uCode revision it's based on or should I combine them? If it's easily possible, please try to combine the old stuff with the new v4 specs. I think it's basically only dropped if() branches, right? -- 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: Fix code for spec changes of 2/7/2007
Joe, Joseph Jezak wrote: That's also part of the problem. With the v4 driver, Broadcom dropped support for a number of older BPHY devices (4301/4303 and some 4306 revisions). Do we still want to support those? Should I continue writing the specs for the uCode revision it's based on or should I combine them? As my 4306 is a rev 1 and is likely a version dropped in the V4 driver, I have a special interest in this question. My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs by that time, and that maintenance will only require following kernel API changes. As the work will be yours, you should decide if you would rather maintain the V3 and V4 pages separately, or denote the special requirements of each firmware flavor in a combined set of pages. Larry - 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: Fix code for spec changes of 2/7/2007
On Friday 09 February 2007 20:17, Joseph Jezak wrote:
The specs are unclear at this point:
Write the value to the offset
Offset in which register type?
PHY Register. I've clarified it in the specs, I think this was said
before, I made it worse when I cleaned it up.
// Initialization
- if (phy-version == 0) {
+ if (phy-analog == 0) {
bcm43xx_write16(bcm, 0x03E6, 0x0122);
} else {
- if (phy-version = 2)
- bcm43xx_write16(bcm, 0x03E6, 0x0040);
+ if (phy-analog = 2)
+ bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm,
0x0003)
+ 0xFFBF) | 0x0040);
I think here is a specs bug.
This is correct. Why do you think it's a specs bug?
Because
a) The old one made more sense to me.
b) Write MMIO register 0x3? I mean. What is that?
Could this be PHY or radio register 0x3?
--
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: Fix code for spec changes of 2/7/2007
Michael Buesch wrote: On Friday 09 February 2007 20:05, Joseph Jezak wrote: I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware. That's also part of the problem. With the v4 driver, Broadcom dropped support for a number of older BPHY devices (4301/4303 and some 4306 revisions). Do we still want to support those? Should I continue writing the specs for the uCode revision it's based on or should I combine them? If it's easily possible, please try to combine the old stuff with the new v4 specs. I think it's basically only dropped if() branches, right? Well, here's the problem. There are a few places where a value is changed (different value written to a register). Does this mean that the value is different due to the uCode changes (can't tell, no documentation)? Is it applicable to all revisions (can't tell, some revisions are not supported in this version)? If the revision number range in a check changes is that because of a difference in supported cards or a bug fix? So, it's not as simple as just dropped if() branches. I can do my best to combine them (I have done some of this already), but I can't promise that it'll be accurate for all revisions or versions of the chipset. -Joe - 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: Fix code for spec changes of 2/7/2007
This is correct. Why do you think it's a specs bug? Because a) The old one made more sense to me. b) Write MMIO register 0x3? I mean. What is that? Could this be PHY or radio register 0x3? Apologies. You are correct that this should be PHY Register 0x3, not MMIO offset 0x3. I've corrected this in the specs. -Joe - 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] NET : UDP can use sk_hash to speedup lookups
From: Eric Dumazet [EMAIL PROTECTED] Date: Fri, 9 Feb 2007 18:44:16 +0100 In a prior patch, I introduced a sk_hash field (__sk_common.skc_hash) to let tcp lookups use one cache line per unmatched entry instead of two. We can also use sk_hash to speedup UDP part as well. We store in sk_hash the hnum value, and use sk-sk_hash (same cache line than 'next' pointer), instead of inet-num (different cache line) Note : We still have a false sharing problem for SMP machines, because sock_hold(sock) dirties the cache line containing the 'next' pointer. Not counting the udp_hash_lock rwlock. (did someone mentioned RCU ? :) ) Signed-off-by: Eric Dumazet [EMAIL PROTECTED] Applied, thanks Eric. - 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 0/5]: spidernet: misc fixes
Jeff, A series of five patches against the spidernet ethernet device driver. The first fixes a compile break in the current kernel.rg tree. The second restructures the descriptor ring, per an old suggestion. The third fourth fix a race condition seen under heavy load. The fifth is a trite janitorial patch. Please apply. --linas - 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.21] phylib: Add support for Marvell 88e1111S and 88e1145
From Andy Fleming [EMAIL PROTECTED]
Changes include:
* New support for 88e1145
* New support for 88e111s
* Fixing 88e1101 driver to not match non-88e1101 PHYs
* Increases in feature support across Marvell PHY product line
* Fixes a bunch of whitespace issues found by Lindent
Signed-off-by: Andrew Fleming [EMAIL PROTECTED]
---
This patch seems to have gotten lost. It still applies cleanly, so I'm
resubmitting it for 2.6.21.
drivers/net/phy/marvell.c | 156 ++---
1 files changed, 144 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 0ad2532..5320ab9 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -43,6 +43,19 @@ #define MII_M1011_IMASK 0x12
#define MII_M1011_IMASK_INIT 0x6400
#define MII_M1011_IMASK_CLEAR 0x
+#define MII_M1011_PHY_SCR 0x10
+#define MII_M1011_PHY_SCR_AUTO_CROSS 0x0060
+
+#define MII_M1145_PHY_EXT_CR 0x14
+#define MII_M1145_RGMII_RX_DELAY 0x0080
+#define MII_M1145_RGMII_TX_DELAY 0x0002
+
+#define M1145_DEV_FLAGS_RESISTANCE 0x0001
+
+#define MII_M_PHY_LED_CONTROL 0x18
+#define MII_M_PHY_LED_DIRECT 0x4100
+#define MII_M_PHY_LED_COMBINE 0x411c
+
MODULE_DESCRIPTION(Marvell PHY driver);
MODULE_AUTHOR(Andy Fleming);
MODULE_LICENSE(GPL);
@@ -64,7 +77,7 @@ static int marvell_config_intr(struct ph
{
int err;
- if(phydev-interrupts == PHY_INTERRUPT_ENABLED)
+ if (phydev-interrupts == PHY_INTERRUPT_ENABLED)
err = phy_write(phydev, MII_M1011_IMASK, MII_M1011_IMASK_INIT);
else
err = phy_write(phydev, MII_M1011_IMASK, MII_M1011_IMASK_CLEAR);
@@ -104,34 +117,153 @@ static int marvell_config_aneg(struct ph
if (err 0)
return err;
+ err = phy_write(phydev, MII_M1011_PHY_SCR,
+ MII_M1011_PHY_SCR_AUTO_CROSS);
+ if (err 0)
+ return err;
+
+ err = phy_write(phydev, MII_M_PHY_LED_CONTROL,
+ MII_M_PHY_LED_DIRECT);
+ if (err 0)
+ return err;
err = genphy_config_aneg(phydev);
return err;
}
+static int m88e1145_config_init(struct phy_device *phydev)
+{
+ int err;
+
+ /* Take care of errata E0 E1 */
+ err = phy_write(phydev, 0x1d, 0x001b);
+ if (err 0)
+ return err;
+
+ err = phy_write(phydev, 0x1e, 0x418f);
+ if (err 0)
+ return err;
+
+ err = phy_write(phydev, 0x1d, 0x0016);
+ if (err 0)
+ return err;
+
+ err = phy_write(phydev, 0x1e, 0xa2da);
+ if (err 0)
+ return err;
+
+ if (phydev-interface == PHY_INTERFACE_MODE_RGMII) {
+ int temp = phy_read(phydev, MII_M1145_PHY_EXT_CR);
+ if (temp 0)
+ return temp;
+
+ temp |= (MII_M1145_RGMII_RX_DELAY | MII_M1145_RGMII_TX_DELAY);
+
+ err = phy_write(phydev, MII_M1145_PHY_EXT_CR, temp);
+ if (err 0)
+ return err;
+
+ if (phydev-dev_flags M1145_DEV_FLAGS_RESISTANCE) {
+ err = phy_write(phydev, 0x1d, 0x0012);
+ if (err 0)
+ return err;
+
+ temp = phy_read(phydev, 0x1e);
+ if (temp 0)
+ return temp;
+
+ temp = 0xf03f;
+ temp |= 2 9; /* 36 ohm */
+ temp |= 2 6; /* 39 ohm */
+
+ err = phy_write(phydev, 0x1e, temp);
+ if (err 0)
+ return err;
+
+ err = phy_write(phydev, 0x1d, 0x3);
+ if (err 0)
+ return err;
+
+ err = phy_write(phydev, 0x1e, 0x8000);
+ if (err 0)
+ return err;
+ }
+ }
+
+ return 0;
+}
static struct phy_driver m88e1101_driver = {
- .phy_id = 0x01410c00,
- .phy_id_mask= 0xff00,
- .name = Marvell 88E1101,
- .features = PHY_GBIT_FEATURES,
- .flags = PHY_HAS_INTERRUPT,
- .config_aneg= marvell_config_aneg,
- .read_status= genphy_read_status,
- .ack_interrupt = marvell_ack_interrupt,
- .config_intr= marvell_config_intr,
- .driver = { .owner = THIS_MODULE,},
+ .phy_id = 0x01410c60,
+ .phy_id_mask = 0xfff0,
+ .name = Marvell 88E1101,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg = marvell_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = marvell_ack_interrupt,
+
[PATCH 1/5]: spidernet: compile break.
As of 2.6.20-git4, the spider_net driver does not compile. This appears to be due to some archaic usage involving kobjects. It also fixes a nasty double-free during ifdown of interface. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Jens Osterkamp [EMAIL PROTECTED] Cc: Kou Ishizaki [EMAIL PROTECTED] drivers/net/spider_net.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) Index: linux-2.6.20-git4/drivers/net/spider_net.c === --- linux-2.6.20-git4.orig/drivers/net/spider_net.c 2007-02-09 17:22:35.0 -0600 +++ linux-2.6.20-git4/drivers/net/spider_net.c 2007-02-09 17:24:04.0 -0600 @@ -1906,8 +1906,7 @@ spider_net_stop(struct net_device *netde spider_net_write_reg(card, SPIDER_NET_GHIINT1MSK, 0); spider_net_write_reg(card, SPIDER_NET_GHIINT2MSK, 0); - /* free_irq(netdev-irq, netdev);*/ - free_irq(to_pci_dev(netdev-class_dev.dev)-irq, netdev); + free_irq(netdev-irq, netdev); spider_net_write_reg(card, SPIDER_NET_GDTDMACCNTR, SPIDER_NET_DMA_TX_FEND_VALUE); @@ -1919,8 +1918,6 @@ spider_net_stop(struct net_device *netde spider_net_release_tx_chain(card, 1); spider_net_free_rx_chain_contents(card); - spider_net_free_rx_chain_contents(card); - spider_net_free_chain(card, card-tx_chain); spider_net_free_chain(card, card-rx_chain); - 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] spidernet: separate hardware state from driver state.
This patch separates the hardware descriptor state from the
driver descriptor state, per (old) suggestion from Ben Herrenschmidt.
This compiles and boots and seems to work.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Jens Osterkamp [EMAIL PROTECTED]
Cc: Kou Ishizaki [EMAIL PROTECTED]
drivers/net/spider_net.c | 150 ++-
drivers/net/spider_net.h | 16 +++--
2 files changed, 95 insertions(+), 71 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.h
===
--- linux-2.6.20-git4.orig/drivers/net/spider_net.h 2007-02-09
17:22:15.0 -0600
+++ linux-2.6.20-git4/drivers/net/spider_net.h 2007-02-09 17:29:15.0
-0600
@@ -24,7 +24,7 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
-#define VERSION 1.6 B
+#define VERSION 1.6 C
#include sungem_phy.h
@@ -356,8 +356,8 @@ enum spider_net_int2_status {
#define SPIDER_NET_DESCR_NOT_IN_USE0xF000
#define SPIDER_NET_DESCR_TXDESFLG 0x0080
-struct spider_net_descr {
- /* as defined by the hardware */
+/* Descriptor, as defined by the hardware */
+struct spider_net_hw_descr {
u32 buf_addr;
u32 buf_size;
u32 next_descr_addr;
@@ -366,13 +366,15 @@ struct spider_net_descr {
u32 valid_size; /* all zeroes for tx */
u32 data_status;
u32 data_error; /* all zeroes for tx */
+} __attribute__((aligned(32)));
- /* used in the driver */
+struct spider_net_descr {
+ struct spider_net_hw_descr *hwdescr;
struct sk_buff *skb;
u32 bus_addr;
struct spider_net_descr *next;
struct spider_net_descr *prev;
-} __attribute__((aligned(32)));
+};
struct spider_net_descr_chain {
spinlock_t lock;
@@ -380,6 +382,7 @@ struct spider_net_descr_chain {
struct spider_net_descr *tail;
struct spider_net_descr *ring;
int num_desc;
+ struct spider_net_hw_descr *hwring;
dma_addr_t dma_addr;
};
@@ -452,6 +455,9 @@ struct spider_net_card {
struct net_device_stats netdev_stats;
struct spider_net_extra_stats spider_stats;
struct spider_net_options options;
+
+ /* Must be last item in struct */
+ struct spider_net_descr darray[0];
};
#define pr_err(fmt,arg...) \
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===
--- linux-2.6.20-git4.orig/drivers/net/spider_net.c 2007-02-09
17:24:04.0 -0600
+++ linux-2.6.20-git4/drivers/net/spider_net.c 2007-02-09 17:29:15.0
-0600
@@ -263,9 +263,9 @@ spider_net_get_mac_address(struct net_de
* returns the status as in the dmac_cmd_status field of the descriptor
*/
static inline int
-spider_net_get_descr_status(struct spider_net_descr *descr)
+spider_net_get_descr_status(struct spider_net_hw_descr *hwdescr)
{
- return descr-dmac_cmd_status SPIDER_NET_DESCR_IND_PROC_MASK;
+ return hwdescr-dmac_cmd_status SPIDER_NET_DESCR_IND_PROC_MASK;
}
/**
@@ -283,12 +283,12 @@ spider_net_free_chain(struct spider_net_
descr = chain-ring;
do {
descr-bus_addr = 0;
- descr-next_descr_addr = 0;
+ descr-hwdescr-next_descr_addr = 0;
descr = descr-next;
} while (descr != chain-ring);
dma_free_coherent(card-pdev-dev, chain-num_desc,
- chain-ring, chain-dma_addr);
+ chain-hwring, chain-dma_addr);
}
/**
@@ -307,31 +307,34 @@ spider_net_init_chain(struct spider_net_
{
int i;
struct spider_net_descr *descr;
+ struct spider_net_hw_descr *hwdescr;
dma_addr_t buf;
size_t alloc_size;
- alloc_size = chain-num_desc * sizeof (struct spider_net_descr);
+ alloc_size = chain-num_desc * sizeof(struct spider_net_hw_descr);
- chain-ring = dma_alloc_coherent(card-pdev-dev, alloc_size,
+ chain-hwring = dma_alloc_coherent(card-pdev-dev, alloc_size,
chain-dma_addr, GFP_KERNEL);
- if (!chain-ring)
+ if (!chain-hwring)
return -ENOMEM;
- descr = chain-ring;
- memset(descr, 0, alloc_size);
+ memset(chain-ring, 0, chain-num_desc * sizeof(struct
spider_net_descr));
/* Set up the hardware pointers in each descriptor */
+ descr = chain-ring;
+ hwdescr = chain-hwring;
buf = chain-dma_addr;
- for (i=0; i chain-num_desc; i++, descr++) {
- descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
+ for (i=0; i chain-num_desc; i++, descr++, hwdescr++) {
+ hwdescr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
+ hwdescr-next_descr_addr = 0;
+ descr-hwdescr = hwdescr;
descr-bus_addr = buf;
- descr-next_descr_addr = 0;
descr-next =
[PATCH 4/5]: spidernet: transmit race
Multiple threads performing a transmit can race into
the spidernet tx ring cleanup code. This puts the
relevant check under a lock.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Jens Osterkamp [EMAIL PROTECTED]
Cc: Kou Ishizaki [EMAIL PROTECTED]
drivers/net/spider_net.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===
--- linux-2.6.20-git4.orig/drivers/net/spider_net.c 2007-02-09
17:30:13.0 -0600
+++ linux-2.6.20-git4/drivers/net/spider_net.c 2007-02-09 17:37:41.0
-0600
@@ -767,8 +767,12 @@ spider_net_release_tx_chain(struct spide
unsigned long flags;
int status;
- while (chain-tail != chain-head) {
+ while (1) {
spin_lock_irqsave(chain-lock, flags);
+ if (chain-tail == chain-head) {
+ spin_unlock_irqrestore(chain-lock, flags);
+ return 0;
+ }
descr = chain-tail;
hwdescr = descr-hwdescr;
-
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/5]: spidernet: misc fixes
Janitorial patch. Undo long lines, fix typo in err msg.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Jens Osterkamp [EMAIL PROTECTED]
Cc: Kou Ishizaki [EMAIL PROTECTED]
drivers/net/spider_net.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===
--- linux-2.6.20-git4.orig/drivers/net/spider_net.c 2007-02-09
17:37:41.0 -0600
+++ linux-2.6.20-git4/drivers/net/spider_net.c 2007-02-09 17:40:57.0
-0600
@@ -1017,14 +1017,15 @@ static void show_rx_chain(struct spider_
#endif
/**
- * spider_net_decode_one_descr - processes an rx descriptor
+ * spider_net_decode_one_descr - processes an RX descriptor
* @card: card structure
*
- * Returns 1 if a packet has been sent to the stack, otherwise 0
+ * Returns 1 if a packet has been sent to the stack, otherwise 0.
*
- * Processes an rx descriptor by iommu-unmapping the data buffer and passing
- * the packet up to the stack. This function is called in softirq
- * context, e.g. either bottom half from interrupt or NAPI polling context
+ * Processes an RX descriptor by iommu-unmapping the data buffer
+ * and passing the packet up to the stack. This function is called
+ * in softirq context, e.g. either bottom half from interrupt or
+ * NAPI polling context.
*/
static int
spider_net_decode_one_descr(struct spider_net_card *card)
@@ -1061,7 +1062,7 @@ spider_net_decode_one_descr(struct spide
if ( (status != SPIDER_NET_DESCR_COMPLETE)
(status != SPIDER_NET_DESCR_FRAME_END) ) {
if (netif_msg_rx_err(card))
- pr_err(%s: RX descriptor with unkown state %d\n,
+ pr_err(%s: RX descriptor with unknown state %d\n,
card-netdev-name, status);
card-spider_stats.rx_desc_unk_state++;
goto bad_desc;
-
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]: spidernet janitorial: typos
Resend, The subject line was wrong on the last one.
End-of-day tiredness.
--linas
Janitorial patch. Undo long lines, fix typo in err msg.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Jens Osterkamp [EMAIL PROTECTED]
Cc: Kou Ishizaki [EMAIL PROTECTED]
drivers/net/spider_net.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
Index: linux-2.6.20-git4/drivers/net/spider_net.c
===
--- linux-2.6.20-git4.orig/drivers/net/spider_net.c 2007-02-09
17:37:41.0 -0600
+++ linux-2.6.20-git4/drivers/net/spider_net.c 2007-02-09 17:40:57.0
-0600
@@ -1017,14 +1017,15 @@ static void show_rx_chain(struct spider_
#endif
/**
- * spider_net_decode_one_descr - processes an rx descriptor
+ * spider_net_decode_one_descr - processes an RX descriptor
* @card: card structure
*
- * Returns 1 if a packet has been sent to the stack, otherwise 0
+ * Returns 1 if a packet has been sent to the stack, otherwise 0.
*
- * Processes an rx descriptor by iommu-unmapping the data buffer and passing
- * the packet up to the stack. This function is called in softirq
- * context, e.g. either bottom half from interrupt or NAPI polling context
+ * Processes an RX descriptor by iommu-unmapping the data buffer
+ * and passing the packet up to the stack. This function is called
+ * in softirq context, e.g. either bottom half from interrupt or
+ * NAPI polling context.
*/
static int
spider_net_decode_one_descr(struct spider_net_card *card)
@@ -1061,7 +1062,7 @@ spider_net_decode_one_descr(struct spide
if ( (status != SPIDER_NET_DESCR_COMPLETE)
(status != SPIDER_NET_DESCR_FRAME_END) ) {
if (netif_msg_rx_err(card))
- pr_err(%s: RX descriptor with unkown state %d\n,
+ pr_err(%s: RX descriptor with unknown state %d\n,
card-netdev-name, status);
card-spider_stats.rx_desc_unk_state++;
goto bad_desc;
-
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] zd1211rw: Readd zd_addr_t cast
Robert P.J. Day's recent commit (getting rid of all casts of k[cmz]alloc()
calls) introduced a sparse warning for zd1211rw, related to our type-checking
of addresses.
zd_chip.c:116:15: warning: implicit cast to nocast type
This patch readds the type cast, it is correct.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux/drivers/net/wireless/zd1211rw/zd_chip.c
===
--- linux.orig/drivers/net/wireless/zd1211rw/zd_chip.c
+++ linux/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -113,7 +113,7 @@ int zd_ioread32v_locked(struct zd_chip *
/* Allocate a single memory block for values and addresses. */
count16 = 2*count;
- a16 = kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)),
+ a16 = (zd_addr_t *) kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)),
GFP_NOFS);
if (!a16) {
dev_dbg_f(zd_chip_dev(chip),
-
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/5] NET Improve layering of structs dst_entry/rtable/rt6_info/dn_route to get less dcache footprint
From: Eric Dumazet [EMAIL PROTECTED] Date: Thu, 08 Feb 2007 22:32:10 +0100 I prepared the following five patches : [PATCH 1/5] : Introduce union in struct dst_entry, to prepare patches 2,3,4 [PATCH 2/5] : Convert ipv4 route to use the new dst_entry 'next' pointer [PATCH 3/5] : Convert ipv6 route to use the new dst_entry 'next' pointer [PATCH 4/5] : Convert decnet route to use the new dst_entry 'next' pointer [PATCH 5/5] : Reorder fields of struct dst_entry I've applied all of this, and fixed up the changelog description of patch #4 as-needed :-) Thanks a lot Eric. - 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: Fix code for spec changes of 2/7/2007
On Friday 09 February 2007 20:55, Joseph Jezak wrote: Michael Buesch wrote: On Friday 09 February 2007 20:05, Joseph Jezak wrote: I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware. That's also part of the problem. With the v4 driver, Broadcom dropped support for a number of older BPHY devices (4301/4303 and some 4306 revisions). Do we still want to support those? Should I continue writing the specs for the uCode revision it's based on or should I combine them? If it's easily possible, please try to combine the old stuff with the new v4 specs. I think it's basically only dropped if() branches, right? Well, here's the problem. There are a few places where a value is changed (different value written to a register). Does this mean that the value is different due to the uCode changes (can't tell, no documentation)? Is it applicable to all revisions (can't tell, some revisions are not supported in this version)? If the revision number range in a check changes is that because of a difference in supported cards or a bug fix? So, it's not as simple as just dropped if() branches. I can do my best to combine them (I have done some of this already), but I can't promise that it'll be accurate for all revisions or versions of the chipset. Ok, I see. How many of these old devices exist and who has access to them? If we want to combine stuff, we really must test it on these devices then. -- 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: Fix code for spec changes of 2/7/2007
On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote: My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs by that time, and that maintenance will only require following kernel API changes. Just to make sure I'm understanding this correctly - does the v4 firmware drop compatibility for older cards, or is it just that Broadcom dropped support in the driver at the same time as the firmware changed, and the new firmware will still also drive the old cards? -- Matthew Garrett | [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] bcm43xx: Fix code for spec changes of 2/7/2007
On Fri, Feb 09, 2007 at 09:32:39PM +, Matthew Garrett wrote: On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote: My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs by that time, and that maintenance will only require following kernel API changes. Just to make sure I'm understanding this correctly - does the v4 firmware drop compatibility for older cards, or is it just that Broadcom dropped support in the driver at the same time as the firmware changed, and the new firmware will still also drive the old cards? We can't extract bcm43xx_microcode2.fw from v4 drivers. You need this file for old rev2+3 0x812 cores. So we don't know what firmware we should load into those old cores. I think broadcom never developed a new v4 style firmware for their old hardware. Martin - 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][IPSEC][2/3] IPv6 over IPv4 IPsec tunnel
Hello,
Kazunori MIYAZAWA wrote:
This is the patch to support IPv6 over IPv4 IPsec
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Kazunori Miyazawa [EMAIL PROTECTED]
This seems to break Mobile IPv6 route optimization (RO).
(This patch is commited as c82f963efe823d3cacaf1f1b7f1a35cc9628b188
to David's tree.)
Please find my comment below.
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 8dffd4d..a1ac537 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -131,13 +131,11 @@ __xfrm6_bundle_create(struct xfrm_policy
struct dst_entry *dst, *dst_prev;
struct rt6_info *rt0 = (struct rt6_info*)(*dst_p);
struct rt6_info *rt = rt0;
- struct in6_addr *remote = fl-fl6_dst;
- struct in6_addr *local = fl-fl6_src;
struct flowi fl_tunnel = {
.nl_u = {
.ip6_u = {
- .saddr = *local,
- .daddr = *remote
+ .saddr = fl-fl6_src,
+ .daddr = fl-fl6_dst,
}
}
};
@@ -153,7 +151,6 @@ __xfrm6_bundle_create(struct xfrm_policy
for (i = 0; i nx; i++) {
struct dst_entry *dst1 = dst_alloc(xfrm6_dst_ops);
struct xfrm_dst *xdst;
- int tunnel = 0;
if (unlikely(dst1 == NULL)) {
err = -ENOBUFS;
@@ -177,19 +174,27 @@ __xfrm6_bundle_create(struct xfrm_policy
dst1-next = dst_prev;
dst_prev = dst1;
- if (xfrm[i]-props.mode != XFRM_MODE_TRANSPORT) {
- remote = __xfrm6_bundle_addr_remote(xfrm[i], remote);
- local = __xfrm6_bundle_addr_local(xfrm[i], local);
- tunnel = 1;
- }
+
__xfrm6_bundle_len_inc(header_len, nfheader_len, xfrm[i]);
trailer_len += xfrm[i]-props.trailer_len;
- if (tunnel) {
- ipv6_addr_copy(fl_tunnel.fl6_dst, remote);
- ipv6_addr_copy(fl_tunnel.fl6_src, local);
- err = xfrm_dst_lookup((struct xfrm_dst **) rt,
- fl_tunnel, AF_INET6);
+ if (xfrm[i]-props.mode == XFRM_MODE_TUNNEL) {
+ unsigned short encap_family = xfrm[i]-props.family;
+ switch(encap_family) {
+ case AF_INET:
+ fl_tunnel.fl4_dst = xfrm[i]-id.daddr.a4;
+ fl_tunnel.fl4_src = xfrm[i]-props.saddr.a4;
+ break;
+ case AF_INET6:
+ ipv6_addr_copy(fl_tunnel.fl6_dst, (struct
in6_addr*)xfrm[i]-id.daddr.a6);
+ ipv6_addr_copy(fl_tunnel.fl6_src, (struct
in6_addr*)xfrm[i]-props.saddr.a6);
+ break;
+ default:
+ BUG_ON(1);
+ }
+
+ err = xfrm_dst_lookup((struct xfrm_dst **) rt,
+ fl_tunnel, encap_family);
if (err)
goto error;
} else
You missed RO mode path when you changed semantics to check the mode
from xfrm[i]-props.mode != XFRM_MODE_TRANSPORT
to xfrm[i]-props.mode == XFRM_MODE_TUNNEL before
changing address. Your patch also makes two incline functions
__xfrm6_bundle_addr_{remote,local} are used by nobody.
I suggest a fix to add || xfrm[i]-props.mode == XFRM_MODE_ROUTEOPTIMIZATION
there
to make it clearer for other developers about RO-is-there than restoring the
code.
# FYI, we don't have to fix another side of inter-family IPsec tunneling
(xfrm4_policy.c)
# where you have similar patch (IPv4 over IPv6 IPsec tunnel) because the RO
# is used only for the case of IPv6 flow and IPv6 extension headers.
Please give me comments for the attached patch.
I hope it will be applied (or replaced the original patch with including mine).
Regards,
--
Masahide NAKAMURA
From ce9f1ac8c8df22b462a15d4609d05ec939930208 Mon Sep 17 00:00:00 2001
From: Masahide NAKAMURA [EMAIL PROTECTED]
Date: Sat, 10 Feb 2007 11:48:49 +0900
Subject: [PATCH][XFRM] IPV6: Fix outbound RO transformation which is broken by
IPsec tunnel patch.
It seems to miss RO mode path by IPv6 over IPv4 IPsec tunnel patch
when it changed semantics to check the mode from
xfrm[i]-props.mode != XFRM_MODE_TRANSPORT to
xfrm[i]-props.mode == XFRM_MODE_TUNNEL before changing address.
It also makes two incline functions __xfrm6_bundle_addr_{remote,local}
are used by nobody.
This patch fixes it.
Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED]
---
net/ipv6/xfrm6_policy.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git
Re: [RFC][PATCH][IPSEC][2/3] IPv6 over IPv4 IPsec tunnel
From: Masahide NAKAMURA [EMAIL PROTECTED] Date: Sat, 10 Feb 2007 12:25:33 +0900 Please give me comments for the attached patch. I hope it will be applied (or replaced the original patch with including mine). Thank you Mashide, I've applied your patch for now. If anyone wants to provide some corrections, we can make them on top of Mashide's version of the fix. Thank you! - 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] zd1211rw: Readd zd_addr_t cast
On Saturday 10 February 2007 02:27, Daniel Drake wrote: Robert P.J. Day's recent commit (getting rid of all casts of k[cmz]alloc() calls) introduced a sparse warning for zd1211rw, related to our type-checking of addresses. zd_chip.c:116:15: warning: implicit cast to nocast type This patch readds the type cast, it is correct. Signed-off-by: Daniel Drake [EMAIL PROTECTED] Index: linux/drivers/net/wireless/zd1211rw/zd_chip.c === --- linux.orig/drivers/net/wireless/zd1211rw/zd_chip.c +++ linux/drivers/net/wireless/zd1211rw/zd_chip.c @@ -113,7 +113,7 @@ int zd_ioread32v_locked(struct zd_chip * /* Allocate a single memory block for values and addresses. */ count16 = 2*count; - a16 = kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)), + a16 = (zd_addr_t *) kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)), GFP_NOFS); Unrelated, but I am wondering since quite some time why you pass GFP_NOFS here. Any special reason? I think in general there is no good reason for code outside of the VFS to use this flag. IMHO you should pass either GFP_ATOMIC or GFP_KERNEL. - 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.21-rc1] ehea: Fixed error recovery
Error recovery for QP errors: Reset QPs and dump error information
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c |8 +++-
drivers/net/ehea/ehea_phyp.c | 10 ++
drivers/net/ehea/ehea_phyp.h |3 +++
drivers/net/ehea/ehea_qmr.c | 42 ++
drivers/net/ehea/ehea_qmr.h |5 +
6 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 272e1ec..42295d6 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include asm/abs_addr.h
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0045
+#define DRV_VERSIONEHEA_0046
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9de2d38..1ef3846 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -76,7 +76,7 @@ void ehea_dump(void *adr, int len, char
int x;
unsigned char *deb = adr;
for (x = 0; x len; x += 16) {
- printk(DRV_NAME %s adr=%p ofs=%04x %016lx %016lx\n, msg,
+ printk(DRV_NAME %s adr=%p ofs=%04x %016lx %016lx\n, msg,
deb, x, *((u64*)deb[0]), *((u64*)deb[8]));
deb += 16;
}
@@ -555,6 +555,7 @@ static irqreturn_t ehea_qp_aff_irq_handl
{
struct ehea_port *port = param;
struct ehea_eqe *eqe;
+ struct ehea_qp *qp;
u32 qp_token;
eqe = ehea_poll_eq(port-qp_eq);
@@ -563,9 +564,14 @@ static irqreturn_t ehea_qp_aff_irq_handl
qp_token = EHEA_BMASK_GET(EHEA_EQE_QP_TOKEN, eqe-entry);
ehea_error(QP aff_err: entry=0x%lx, token=0x%x,
eqe-entry, qp_token);
+
+ qp = port-port_res[qp_token].qp;
+ ehea_error_data(port-adapter, qp-fw_handle);
eqe = ehea_poll_eq(port-qp_eq);
}
+ queue_work(port-adapter-ehea_wq, port-reset_task);
+
return IRQ_HANDLED;
}
diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 37716e0..bc3c005 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -612,3 +612,13 @@ u64 ehea_h_reset_events(const u64 adapte
event_mask, /* R6 */
0, 0, 0, 0); /* R7-R12 */
}
+
+u64 ehea_h_error_data(const u64 adapter_handle, const u64 ressource_handle,
+ void *rblock)
+{
+ return ehea_plpar_hcall_norets(H_ERROR_DATA,
+ adapter_handle, /* R4 */
+ ressource_handle,/* R5 */
+ virt_to_abs(rblock), /* R6 */
+ 0, 0, 0, 0); /* R7-R12 */
+}
diff --git a/drivers/net/ehea/ehea_phyp.h b/drivers/net/ehea/ehea_phyp.h
index 919f94b..90acddb 100644
--- a/drivers/net/ehea/ehea_phyp.h
+++ b/drivers/net/ehea/ehea_phyp.h
@@ -454,4 +454,7 @@ u64 ehea_h_reg_dereg_bcmc(const u64 adap
u64 ehea_h_reset_events(const u64 adapter_handle, const u64 neq_handle,
const u64 event_mask);
+u64 ehea_h_error_data(const u64 adapter_handle, const u64 ressource_handle,
+ void *rblock);
+
#endif /* __EHEA_PHYP_H__ */
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index f143e13..96ff3b6 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -486,6 +486,7 @@ int ehea_destroy_qp(struct ehea_qp *qp)
if (!qp)
return 0;
+ ehea_h_disable_and_get_hea(qp-adapter-handle, qp-fw_handle);
hret = ehea_h_free_resource(qp-adapter-handle, qp-fw_handle);
if (hret != H_SUCCESS) {
ehea_error(destroy_qp failed);
@@ -581,4 +582,45 @@ out:
return ret;
}
+void print_error_data(u64 *data)
+{
+ int length;
+ u64 type = EHEA_BMASK_GET(ERROR_DATA_TYPE, data[2]);
+ u64 resource = data[1];
+
+ length = EHEA_BMASK_GET(ERROR_DATA_LENGTH, data[0]);
+
+ if (length EHEA_PAGESIZE)
+ length = EHEA_PAGESIZE;
+
+ if (type == 0x8) /* Queue Pair */
+ ehea_error(QP (resource=%lX) state: AER=0x%lX, AERR=0x%lX,
+ port=%lX, resource, data[6], data[12], data[22]);
+
+ ehea_dump(data, length, error data);
+}
+
+void ehea_error_data(struct ehea_adapter *adapter, u64 res_handle)
+{
+ unsigned long ret;
+ u64 *rblock;
+
+ rblock = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!rblock) {
+ ehea_error(Cannot allocate rblock memory.);
+ return;
+ }
+ ret = ehea_h_error_data(adapter-handle,
+
Re: Network: convert network devices to use struct device instead of class_device
On Thu, 2007-02-08 at 22:59 -0500, Dmitry Torokhov wrote: On Thursday 08 February 2007 19:56, Greg KH wrote: On Thu, Feb 08, 2007 at 12:29:12PM -0500, Dmitry Torokhov wrote: On 2/8/07, Stephen Hemminger [EMAIL PROTECTED] wrote: On Thu, 08 Feb 2007 07:43:18 -0500 Network: convert network devices to use struct device instead of class_device This lets the network core have the ability to handle suspend/resume issues, if it wants to. It fixes a non-problem. I would like to see the network core suspend/resume proposal as well. Last time I examined doing network core suspend help, the problem was that the physical device suspend was called before the class device. It is not clear how this change would help. If physical devices are registered before class devices then when suspending class devices are naturally suspended first. It is still not clear to me why we need to convert everythign to struct device, I believe I've shown (with patches) that it is possible to integrate struct class_device into PM framework and avoid reshuffling half of the kernel code. I don't want to have two separate device trees in the kernel (well, one big device tree and a bunch of little class_device trees.) The code duplication in the class_device code is just too much, and I get questions all the time as to what the differences are. While duplication of code is a real concern my worry is constant fattening of struct device. For example most physical devices do not interface directly with userspace but every single one of them now has dev_t. Former class_devices do not need suspend/resume early framework either. And so on, and so forth. The dev_t is a good example for the mess we try to fix here. Not having a dev_t for devices lead to the creation of a lot of otherwise completely useless class devices which are just a total pain to interpret, and follow the events they create, from userspace. Things like the scsi_device devices, usb_device devices, ... just exist, because only this type of devices was allowed to pass information for device nodes to userspace. Thanks, Kay - 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] [ipv6]: adjust inet6_exit() cleanup sequence against inet6_init()
Hi,
This patch for adjust inet6_exit() to inverse sequence to inet6_init().
At ipv6_init, it first create proc_root/net/dev_snmp6 entry by call
ipv6_misc_proc_init(), then call addrconf_init() to create the corresponding
device entry at this directory, but at inet6_exit, ipv6_misc_proc_exit()
called first, then call addrconf_init().
Signed-off-by: Joe Jin [EMAIL PROTECTED]
--- linux-2.6.20/net/ipv6/af_inet6.c.orig 2007-02-09 14:05:10.0
+0800
+++ linux-2.6.20/net/ipv6/af_inet6.c2007-02-09 14:21:54.0 +0800
@@ -930,25 +930,28 @@
{
/* First of all disallow new sockets creation. */
sock_unregister(PF_INET6);
-#ifdef CONFIG_PROC_FS
- if6_proc_exit();
- ac6_proc_exit();
- ipv6_misc_proc_exit();
- udp6_proc_exit();
- udplite6_proc_exit();
- tcp6_proc_exit();
- raw6_proc_exit();
-#endif
+
+ /* Cleanup code parts. */
+ ipv6_packet_cleanup();
#ifdef CONFIG_IPV6_MIP6
mip6_fini();
#endif
- /* Cleanup code parts. */
- ip6_flowlabel_cleanup();
addrconf_cleanup();
+ ip6_flowlabel_cleanup();
ip6_route_cleanup();
- ipv6_packet_cleanup();
- igmp6_cleanup();
+#ifdef CONFIG_PROC_FS
+
+ /* Cleanup code parts. */
+ if6_proc_exit();
+ ac6_proc_exit();
+ ipv6_misc_proc_exit();
+ udplite6_proc_exit();
+ udp6_proc_exit();
+ tcp6_proc_exit();
+ raw6_proc_exit();
+#endif
ipv6_netfilter_fini();
+ igmp6_cleanup();
ndisc_cleanup();
icmpv6_cleanup();
#ifdef CONFIG_SYSCTL
@@ -956,6 +959,7 @@
#endif
cleanup_ipv6_mibs();
proto_unregister(rawv6_prot);
+ proto_unregister(udplitev6_prot);
proto_unregister(udpv6_prot);
proto_unregister(tcpv6_prot);
}
-
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: forcedeth problems on 2.6.20-rc6-mm3
Tobias Diedrich wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
--- linux-2.6.20/drivers/net/forcedeth.c.orig 2007-02-09 13:02:02.0
+0100
+++ linux-2.6.20/drivers/net/forcedeth.c.new2007-02-09 13:03:45.0
+0100
@@ -2603,10 +2603,16 @@
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
unsigned long flags;
+ u32 retcode;
- pkts = nv_rx_process(dev, limit);
+ if (np-desc_ver == DESC_VER_1 || np-desc_ver == DESC_VER_2) {
+ pkts = nv_rx_process(dev, limit);
+ retcode = nv_alloc_rx(dev);
+ } else {
+ retcode = nv_alloc_rx_optimized(dev);
+ }
- if (nv_alloc_rx(dev)) {
+ if (retcode) {
spin_lock_irqsave(np-lock, flags);
if (!np-in_shutdown)
mod_timer(np-oom_kick, jiffies + OOM_REFILL);
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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: forcedeth problems on 2.6.20-rc6-mm3
Ayaz Abdulla wrote: For all those who are having issues, please try out the attached patch. Will try. I reverted to 2.6.19 w/o suspend/resume patch last weekend to make sure on 2.6.19 forcedeth is stable and noticed something odd: Because I didn't include the suspend/resume patch I obviously had to a down/rmmod/modprobe/up cycle after each resume and I noticed that the behaviour seems to alternate between resumes: Behaviour 1: After modprobe I get two interface 'eth0' and 'eth1' for the two ports, as expected. Behaviour 2: After modprobe I get one interface 'eth3' (which should be 'eth1') and one interface with increasing numbers (which should be 'eth0', last resume it was 'eth12' IIRC). As I said if I get behaviour 1 on one resume I get behaviour 2 on the next resume and vice versa. That seems rather odd to me. On a not quite related note, forcedeth shows a different ethtool output (compared to e100), when no cable is connected to the port: forcedeth, no cable connected: |Settings for eth1: | Supported ports: [ MII ] | Supported link modes: 10baseT/Half 10baseT/Full | 100baseT/Half 100baseT/Full | 1000baseT/Full | Supports auto-negotiation: Yes | Advertised link modes: 10baseT/Half 10baseT/Full | 100baseT/Half 100baseT/Full | 1000baseT/Full | Advertised auto-negotiation: Yes | Speed: Unknown! (65535) | Duplex: Unknown! (255) | Port: MII | PHYAD: 1 | Transceiver: external | Auto-negotiation: on | Supports Wake-on: g | Wake-on: d | Link detected: no e100, no cable connected: |Settings for eth0: |Supported ports: [ TP MII ] |Supported link modes: 10baseT/Half 10baseT/Full |100baseT/Half 100baseT/Full |Supports auto-negotiation: Yes |Advertised link modes: 10baseT/Half 10baseT/Full |100baseT/Half 100baseT/Full |Advertised auto-negotiation: Yes |Speed: 10Mb/s |Duplex: Half |Port: MII |PHYAD: 1 |Transceiver: internal |Auto-negotiation: on |Supports Wake-on: g |Wake-on: g |Current message level: 0x0007 (7) |Link detected: no Note that e100 returns the lowest possible speed if no link is detected, while forcedeth seems to return -1, which ethtool doesn't seem to recognise as a valid response (I guess, why else would it show the number after 'Unknown!'). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: forcedeth problems on 2.6.20-rc6-mm3
Tobias Diedrich wrote: Tobias Diedrich wrote: Ayaz Abdulla wrote: For all those who are having issues, please try out the attached patch. Will try. Does not apply cleanly against 2.6.20, is this one fixed up right? It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3. IOW, the forcedeth changes in question are not in 2.6.20, and you need to apply the patch on top of the latest batch of forcedeth changes. 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: Network: convert network devices to use struct device instead of class_device
On 2/9/07, Kay Sievers [EMAIL PROTECTED] wrote: On Thu, 2007-02-08 at 22:59 -0500, Dmitry Torokhov wrote: On Thursday 08 February 2007 19:56, Greg KH wrote: On Thu, Feb 08, 2007 at 12:29:12PM -0500, Dmitry Torokhov wrote: On 2/8/07, Stephen Hemminger [EMAIL PROTECTED] wrote: On Thu, 08 Feb 2007 07:43:18 -0500 Network: convert network devices to use struct device instead of class_device This lets the network core have the ability to handle suspend/resume issues, if it wants to. It fixes a non-problem. I would like to see the network core suspend/resume proposal as well. Last time I examined doing network core suspend help, the problem was that the physical device suspend was called before the class device. It is not clear how this change would help. If physical devices are registered before class devices then when suspending class devices are naturally suspended first. It is still not clear to me why we need to convert everythign to struct device, I believe I've shown (with patches) that it is possible to integrate struct class_device into PM framework and avoid reshuffling half of the kernel code. I don't want to have two separate device trees in the kernel (well, one big device tree and a bunch of little class_device trees.) The code duplication in the class_device code is just too much, and I get questions all the time as to what the differences are. While duplication of code is a real concern my worry is constant fattening of struct device. For example most physical devices do not interface directly with userspace but every single one of them now has dev_t. Former class_devices do not need suspend/resume early framework either. And so on, and so forth. The dev_t is a good example for the mess we try to fix here. Not having a dev_t for devices lead to the creation of a lot of otherwise completely useless class devices which are just a total pain to interpret, and follow the events they create, from userspace. Things like the scsi_device devices, usb_device devices, ... just exist, because only this type of devices was allowed to pass information for device nodes to userspace. I admit I do not know scsi stack but I would expect that the only things that need dev_t there would be sd, sr and sg interfaces. As such they are separate entities and deserve their own structures no mater what. I can bet that number of real devices that need dev_t is smaller than number of virtual devices that do not need full power management: PCI cards, ACPI tree, etc, etc - hardware devices interfacing with other parts of the kernel, not userspace directly. NET, input, tty, etc - no need to suspend late/resume early And, btw, having separate device and struct device does not prevent exporting them as a unified sysfs tree and is in fact pretty easy to do (I believe I posted patches to do that as well). -- Dmitry - 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] kill eth_io_copy_and_sum()
On all targets that sucker boils down to memcpy_fromio(sbk-data, from, len).
The function name is highly misguiding (it _never_ does any checksums), the
last argument is just a noise and simply expanding the call to memcpy_fromio()
gives shorter and more readable source. For a lot of reasons it has almost
no remaining users, so it's better to just outright kill it.
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
drivers/net/3c503.c |3 +--
drivers/net/ac3200.c |3 +--
drivers/net/e2100.c |3 +--
drivers/net/es3210.c |2 +-
drivers/net/smc-mca.c|3 +--
drivers/net/smc-ultra.c |3 +--
drivers/net/smc-ultra32.c|3 +--
drivers/net/wd.c |2 +-
include/asm-alpha/io.h |9 -
include/asm-arm/arch-ixp4xx/io.h |3 ---
include/asm-arm/io.h |5 -
include/asm-cris/io.h|5 -
include/asm-i386/io.h|6 --
include/asm-mips/io.h|6 --
include/asm-parisc/io.h |9 -
include/asm-ppc/io.h |2 --
include/asm-x86_64/io.h |6 --
17 files changed, 8 insertions(+), 65 deletions(-)
diff --git a/drivers/net/3c503.c b/drivers/net/3c503.c
index 7e34c4f..bc7e906 100644
--- a/drivers/net/3c503.c
+++ b/drivers/net/3c503.c
@@ -600,8 +600,7 @@ el2_block_input(struct net_device *dev, int count, struct
sk_buff *skb, int ring
count -= semi_count;
memcpy_fromio(skb-data + semi_count, base + ei_status.priv, count);
} else {
- /* Packet is in one chunk -- we can copy + cksum. */
- eth_io_copy_and_sum(skb, base + ring_offset, count, 0);
+ memcpy_fromio(skb-data, base + ring_offset, count);
}
return;
}
diff --git a/drivers/net/ac3200.c b/drivers/net/ac3200.c
index c01f87f..644c408 100644
--- a/drivers/net/ac3200.c
+++ b/drivers/net/ac3200.c
@@ -327,8 +327,7 @@ static void ac_block_input(struct net_device *dev, int
count, struct sk_buff *sk
memcpy_fromio(skb-data + semi_count,
ei_status.mem + TX_PAGES*256, count);
} else {
- /* Packet is in one chunk -- we can copy + cksum. */
- eth_io_copy_and_sum(skb, start, count, 0);
+ memcpy_fromio(skb-data, start, count);
}
}
diff --git a/drivers/net/e2100.c b/drivers/net/e2100.c
index c62d9c6..b2b0a96 100644
--- a/drivers/net/e2100.c
+++ b/drivers/net/e2100.c
@@ -355,8 +355,7 @@ e21_block_input(struct net_device *dev, int count, struct
sk_buff *skb, int ring
mem_on(ioaddr, shared_mem, (ring_offset8));
- /* Packet is always in one chunk -- we can copy + cksum. */
- eth_io_copy_and_sum(skb, ei_status.mem + (ring_offset 0xff), count,
0);
+ memcpy_fromio(skb-data, ei_status.mem + (ring_offset 0xff), count);
mem_off(ioaddr);
}
diff --git a/drivers/net/es3210.c b/drivers/net/es3210.c
index 2d2ea94..822e5bf 100644
--- a/drivers/net/es3210.c
+++ b/drivers/net/es3210.c
@@ -375,7 +375,7 @@ static void es_block_input(struct net_device *dev, int
count, struct sk_buff *sk
memcpy_fromio(skb-data + semi_count, ei_status.mem, count);
} else {
/* Packet is in one chunk. */
- eth_io_copy_and_sum(skb, xfer_start, count, 0);
+ memcpy_fromio(skb-data, xfer_start, count);
}
}
diff --git a/drivers/net/smc-mca.c b/drivers/net/smc-mca.c
index 7122932..ae1ae34 100644
--- a/drivers/net/smc-mca.c
+++ b/drivers/net/smc-mca.c
@@ -482,8 +482,7 @@ static void ultramca_block_input(struct net_device *dev,
int count, struct sk_bu
count -= semi_count;
memcpy_fromio(skb-data + semi_count, ei_status.mem + TX_PAGES
* 256, count);
} else {
- /* Packet is in one chunk -- we can copy + cksum. */
- eth_io_copy_and_sum(skb, xfer_start, count, 0);
+ memcpy_fromio(skb-data, xfer_start, count);
}
}
diff --git a/drivers/net/smc-ultra.c b/drivers/net/smc-ultra.c
index d70bc97..a52b22d 100644
--- a/drivers/net/smc-ultra.c
+++ b/drivers/net/smc-ultra.c
@@ -454,8 +454,7 @@ ultra_block_input(struct net_device *dev, int count, struct
sk_buff *skb, int ri
count -= semi_count;
memcpy_fromio(skb-data + semi_count, ei_status.mem + TX_PAGES
* 256, count);
} else {
- /* Packet is in one chunk -- we can copy + cksum. */
- eth_io_copy_and_sum(skb, xfer_start, count, 0);
+ memcpy_fromio(skb-data, xfer_start, count);
}
outb(0x00, dev-base_addr - ULTRA_NIC_OFFSET); /* Disable memory. */
diff --git a/drivers/net/smc-ultra32.c b/drivers/net/smc-ultra32.c
index 2c5319c..88a30e5 100644
--- a/drivers/net/smc-ultra32.c
+++ b/drivers/net/smc-ultra32.c
@@ -395,8 +395,7 @@ static
Re: Network: convert network devices to use struct device instead of class_device
On Thu, Feb 08, 2007 at 10:59:46PM -0500, Dmitry Torokhov wrote: On Thursday 08 February 2007 19:56, Greg KH wrote: On Thu, Feb 08, 2007 at 12:29:12PM -0500, Dmitry Torokhov wrote: On 2/8/07, Stephen Hemminger [EMAIL PROTECTED] wrote: On Thu, 08 Feb 2007 07:43:18 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43cb76d91ee85f579a69d42bc8efc08bac560278 Commit: 43cb76d91ee85f579a69d42bc8efc08bac560278 Parent: 2943ecf2ed32632473c06f1975db47a7aa98c10f Author: Greg Kroah-Hartman [EMAIL PROTECTED] AuthorDate: Tue Apr 9 12:14:34 2002 -0700 Committer: Greg Kroah-Hartman [EMAIL PROTECTED] CommitDate: Wed Feb 7 10:37:11 2007 -0800 Network: convert network devices to use struct device instead of class_device This lets the network core have the ability to handle suspend/resume issues, if it wants to. It fixes a non-problem. I would like to see the network core suspend/resume proposal as well. Last time I examined doing network core suspend help, the problem was that the physical device suspend was called before the class device. It is not clear how this change would help. If physical devices are registered before class devices then when suspending class devices are naturally suspended first. It is still not clear to me why we need to convert everythign to struct device, I believe I've shown (with patches) that it is possible to integrate struct class_device into PM framework and avoid reshuffling half of the kernel code. I don't want to have two separate device trees in the kernel (well, one big device tree and a bunch of little class_device trees.) The code duplication in the class_device code is just too much, and I get questions all the time as to what the differences are. While duplication of code is a real concern my worry is constant fattening of struct device. For example most physical devices do not interface directly with userspace but every single one of them now has dev_t. Former class_devices do not need suspend/resume early framework either. And so on, and so forth. The memory requirements of 'struct device' is trivial in the overall system requirements. Now this doesn't mean we need to go crazy with adding everything and the kitchen sink to the structure, but adding a dev_t is not going to make any difference to anyone. thanks, greg k-h - 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][RESEND] gianfar: Convert network devices to use struct device instead of class_device
Kumar Gala wrote: Convert network devices to use struct device instead of class_device. Greg missed this one in his cleanup path. Signed-off-by: Kumar Gala [EMAIL PROTECTED] OK, but doesn't apply to torvalds/linux-2.6.git ... 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: [PATCH 2.6.21-rc1] ehea: Fixed error recovery
Jan-Bernd Themann wrote: Error recovery for QP errors: Reset QPs and dump error information Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED] applied - 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
[ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Please hold all questions until I am done with this email. Thank you. We are pleased to announce the availability of a new driver for the Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver uses the new d80211 subsystem previously only available as part of the wireless-dev tree. You can find the new driver, and additional information about it, here: http://intellinuxwireless.org/iwlwifi. Within the new driver package are sources which we plan to submit for kernel inclusion as well as scripts and patches which create a version of the driver which can be loaded into kernels based on 2.6.18 and newer (provided you have installed the d80211 subsystem as well) The README document can walk you through pretty quickly. Since a lot of our users are not able to move to the latest versions of the Linux kernel, we have put together a d80211 package allowing the installation of the d80211 subsystem into an existing kernel image without the need to migrate to wireless-dev, or upgrade to a newer kernel at all (assuming you are using 2.6.18 or newer). You can find that package at: http://intellinuxwireless.org/d80211 Ok. Now... any questions? Thanks, James / Intel Corporation - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On 2/9/07, James Ketrenos [EMAIL PROTECTED] wrote: Ok. Now... any questions? No... Just that it is great news! Best Regards, Alon Bar-Lev. - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Friday February 9, [EMAIL PROTECTED] wrote: Ok. Now... any questions? Yes. Does this require a closed user-space helper like the other 3945ABG driver, or is it completely open (maybe excepting firmware)? Thanks, NeilBrown - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Neil Brown wrote: On Friday February 9, [EMAIL PROTECTED] wrote: Ok. Now... any questions? Yes. Does this require a closed user-space helper like the other 3945ABG driver, or is it completely open (maybe excepting firmware)? The iwlwifi driver for the 3945 does not require the user space daemon, but does require a new microcode image. Over the past year we were able to make the necessary changes to the microcode used with the 3945 such that we were able to remove the regulatory daemon. James - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Hello. On Sat, 2007-02-10 at 09:26, Neil Brown wrote: On Friday February 9, [EMAIL PROTECTED] wrote: Ok. Now... any questions? Yes. Does this require a closed user-space helper like the other 3945ABG driver, or is it completely open (maybe excepting firmware)? Quote from the mentioned website: In addition to using the new d80211 subsystem, this project uses a new microcode image which removes the need for the user space regulatory daemon for this adapter regards Stefan Schmidt signature.asc Description: Digital signature
