Re: [RFC] memory barrier cleanups
From: Ralf Baechle [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 21:49:46 + I believe all the below memory barriers only matter on SMP so therefore the smp_* variant of the barrier should be used. I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be dropped entirely. schedule_work's implementation currently implies a memory barrier and I think sane semantics of schedule_work() should imply a memory barrier, as needed so the caller shouldn't have to worry. It's not quite obvious why the barrier in net/packet/af_packet.c is needed; maybe it should be implied through flush_dcache_page? Ralf Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Ok, Ralf this looks good, and I think your suspicions are correct about the timewait case, I'll just delete that memory barrier. I put it there and aparently for now justifiable reason :-) - 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 6/7][TG3]: Use msleep.
From: Michael Chan [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:47:17 -0800 [TG3]: Use msleep. Change some udelay() in some eeprom functions to msleep(). Eeprom related functions are always called from sleepable context. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied. Thanks for continuing to work on eliminating these long udelay()s. - 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 7/7][TG3]: Identify Serdes devices more clearly.
From: Michael Chan [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:47:23 -0800 [TG3]: Identify Serdes devices more clearly. Change the message to more clearly identify Serdes devices. Update version to 3.70. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied. Thanks 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 1/7][TG3]: Fix Phy loopback.
From: Michael Chan [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:46:06 -0800 [TG3]: Fix Phy loopback. Phy loopback on most 10/100 devices need to be run in 1Gbps mode in GMII mode. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, thanks 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 3/7][TG3]: Add TG3_FLG2_IS_NIC flag.
From: Michael Chan [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:46:29 -0800 [TG3]: Add TG3_FLG2_IS_NIC flag. Add Tg3_FLG2_IS_NIC flag to unambiguously determine whether the device is NIC or onboard. Previously, the EEPROM_WRITE_PROT flag was overloaded to also mean onboard. With the separation, we can support some devices that are onboard but do not use eeprom write protect. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, 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 5/7][TG3]: Use netif_msg_*.
From: Michael Chan [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:47:11 -0800 [TG3]: Use netif_msg_*. Use netif_msg_* to turn on or off some messages. Based on Stephen Hemminger's initial patch. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, 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/7][TG3]: Add 5787F device ID.
From: Michael Chan [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:46:25 -0800 [TG3]: Add 5787F device ID. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, 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 4/7][TG3]: Allow partial speed advertisement.
From: Michael Chan [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:46:47 -0800 [TG3]: Allow partial speed advertisement. Honor the advertisement bitmask from ethtool. We used to always advertise the full capability when autoneg was set to on. Signed-off-by: Michael Chan [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
Re: [PATCH 7/7][TG3]: Identify Serdes devices more clearly.
Michael Chan wrote: [TG3]: Identify Serdes devices more clearly. Change the message to more clearly identify Serdes devices. Update version to 3.70. ACK patches 1-7 - 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: NAPI and shared interrupt control
From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Thu, 07 Dec 2006 15:24:06 +1100 What Eugene does currently, which seems to me like it's actually the only proper solution, is to create a separate net_device structure for the DMA engine and thus have a single NAPI poll weighting for all the EMACs sharing a given MAL (MAL is the name of that DMA engine). This means that Rx from any of the channels schedules the poll, and interrupts can be properly masked/unmasked globally based on the presence/absence of work on all the channels. Actually, another solution would be to have one of the instances do the NAPI poll for all of them instead of creating a separate net_device for the DMA engine... I think this idea would work the best. Just link the other related devices into a list in the driver private struct. Or a simple work pending bitmask for each of the EMACs, which tell the primary EMAC netdev which devices should be polled. This architecture doesn't make things easy, that's for sure :-) If things get too hairy, don't feel too bad about ideas like forgoing NAPI altogether and just using the interrupt mitigation features of the chip. Does it have any? - 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] netfilter: fix non-ANSI func. decl.
From: Randy Dunlap [EMAIL PROTECTED] Date: Tue, 5 Dec 2006 19:37:13 -0800 From: Randy Dunlap [EMAIL PROTECTED] Fix non-ANSI function declaration: net/netfilter/nf_conntrack_core.c:1096:25: warning: non-ANSI function declaration of function 'nf_conntrack_flush' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Applied, thanks Randy. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAPI and shared interrupt control
On Thu, Dec 07, 2006 at 01:16:27AM -0800, David Miller wrote: From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Thu, 07 Dec 2006 15:24:06 +1100 What Eugene does currently, which seems to me like it's actually the only proper solution, is to create a separate net_device structure for the DMA engine and thus have a single NAPI poll weighting for all the EMACs sharing a given MAL (MAL is the name of that DMA engine). This means that Rx from any of the channels schedules the poll, and interrupts can be properly masked/unmasked globally based on the presence/absence of work on all the channels. Actually, another solution would be to have one of the instances do the NAPI poll for all of them instead of creating a separate net_device for the DMA engine... I think this idea would work the best. I fail to see how this is not even more ugly and more complex than the solution we have right now. Instead of trivial orthogonal polling code you are suggesting adding additional complexity - handle dynamic selection of that master EMAC and also handling situation when this master device goes down and you have to switch to another one without disturbing polling for other active devices. Why all this? This hw is ugly enough as it is. Just link the other related devices into a list in the driver private struct. Or a simple work pending bitmask for each of the EMACs, which tell the primary EMAC netdev which devices should be polled. This architecture doesn't make things easy, that's for sure :-) If things get too hairy, don't feel too bad about ideas like forgoing NAPI altogether and just using the interrupt mitigation features of the chip. Does it have any? No, it does not. -- Eugene - 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/RFC] make MII and PHYLIB independent of NET_ETHERNET
Randy Dunlap wrote: On Thu, 30 Nov 2006 06:10:14 -0500 Jeff Garzik wrote: ACK, but patch doesn't apply to #upstream Does it work to patch -mm instead? (below) --- From: Randy Dunlap [EMAIL PROTECTED] PHYLIB can be used by non-NET_ETHERNET (10/100 ethernet) devices; e.g., GIANFAR (gigabit) uses it. We also have USB ethernet devices trying to use MII without NET_ETHERNET being enabled, so move MII outside of NET_ETHERNET, along with PHYLIB. They both still depend on NET NETDEVICES. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] still didn't apply - 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: NAPI and shared interrupt control
From: Eugene Surovegin [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 01:45:02 -0800 I fail to see how this is not even more ugly and more complex than the solution we have right now. Instead of trivial orthogonal polling code you are suggesting adding additional complexity - handle dynamic selection of that master EMAC and also handling situation when this master device goes down and you have to switch to another one without disturbing polling for other active devices. Why all this? This hw is ugly enough as it is. Don't do dynamic selection, that indeed would be dumb. Instead, just pick one of them to act as the polling master. Each EMAC has a backpointer to the master EMAC, and trigger the poll via that indirection. With this shared interrupt scheme and lack of hw interrupt mitigation, how did the designers of this chip expect people to do interrupt mitigation? I suppose they expected you to do it by standing on your head :-) - 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] netxen: sparse warning and ioctl bug fixes
Stephen Hemminger wrote: Fix sparse warnings and get rid of casts that hide misuse of __user pointers. There were two real bugs here: * ioctl was copying uninitialized stack om NETXEN_NIC_NAME * ioctl was dereferencing a user pointer in nettxen_nic_cmd_clear_stats. IMHO the ioctl usage in this driver is going to be more maintenance burden than useful. and should be removed. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] ACK but netxen is in heavy flux right now, with upstream workqueue changes, changes from Amit, etc. so, it didn't apply. Ever considered submitting via 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: Please pull 'upstream' branch of wireless-2.6
John W. Linville wrote: The following changes since commit e62438630ca37539c8cc1553710bbfaa3cf960a7: Matthew Wilcox: Centralise definitions of sector_t and blkcnt_t are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream pulled, but there were workqueue-related conflicts. let me know if #upstream doesn't match what you would like. - 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] Pull request for 'r8169-upstream-20061204-00' tag
Francois Romieu wrote: Please pull from tag 'r8169-upstream-20061204-00' in repository git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git#r8169-upstream-20061204-00 pulled. please change your please pull email message to reflect something I can cut-n-paste directly to the command line. For tags, this would be $url tag $tag. 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 3/16] Spidernet RX Locking
Linas Vepstas wrote: The RX packet handling can be called from several places, yet does not protect the rx ring structure. This patch places the ring buffer pointers under a lock. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] This is a HUGELY invasive patch. A sledgehammer. What /specifically/ are these several places, and what other non-sledgehammer approaches were discarded before arriving at this one? 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: NAPI and shared interrupt control
On Thu, Dec 07, 2006 at 01:59:54AM -0800, David Miller wrote: From: Eugene Surovegin [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 01:45:02 -0800 I fail to see how this is not even more ugly and more complex than the solution we have right now. Instead of trivial orthogonal polling code you are suggesting adding additional complexity - handle dynamic selection of that master EMAC and also handling situation when this master device goes down and you have to switch to another one without disturbing polling for other active devices. Why all this? This hw is ugly enough as it is. Don't do dynamic selection, that indeed would be dumb. Instead, just pick one of them to act as the polling master. Each EMAC has a backpointer to the master EMAC, and trigger the poll via that indirection. Well, dev_close() explicitly checks and modifies state bits related to NAPI polling. From quick look I don't think it's safe to take down master device and expect NAPI polling to still work. With this shared interrupt scheme and lack of hw interrupt mitigation, how did the designers of this chip expect people to do interrupt mitigation? I suppose they expected you to do it by standing on your head :-) There are more fun stuff in this hw - max buffer size is around 4080 bytes so we have to split packets on TX and assemble on RX (meaning doing memcpy) for jumbo frames. You have to reset MAC on almost every register change, etc -- Eugene - 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: NAPI and shared interrupt control
On Thu, Dec 07, 2006 at 02:20:10AM -0800, David Miller wrote: It also just occured to me that even if you use the dummy device approach, it's the dummy device's quota that will be used by the generic -poll() downcall into the driver. Yes, that's true. That's why I made this parameter Konfig-configurable. Yes, this is not as flexible as run-time configuration available for a real netdev, but better than nothing and nobody has complained yet :) -- Eugene - 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: Kernel header changes break glibc build
* David Miller [EMAIL PROTECTED] 2006-12-06 16:56 That's enough for me. Thomas we need to restore things to how they were before. If that means including if_addr.h from rtnetlink.h so be it. We can't break shit like this, there are no excuses, especially now that we properly frob the headers for userspace consumption in the kernel tree. So you want to restore IFLA_RTA/IFLA_PAYLOAD etc. as well? - 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: Kernel header changes break glibc build
From: Thomas Graf [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 11:47:21 +0100 * David Miller [EMAIL PROTECTED] 2006-12-06 16:56 That's enough for me. Thomas we need to restore things to how they were before. If that means including if_addr.h from rtnetlink.h so be it. We can't break shit like this, there are no excuses, especially now that we properly frob the headers for userspace consumption in the kernel tree. So you want to restore IFLA_RTA/IFLA_PAYLOAD etc. as well? Just fixup the if_addr.h include for now. - 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
[NETLINK]: Restore API compatibility of address and neighbour bits
Restore API compatibility due to bits moved from rtnetlink.h to separate headers. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/include/linux/rtnetlink.h === --- net-2.6.orig/include/linux/rtnetlink.h 2006-12-07 11:25:29.0 +0100 +++ net-2.6/include/linux/rtnetlink.h 2006-12-07 11:32:25.0 +0100 @@ -3,6 +3,8 @@ #include linux/netlink.h #include linux/if_link.h +#include linux/if_addr.h +#include linux/neighbour.h / * Routing/neighbour discovery messages. - 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: NAPI and shared interrupt control
On Thu, 2006-12-07 at 02:22 -0800, Eugene Surovegin wrote: On Thu, Dec 07, 2006 at 02:20:10AM -0800, David Miller wrote: It also just occured to me that even if you use the dummy device approach, it's the dummy device's quota that will be used by the generic -poll() downcall into the driver. Yes, that's true. That's why I made this parameter Konfig-configurable. Yes, this is not as flexible as run-time configuration available for a real netdev, but better than nothing and nobody has complained yet :) Can we maybe change the dummy device weight as emacs get added to a MAL ? Dave, the main point of my initial email was: should we provide a routine from the net core to initialize such dummy devices properly ? I'm a little worried that some day, the NAPI code will change and the initialisations done by the driver will not be enough anymore... Cheers, Ben. - 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: [NETLINK]: Restore API compatibility of address and neighbour bits
On Thu, 2006-12-07 at 11:55 +0100, Thomas Graf wrote: Restore API compatibility due to bits moved from rtnetlink.h to separate headers. For 2.6.19.1 too, please. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/include/linux/rtnetlink.h === --- net-2.6.orig/include/linux/rtnetlink.h2006-12-07 11:25:29.0 +0100 +++ net-2.6/include/linux/rtnetlink.h 2006-12-07 11:32:25.0 +0100 @@ -3,6 +3,8 @@ #include linux/netlink.h #include linux/if_link.h +#include linux/if_addr.h +#include linux/neighbour.h / * Routing/neighbour discovery messages. - 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 -- dwmw2 - 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: Kernel header changes break glibc build
On Wed, 2006-12-06 at 15:23 +0100, Thomas Graf wrote: I'm suggesting that if you want to change things around as you did, you should make sure the users of those headers adapt to cope. You did fix the in-kernel users; you neglected to fix glibc -- and as far as I can tell you didn't even bother to _warn_ glibc folks. I didn't warn them because I didn't know better. Fair enough. Now you do -- and thanks for fixing it. I was under the impression that glibc still maintains their own set of headers and will fix this automatically when they look at the diff. That's what I do for my userspace applications that use kernel headers. That's never been the case for glibc. As I said, various people have _attempted_ to do it, but it really isn't a workable approach and the results were wildly inconsistent. Having a single, centrally-exported set of headers is a massive improvement -- but yes, it does mean we have to take a little care with what we're exporting to userspace. Ideally install_headers would do the trick but it often fails f.e. when some application which uses bsd features thus including net/if.h also wants to use new linux features and includes linux/if.h which then conflicts. Applications in general shouldn't be doing that -- kernel headers are for system libraries and tools only. We should try to ensure that the _sensible_ use cases don't break, but we don't have to go overboard with keeping our namespace clean and anticipating _every_ strange thing which a userspace app might do with our headers -- we still get to say 'caveat emptor'; it's just that we can't be _quite_ as haphazard about it as we've been in the past. -- dwmw2 - 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 7/7] d80211: do not pass an invalid key index to set_key()
On Wed, 6 Dec 2006 16:45:40 -0800, David Kimdon wrote:
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -612,7 +612,7 @@ static int ieee80211_set_encryption(stru
if (alg == ALG_NONE) {
keyconf = NULL;
- if (try_hwaccel key local-ops-set_key
+ if (try_hwaccel key key-hw_key_idx != -1
local-ops-set_key
Use HW_KEY_IDX_INVALID, please.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 5/7] d80211: remove unused references to sub interface data
On Wed, 2006-12-06 at 16:45 -0800, David Kimdon wrote: plain text document attachment (unused-sdata.patch) In these three cases the pointer returned by IEEE80211_DEV_TO_SUB_IF() is never used. Good catch, I must have introduced this when converting the prototypes. Thanks. johannes signature.asc Description: This is a digitally signed message part
Re: [patch 6/7] d80211: fix invalid check for sub interface type AP
Patches 1 to 6 have been applied to my tree. Thanks, Jiri On Wed, 6 Dec 2006 16:45:32 -0800, David Kimdon wrote: We should be checking the type member, not the raw pointer. Signed-off-by: David Kimdon [EMAIL PROTECTED] -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: change spinlocks and remove timers in favor of workqueues
On 12/7/06, Jay Vosburgh [EMAIL PROTECTED] wrote: I don't see a problem in starting with your patch; the end state will be sufficiently different (e.g., the four workqueues would ultimately be consolidated into one) that it's still a good testbed to start with. My patch actually only uses a single workqueue for each bond (almost exactly like yours in-fact) with 4 different types of work that can be placed on it. The only other minor issue is that after this week, I will be off for the holidays (and far, far away from email) for the next month. Good to know. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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] softmac: Fixed handling of deassociation from AP
On Thursday 07 December 2006 01:36, Larry Finger wrote: it seems to me that the mutex protects only the association data; whereas the spinlock protects more data, but does include the association data. Nope. The same way you could argue that the BKL should be taken here, as it's the global kernel lock which protects everything. But it's simply not true and won't protect anything. ;) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] prism54: set carrier flags correctly
prism54 should set the carrier flags correctly when it thinks the link can be
used.
Signed-off-by: Roy Marples [EMAIL PROTECTED]
--- a/drivers/net/wireless/prism54/isl_ioctl.c 2006-08-24 10:48:50.0
+0100
+++ b/drivers/net/wireless/prism54/isl_ioctl.c 2006-08-24 10:29:32.0
+0100
@@ -1573,8 +1573,11 @@
} else
send_simple_event(netdev_priv(ndev),
Link established);
- } else
+ netif_carrier_on(ndev);
+ } else {
send_simple_event(netdev_priv(ndev), Link lost);
+ netif_carrier_off(ndev);
+ }
}
/* Beacon/ProbeResp payload header */
--- a/drivers/net/wireless/prism54/islpci_dev.c 2006-08-24 10:48:50.0
+0100
+++ b/drivers/net/wireless/prism54/islpci_dev.c 2006-08-24 10:30:31.0
+0100
@@ -387,7 +387,9 @@
}
netif_start_queue(ndev);
-/* netif_mark_up( ndev ); */
+
+ /* Turn off carrier unless we know we have associated */
+ netif_carrier_off(ndev);
return 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
Re: [patch 7/7] d80211: do not pass an invalid key index to set_key()
Use HW_KEY_IDX_INVALID, please.
oops, here you go (also fixed bad indentation):
--
d80211: do not pass an invalid key index to set_key()
If a hardware key has not been configured then there is no point
to calling DISABLE_KEY.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -612,7 +612,9 @@ static int ieee80211_set_encryption(stru
if (alg == ALG_NONE) {
keyconf = NULL;
- if (try_hwaccel key local-ops-set_key
+ if (try_hwaccel key
+ key-hw_key_idx != HW_KEY_IDX_INVALID
+ local-ops-set_key
(keyconf = ieee80211_key_data2conf(local, key)) != NULL
local-ops-set_key(local_to_hw(local), DISABLE_KEY,
sta_addr, keyconf, sta ? sta-aid : 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
Re: [PATCH 2.6.19] AT91RM9200 Ethernet update 3
On 05 Dec 2006 09:29:52 +0200 Andrew Victor [EMAIL PROTECTED] wrote: hi Stephen, Use netdev_alloc_skb instead. It sets skb-dev so you don't have to. netdev_alloc_skb() seems to cause 2 function calls [__netdev_alloc_skb() and __alloc_skb()], instead of just 1 for the dev_alloc_skb() case. It might be more efficient if the driver manually sets skb-dev. That is trivial, and netdev_alloc_skb() is setup to handle other issues in future. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/16] Spidernet DMA coalescing
On Wed, Dec 06, 2006 at 11:08:47PM -0800, Andrew Morton wrote: It worries me when a patch series gets resent a few hours later. Did anything change? I did not resend this patch series. However, I did receive a large number of MTA errors: [EMAIL PROTECTED]: mail forwarding loop for [EMAIL PROTECTED] which might be related to what you saw. (I also cc'ed several lists, and delivry on one of the lists may have been delayed by a few hours??) --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
Marvell Libertas wifi
I just wanted to check on the status of the libertas driver from Marvell for the OLPC project. I haven't really been able to find out much about this driver other than the commits to the olpc and infradead libertas git trees. The olpc laptop uses the usb interface and that seems to be what is supported at the moment (although some comments in the code allude to pci and sdio interfaces as well). Does anyone know what the plan is for merging this driver into mainline? What about pci support? Did Marvell donate any code for the PCI interface? If not how hard would it be to add PCI support? I requested databooks from Marvell months ago, but never got anywhere. I'd like to see better support for this chip and would be willing to help out. Any updates would be much appreciated. Thanks, Alex PS, please CC: me on replies as I'm not on this list. - 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 3/16] Spidernet RX Locking
On Thu, Dec 07, 2006 at 05:09:20AM -0500, Jeff Garzik wrote: Linas Vepstas wrote: The RX packet handling can be called from several places, yet does not protect the rx ring structure. This patch places the ring buffer pointers under a lock. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] This is a HUGELY invasive patch. A sledgehammer. I am rather unlear what you perceive as being invasive, since the patch summary states: drivers/net/spider_net.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) What /specifically/ are these several places, spider_net_decode_one_descr() is called from spider_net_poll() (which is the netdev-poll callback) and also from spider_net_handle_rxram_full(). The rxramfull routine is called from a tasklet that is fired off after a RX ram full interrupt is receved. This interrupt is generated when the hardware runs out of space to store incoming packets. We are seeing this interrupt fire when the CPU is heavily loaded, and a lot of traffic is being fired at the device. and what other non-sledgehammer approaches were discarded before arriving at this one? Well, I'm not that good at kernel programming, so I guess I did not perceive this as a sledgehammer. And alternative approach is to simply ignore the rxramfull interrupt entirely, and depend on poll() do all the work. I'll try this shortly. --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] convert hh_lock to seqlock
The hard header cache is in the main output path, so using
seqlock instead of reader/writer lock should reduce overhead.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
include/linux/netdevice.h |2 +-
include/net/neighbour.h | 18 ++
net/core/neighbour.c | 11 ++-
net/ipv4/ip_output.c | 14 +++---
net/ipv6/ip6_output.c | 15 +++
5 files changed, 31 insertions(+), 29 deletions(-)
--- linux-2.6.19.orig/include/linux/netdevice.h 2006-12-05 13:55:54.0
-0800
+++ linux-2.6.19/include/linux/netdevice.h 2006-12-06 10:29:15.0
-0800
@@ -199,7 +199,7 @@
*/
u16 hh_len; /* length of header */
int (*hh_output)(struct sk_buff *skb);
- rwlock_thh_lock;
+ seqlock_t hh_lock;
/* cached hardware header; allow for machine alignment needs.*/
#define HH_DATA_MOD16
--- linux-2.6.19.orig/include/net/neighbour.h 2006-12-05 13:36:16.0
-0800
+++ linux-2.6.19/include/net/neighbour.h2006-12-06 14:53:52.0
-0800
@@ -309,6 +309,24 @@
return 0;
}
+static inline int neigh_hh_output(struct hh_cache *hh, struct sk_buff *skb)
+{
+ unsigned seq;
+ int hh_len;
+
+ do {
+ int hh_alen;
+
+ seq = read_seqbegin(hh-hh_lock);
+ hh_len = hh-hh_len;
+ hh_alen = HH_DATA_ALIGN(hh_len);
+ memcpy(skb-data - hh_alen, hh-hh_data, hh_alen);
+ } while (read_seqretry(hh-hh_lock, seq));
+
+ skb_push(skb, hh_len);
+ return hh-hh_output(skb);
+}
+
static inline struct neighbour *
__neigh_lookup(struct neigh_table *tbl, const void *pkey, struct net_device
*dev, int creat)
{
--- linux-2.6.19.orig/net/core/neighbour.c 2006-12-05 13:55:54.0
-0800
+++ linux-2.6.19/net/core/neighbour.c 2006-12-06 10:29:15.0 -0800
@@ -577,9 +577,10 @@
while ((hh = neigh-hh) != NULL) {
neigh-hh = hh-hh_next;
hh-hh_next = NULL;
- write_lock_bh(hh-hh_lock);
+
+ write_seqlock_bh(hh-hh_lock);
hh-hh_output = neigh_blackhole;
- write_unlock_bh(hh-hh_lock);
+ write_sequnlock_bh(hh-hh_lock);
if (atomic_dec_and_test(hh-hh_refcnt))
kfree(hh);
}
@@ -897,9 +898,9 @@
if (update) {
for (hh = neigh-hh; hh; hh = hh-hh_next) {
- write_lock_bh(hh-hh_lock);
+ write_seqlock_bh(hh-hh_lock);
update(hh, neigh-dev, neigh-ha);
- write_unlock_bh(hh-hh_lock);
+ write_sequnlock_bh(hh-hh_lock);
}
}
}
@@ -1089,7 +1090,7 @@
break;
if (!hh (hh = kzalloc(sizeof(*hh), GFP_ATOMIC)) != NULL) {
- rwlock_init(hh-hh_lock);
+ seqlock_init(hh-hh_lock);
hh-hh_type = protocol;
atomic_set(hh-hh_refcnt, 0);
hh-hh_next = NULL;
--- linux-2.6.19.orig/net/ipv4/ip_output.c 2006-12-05 13:55:54.0
-0800
+++ linux-2.6.19/net/ipv4/ip_output.c 2006-12-06 10:29:15.0 -0800
@@ -164,7 +164,6 @@
static inline int ip_finish_output2(struct sk_buff *skb)
{
struct dst_entry *dst = skb-dst;
- struct hh_cache *hh = dst-hh;
struct net_device *dev = dst-dev;
int hh_len = LL_RESERVED_SPACE(dev);
@@ -183,16 +182,9 @@
skb = skb2;
}
- if (hh) {
- int hh_alen;
-
- read_lock_bh(hh-hh_lock);
- hh_alen = HH_DATA_ALIGN(hh-hh_len);
- memcpy(skb-data - hh_alen, hh-hh_data, hh_alen);
- read_unlock_bh(hh-hh_lock);
- skb_push(skb, hh-hh_len);
- return hh-hh_output(skb);
- } else if (dst-neighbour)
+ if (dst-hh)
+ return neigh_hh_output(dst-hh, skb);
+ else if (dst-neighbour)
return dst-neighbour-output(skb);
if (net_ratelimit())
--- linux-2.6.19.orig/net/ipv6/ip6_output.c 2006-12-05 13:55:54.0
-0800
+++ linux-2.6.19/net/ipv6/ip6_output.c 2006-12-06 10:33:24.0 -0800
@@ -72,20 +72,11 @@
static inline int ip6_output_finish(struct sk_buff *skb)
{
-
struct dst_entry *dst = skb-dst;
- struct hh_cache *hh = dst-hh;
-
- if (hh) {
- int hh_alen;
- read_lock_bh(hh-hh_lock);
- hh_alen = HH_DATA_ALIGN(hh-hh_len);
- memcpy(skb-data - hh_alen, hh-hh_data, hh_alen);
- read_unlock_bh(hh-hh_lock);
- skb_push(skb, hh-hh_len);
- return hh-hh_output(skb);
- } else if (dst-neighbour)
+ if (dst-hh)
+ return neigh_hh_output(dst-hh, skb);
+
[PATCH 1/2] ucc_geth: compilation error fixes
Fix compilation failures when building the ucc_geth driver with spinlock
debugging.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
drivers/net/ucc_geth.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 1f05511..62d979b 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -194,9 +194,9 @@ static void enqueue(struct list_head *no
{
unsigned long flags;
- spin_lock_irqsave(ugeth_lock, flags);
+ spin_lock_irqsave(ugeth_lock, flags);
list_add_tail(node, lh);
- spin_unlock_irqrestore(ugeth_lock, flags);
+ spin_unlock_irqrestore(ugeth_lock, flags);
}
#endif /* CONFIG_UGETH_FILTERING */
@@ -204,14 +204,14 @@ static struct list_head *dequeue(struct
{
unsigned long flags;
- spin_lock_irqsave(ugeth_lock, flags);
+ spin_lock_irqsave(ugeth_lock, flags);
if (!list_empty(lh)) {
struct list_head *node = lh-next;
list_del(node);
- spin_unlock_irqrestore(ugeth_lock, flags);
+ spin_unlock_irqrestore(ugeth_lock, flags);
return node;
} else {
- spin_unlock_irqrestore(ugeth_lock, flags);
+ spin_unlock_irqrestore(ugeth_lock, flags);
return NULL;
}
}
--
1.4.2.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ucc_geth: Initialize mdio_lock.
Signed-off-by: Scott Wood [EMAIL PROTECTED] --- drivers/net/ucc_geth.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index 62d979b..8243150 100644 --- a/drivers/net/ucc_geth.c +++ b/drivers/net/ucc_geth.c @@ -1852,6 +1852,8 @@ static int init_phy(struct net_device *d mii_info-mdio_read = read_phy_reg; mii_info-mdio_write = write_phy_reg; + spin_lock_init(mii_info-mdio_lock); + ugeth-mii_info = mii_info; spin_lock_irq(ugeth-lock); -- 1.4.2.3 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Wed, 06 Dec 2006 23:24:59 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Amit S. Kale [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 11:55:22 +0530 We can let a driver handle dma mapping errors using these- 1.Reduce the size of a receive ring. This will free some possibly remapped memory, reducing pressure on iommu. We also need to printk a message so that a user knows the reason why receive ring was shrunk. Growing it when iommu pressure goes down will result in a ping-pong. 2. Force processing of receive and transmit ring. This will ensure that the buffers processed by hardware are freed, reducing iommu pressure. 3. If we need to do (1) and (2) a predefined number of times (say 20), stop the queue. Stopping the queue in general will cause a ping-pong, so it should be avoided as far as possible. This scheme assumes the networking card is the culprit. In many workloads it will not be and these efforts will be in vain and perhaps even make the situation worse. There's not reason to run the RX and TX queues, and even shrink them, when the FC controller has most of the IOMMU entires tied up. That's why users needs to queue up and get feedback when IOMMU space is made available. Looking at other subsystems, the disk code seems to return I/O errors if dma mapping fails. Perhaps this discussion needs to move off to lkml or the platform lists. - 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] bonding: change spinlocks and remove timers in favor of workqueues
Andy Gospodarek [EMAIL PROTECTED] wrote: [...] My patch actually only uses a single workqueue for each bond (almost exactly like yours in-fact) with 4 different types of work that can be placed on it. Well, what I was trying to say was that there are still multiple independently scheduled thingies on the workqueue (although you can't ever have all of them going at the same time), whereas in the Big Patch, there's only one scheduled thingie on the workqueue, and everything is dispatched from within its single handler (making it less complicated to pause all of the timers for mutual exclusion purposes). -J --- -Jay Vosburgh, IBM Linux Technology Center, [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] convert hh_lock to seqlock
Stephen Hemminger a écrit : The hard header cache is in the main output path, so using seqlock instead of reader/writer lock should reduce overhead. Nice work Stephen, I am very interested. Did you benchmarked it ? I ask because I think hh_refcnt frequent changes may defeat the gain you want (ie avoiding cache line ping pongs between cpus). seqlock are definitly better than rwlock, but if we really keep cache lines shared. So I would suggest reordering fields of hh_cache and adding one cacheline_aligned_in_smp to keep hh_refcnt in another cache line. (hh_len, hh_lock and hh_data should be placed on a 'mostly read' cache line) Thank you 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] convert hh_lock to seqlock
On Thu, 07 Dec 2006 21:23:07 +0100 Eric Dumazet [EMAIL PROTECTED] wrote: Stephen Hemminger a écrit : The hard header cache is in the main output path, so using seqlock instead of reader/writer lock should reduce overhead. Nice work Stephen, I am very interested. Did you benchmarked it ? I ask because I think hh_refcnt frequent changes may defeat the gain you want (ie avoiding cache line ping pongs between cpus). seqlock are definitly better than rwlock, but if we really keep cache lines shared. So I would suggest reordering fields of hh_cache and adding one cacheline_aligned_in_smp to keep hh_refcnt in another cache line. (hh_len, hh_lock and hh_data should be placed on a 'mostly read' cache line) Thank you Eric It doesn't make any visible performance difference for real networks; copies and device issues are much larger. The hh_refcnt is used only when creating destroying neighbor entries, so except under DoS attack it doesn't make a lot of difference. The hh_lock is used on each packet sent. - 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: Marvell Libertas wifi
On Thu, 2006-12-07 at 12:32 -0500, Alex Deucher wrote: I just wanted to check on the status of the libertas driver from Marvell for the OLPC project. I haven't really been able to find out The driver needs quite a bit of love. It's only been used for embedded devices so far and has quite a few NDIS-isms sprinkled throughout. It's also something like 30,000 LoC, which is completely bogus. There's no reason it should be that large given that it's a FullMAC-type part. We're slowly working on cleaning it up for submission to the kernel. That process will probably take until after the holidays. We are removing unused code/defines, cleaning up WEXT compliance, making operations like association and scanning asynchronous, converting private IOCTLs to debugfs, fixing the power-saving code, and adding draft 802.11s wireless mesh functionality to the firmware and the driver. Are you developing a device based on the 8388? AFAIK, the chip does not appear in any consumer devices that are generally available to the public, and certainly isn't sold to Linksys or DLink for consumer USB dongles. It does show up in embedded situations like the Nokia N80 mobile phone and a few other small gadgets like that. much about this driver other than the commits to the olpc and infradead libertas git trees. The olpc laptop uses the usb interface Correct; the 8388 module is connected directly to the USB traces coming out of the 5536 Geode companion chip on the OLPC motherboard. and that seems to be what is supported at the moment (although some comments in the code allude to pci and sdio interfaces as well). Does Yes; the part evidently has other interface variants, though code for those variants was not provided in the initial driver sources which Marvell GPL-ed in April. anyone know what the plan is for merging this driver into mainline? What about pci support? Did Marvell donate any code for the PCI interface? If not how hard would it be to add PCI support? I No code for PCI was donated, and we don't have any 8388 PCI cards at OLPC. requested databooks from Marvell months ago, but never got anywhere. I'd like to see better support for this chip and would be willing to help out. Any updates would be much appreciated. Be aware that I _think_ there are a few chips in the Libertas line; we are using the 8388. The current driver only supports that specific part. That said, if you've got hardware, we'd love patches, certainly accept patches that provided PCI support and fixed bugs in the driver. We may also be able to provide USB 8388 reference dongles for people willing to help out with the development of the driver. Cheers, Dan Thanks, Alex PS, please CC: me on replies as I'm not on this list. - 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: [PATCH]: Fix netpoll arp_reply for multiple routers
Chris Lalancette wrote:
All,
Attached is a patch to fix arp_reply when you have multiple possible
routers doing ARP requests to you. Currently arp_reply always replies to the
MAC address that it was given when it starts. However, if you have multiple
routers that can ARP request you, you might respond to the wrong router; in
which case the other router will eventually drop you from it's ARP cache and
stop delivering packets to you. The fix is to always reply to the router
that asked you, not the one you have hard-coded.
I do not have the setup to test this; the customer that does have the
setup has tested the patch and reports that it fixes the problems they were
having.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 3c58846..5833b21 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -331,6 +331,7 @@ static void arp_reply(struct sk_buff *sk
unsigned char *arp_ptr;
int size, type = ARPOP_REPLY, ptype = ETH_P_ARP;
__be32 sip, tip;
+ unsigned char *sha;
struct sk_buff *send_skb;
struct netpoll *np = NULL;
@@ -357,9 +358,14 @@ static void arp_reply(struct sk_buff *sk
arp-ar_op != htons(ARPOP_REQUEST))
return;
- arp_ptr = (unsigned char *)(arp+1) + skb-dev-addr_len;
+ arp_ptr = (unsigned char *)(arp+1);
+ /* save the location of the src hw addr */
+ sha = arp_ptr;
+ arp_ptr += skb-dev-addr_len;
memcpy(sip, arp_ptr, 4);
- arp_ptr += 4 + skb-dev-addr_len;
+ arp_ptr += 4;
+ /* if we actually cared about dst hw addr, it would get copied here */
+ arp_ptr += skb-dev-addr_len;
memcpy(tip, arp_ptr, 4);
/* Should we ignore arp? */
@@ -382,7 +388,7 @@ static void arp_reply(struct sk_buff *sk
if (np-dev-hard_header
np-dev-hard_header(send_skb, skb-dev, ptype,
- np-remote_mac, np-local_mac,
+ sha, np-local_mac,
send_skb-len) 0) {
kfree_skb(send_skb);
return;
@@ -406,7 +412,7 @@ static void arp_reply(struct sk_buff *sk
arp_ptr += np-dev-addr_len;
memcpy(arp_ptr, tip, 4);
arp_ptr += 4;
- memcpy(arp_ptr, np-remote_mac, np-dev-addr_len);
+ memcpy(arp_ptr, sha, np-dev-addr_len);
arp_ptr += np-dev-addr_len;
memcpy(arp_ptr, sip, 4);
All,
Sorry for the confusion...this was already picked up by akpm on linux-net.
Please don't take the patch.
Thanks,
Chris Lalancette
-
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/7] inter address family ipsec tunnel
From: Kazunori MIYAZAWA [EMAIL PROTECTED] Date: Thu, 07 Dec 2006 20:23:48 +0900 David Miller wrote: From: David Miller [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:37:49 -0800 (PST) From: Kazunori MIYAZAWA [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 20:35:37 +0900 BTW, I have a question about descrementing the reference count of rt-peer. The reference cound in normal dst structure is decremented by calling inet_putpeer from ipv4_dst_destroy. But xfrm4_dst_destroy does not call inet_putpeer. Where do we decrement the count? Should xfrm4_dst_destroy do that? Indeed, it is a real leak. And yes, I believe that xfrm4_dst_destroy() should release it. I will make this fix, thank you. For reference, this is the fix I checked in. Thanks again for spotting this problem. Thank you for making the patch. Will it be merged to 2.6.19.x? Yes, I submitted it to -stable last night and Chris W. just queued it up for the -stable branches (even 2.6.18.x etc.) - 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] convert hh_lock to seqlock
Stephen Hemminger a écrit : On Thu, 07 Dec 2006 21:23:07 +0100 Eric Dumazet [EMAIL PROTECTED] wrote: Stephen Hemminger a écrit : The hard header cache is in the main output path, so using seqlock instead of reader/writer lock should reduce overhead. Nice work Stephen, I am very interested. Did you benchmarked it ? I ask because I think hh_refcnt frequent changes may defeat the gain you want (ie avoiding cache line ping pongs between cpus). seqlock are definitly better than rwlock, but if we really keep cache lines shared. So I would suggest reordering fields of hh_cache and adding one cacheline_aligned_in_smp to keep hh_refcnt in another cache line. (hh_len, hh_lock and hh_data should be placed on a 'mostly read' cache line) Thank you Eric It doesn't make any visible performance difference for real networks; copies and device issues are much larger. Hum, so 'my' machines must be unreal :) The hh_refcnt is used only when creating destroying neighbor entries, so except under DoS attack it doesn't make a lot of difference. The hh_lock is used on each packet sent. Some machines create/delete 10.000 entries per second in rt_cache. I believe they are real. DoS ? you tell it, some people wont agree. # grep eth0 /proc/net/rt_cache|head -n 1|cut -f13|sort -u|wc -l 359 (13th field of /proc/net/rt_cache is HHRef) # rtstat -c1000 -i1 rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache| entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| || tot| mc| ute|| an_dst| an_src| |_tot| _mc|| ed|miss| verflow| _search|t_search| 2467048|2479640328|1334812199| 0| 0| 34| 0| 117112|6139056109|7510556324| 0| 0| 0| 0| 0|8864696485|9819074477| 2465642| 16594|4791| 0| 0| 0| 0| 0| 2387|2738| 0| 0| 0| 0| 0| 21878|7478| 2464482| 16505|4765| 0| 0| 0| 0| 0| 2460|2669| 0| 0| 0| 0| 0| 4|7499| 2463512| 17281|4640| 0| 0| 0| 0| 0| 2449|2632| 0| 0| 0| 0| 0| 22069|7240| 2462651| 16504|4314| 0| 0| 0| 0| 0| 2446|2497| 0| 0| 0| 0| 0| 20796|6979| 2462175| 18152|5792| 0| 0| 0| 0| 0| 2448|2791| 0| 0| 0| 0| 0| 26164|7731| 2461889| 16970|5059| 0| 0| 0| 0| 0| 2535|2829| 0| 0| 0| 0| 0| 22614|7595| 2461719| 16446|4643| 0| 0| 0| 0| 0| 2496|2717| 0| 0| 0| 0| 0| 21347|7354| 2461775| 17098|4782| 0| 0| 0| 0| 0| 2386|2570| 0| 0| 0| 0| 0| 22448|7049| Thank you 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/RFC] make MII and PHYLIB independent of NET_ETHERNET
still didn't apply --- From: Randy Dunlap [EMAIL PROTECTED] PHYLIB can be used by non-NET_ETHERNET (10/100 ethernet) devices; e.g., GIANFAR (gigabit) uses it. We also have USB ethernet devices trying to use MII without NET_ETHERNET being enabled, so move MII outside of NET_ETHERNET, along with PHYLIB. They both still depend on NET NETDEVICES. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/net/Kconfig | 16 drivers/net/phy/Kconfig | 21 + 2 files changed, 13 insertions(+), 24 deletions(-) --- netdev-ups.orig/drivers/net/Kconfig +++ netdev-ups/drivers/net/Kconfig @@ -145,6 +145,14 @@ config NET_SB1000 source drivers/net/arcnet/Kconfig +config MII + tristate Generic Media Independent Interface device support + depends on NET_ETHERNET + help + Most ethernet controllers have MII transceiver either as an external + or internal device. It is safe to say Y or M here even if your + ethernet card lack MII. + source drivers/net/phy/Kconfig # @@ -180,14 +188,6 @@ config NET_ETHERNET kernel: saying N will just cause the configurator to skip all the questions about Ethernet network cards. If unsure, say N. -config MII - tristate Generic Media Independent Interface device support - depends on NET_ETHERNET - help - Most ethernet controllers have MII transceiver either as an external - or internal device. It is safe to say Y or M here even if your - ethernet card lack MII. - config MACB tristate Atmel MACB support depends on NET_ETHERNET AVR32 --- netdev-ups.orig/drivers/net/phy/Kconfig +++ netdev-ups/drivers/net/phy/Kconfig @@ -2,69 +2,59 @@ # PHY Layer Configuration # -menu PHY device support - -config PHYLIB +menuconfig PHYLIB tristate PHY Device support and infrastructure - depends on NET_ETHERNET (BROKEN || !S390) + depends on (BROKEN || !S390) help Ethernet controllers are usually attached to PHY devices. This option provides infrastructure for managing PHY devices. +if PHYLIB + comment MII PHY device drivers - depends on PHYLIB config MARVELL_PHY tristate Drivers for Marvell PHYs - depends on PHYLIB ---help--- Currently has a driver for the 88E1011S config DAVICOM_PHY tristate Drivers for Davicom PHYs - depends on PHYLIB ---help--- Currently supports dm9161e and dm9131 config QSEMI_PHY tristate Drivers for Quality Semiconductor PHYs - depends on PHYLIB ---help--- Currently supports the qs6612 config LXT_PHY tristate Drivers for the Intel LXT PHYs - depends on PHYLIB ---help--- Currently supports the lxt970, lxt971 config CICADA_PHY tristate Drivers for the Cicada PHYs - depends on PHYLIB ---help--- Currently supports the cis8204 config VITESSE_PHY tristate Drivers for the Vitesse PHYs -depends on PHYLIB ---help--- Currently supports the vsc8244 config SMSC_PHY tristate Drivers for SMSC PHYs - depends on PHYLIB ---help--- Currently supports the LAN83C185 PHY config BROADCOM_PHY tristate Drivers for Broadcom PHYs - depends on PHYLIB ---help--- Currently supports the BCM5411, BCM5421 and BCM5461 PHYs. config FIXED_PHY tristate Drivers for PHY emulation on fixed speed/link - depends on PHYLIB ---help--- Adds the driver to PHY layer to cover the boards that do not have any PHY bound, but with the ability to manipulate the speed/link in software. The relevant MII @@ -79,5 +69,4 @@ config FIXED_MII_100_FDX bool Emulation for 100M Fdx fixed PHY behavior depends on FIXED_PHY -endmenu - +endif #PHYLIB - 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] convert hh_lock to seqlock
On Thu, 07 Dec 2006 23:27:00 +0100 Eric Dumazet [EMAIL PROTECTED] wrote: Stephen Hemminger a écrit : On Thu, 07 Dec 2006 21:23:07 +0100 Eric Dumazet [EMAIL PROTECTED] wrote: Stephen Hemminger a écrit : The hard header cache is in the main output path, so using seqlock instead of reader/writer lock should reduce overhead. Nice work Stephen, I am very interested. Did you benchmarked it ? I ask because I think hh_refcnt frequent changes may defeat the gain you want (ie avoiding cache line ping pongs between cpus). seqlock are definitly better than rwlock, but if we really keep cache lines shared. So I would suggest reordering fields of hh_cache and adding one cacheline_aligned_in_smp to keep hh_refcnt in another cache line. (hh_len, hh_lock and hh_data should be placed on a 'mostly read' cache line) Thank you Eric It doesn't make any visible performance difference for real networks; copies and device issues are much larger. Hum, so 'my' machines must be unreal :) The hh_refcnt is used only when creating destroying neighbor entries, so except under DoS attack it doesn't make a lot of difference. The hh_lock is used on each packet sent. Some machines create/delete 10.000 entries per second in rt_cache. I believe they are real. DoS ? you tell it, some people wont agree. That could be fixed by doing RCU, I did some of that previously, but it seemed better to hit the worst case first. Even Robert doesn't see 10,000 rt cache entries per second. - 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] convert hh_lock to seqlock
From: Eric Dumazet [EMAIL PROTECTED] Date: Fri, 08 Dec 2006 00:02:44 +0100 What's the problem with my suggestion of keeping hh_refcnt on another cache line ? It is basically free (once your change from rwlock to seqlock put in), and no change of algorithm. I think this change is worthwhile for the short term until we get time to implement something like the RCU idea. - 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] convert hh_lock to seqlock
Stephen Hemminger a écrit : On Thu, 07 Dec 2006 23:27:00 +0100 Eric Dumazet [EMAIL PROTECTED] wrote: Stephen Hemminger a écrit : On Thu, 07 Dec 2006 21:23:07 +0100 Eric Dumazet [EMAIL PROTECTED] wrote: Stephen Hemminger a écrit : The hard header cache is in the main output path, so using seqlock instead of reader/writer lock should reduce overhead. Nice work Stephen, I am very interested. Did you benchmarked it ? I ask because I think hh_refcnt frequent changes may defeat the gain you want (ie avoiding cache line ping pongs between cpus). seqlock are definitly better than rwlock, but if we really keep cache lines shared. So I would suggest reordering fields of hh_cache and adding one cacheline_aligned_in_smp to keep hh_refcnt in another cache line. (hh_len, hh_lock and hh_data should be placed on a 'mostly read' cache line) Thank you Eric It doesn't make any visible performance difference for real networks; copies and device issues are much larger. Hum, so 'my' machines must be unreal :) The hh_refcnt is used only when creating destroying neighbor entries, so except under DoS attack it doesn't make a lot of difference. The hh_lock is used on each packet sent. Some machines create/delete 10.000 entries per second in rt_cache. I believe they are real. DoS ? you tell it, some people wont agree. That could be fixed by doing RCU, I did some of that previously, but it seemed better to hit the worst case first. Even Robert doesn't see 10,000 rt cache entries per second. What's the problem with my suggestion of keeping hh_refcnt on another cache line ? It is basically free (once your change from rwlock to seqlock put in), and no change of algorithm. - 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] convert hh_lock to seqlock
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 11:33:09 -0800 The hard header cache is in the main output path, so using seqlock instead of reader/writer lock should reduce overhead. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] I've applied this, thanks Stephen. - 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
[AX.25] Constify ax25 utility functions
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
include/net/ax25.h | 18 ++
net/ax25/ax25_addr.c | 19 +++
2 files changed, 21 insertions(+), 16 deletions(-)
Index: linux-net/include/net/ax25.h
===
--- linux-net.orig/include/net/ax25.h
+++ linux-net/include/net/ax25.h
@@ -283,14 +283,16 @@ extern struct sock *ax25_make_new(struct
/* ax25_addr.c */
extern ax25_address null_ax25_address;
-extern char *ax2asc(char *buf, ax25_address *);
-extern void asc2ax(ax25_address *addr, char *callsign);
-extern int ax25cmp(ax25_address *, ax25_address *);
-extern int ax25digicmp(ax25_digi *, ax25_digi *);
-extern unsigned char *ax25_addr_parse(unsigned char *, int, ax25_address *,
ax25_address *, ax25_digi *, int *, int *);
-extern int ax25_addr_build(unsigned char *, ax25_address *, ax25_address *,
ax25_digi *, int, int);
-extern int ax25_addr_size(ax25_digi *);
-extern void ax25_digi_invert(ax25_digi *, ax25_digi *);
+extern char *ax2asc(char *buf, const ax25_address *);
+extern void asc2ax(ax25_address *addr, const char *callsign);
+extern int ax25cmp(const ax25_address *, const ax25_address *);
+extern int ax25digicmp(const ax25_digi *, const ax25_digi *);
+extern const unsigned char *ax25_addr_parse(const unsigned char *, int,
+ ax25_address *, ax25_address *, ax25_digi *, int *, int *);
+extern int ax25_addr_build(unsigned char *, const ax25_address *,
+ const ax25_address *, const ax25_digi *, int, int);
+extern int ax25_addr_size(const ax25_digi *);
+extern void ax25_digi_invert(const ax25_digi *, ax25_digi *);
/* ax25_dev.c */
extern ax25_dev *ax25_dev_list;
Index: linux-net/net/ax25/ax25_addr.c
===
--- linux-net.orig/net/ax25/ax25_addr.c
+++ linux-net/net/ax25/ax25_addr.c
@@ -39,7 +39,7 @@ EXPORT_SYMBOL(null_ax25_address);
/*
* ax25 - ascii conversion
*/
-char *ax2asc(char *buf, ax25_address *a)
+char *ax2asc(char *buf, const ax25_address *a)
{
char c, *s;
int n;
@@ -72,7 +72,7 @@ EXPORT_SYMBOL(ax2asc);
/*
* ascii - ax25 conversion
*/
-void asc2ax(ax25_address *addr, char *callsign)
+void asc2ax(ax25_address *addr, const char *callsign)
{
char *s;
int n;
@@ -107,7 +107,7 @@ EXPORT_SYMBOL(asc2ax);
/*
* Compare two ax.25 addresses
*/
-int ax25cmp(ax25_address *a, ax25_address *b)
+int ax25cmp(const ax25_address *a, const ax25_address *b)
{
int ct = 0;
@@ -128,7 +128,7 @@ EXPORT_SYMBOL(ax25cmp);
/*
* Compare two AX.25 digipeater paths.
*/
-int ax25digicmp(ax25_digi *digi1, ax25_digi *digi2)
+int ax25digicmp(const ax25_digi *digi1, const ax25_digi *digi2)
{
int i;
@@ -149,7 +149,9 @@ int ax25digicmp(ax25_digi *digi1, ax25_d
* Given an AX.25 address pull of to, from, digi list, command/response
and the start of data
*
*/
-unsigned char *ax25_addr_parse(unsigned char *buf, int len, ax25_address *src,
ax25_address *dest, ax25_digi *digi, int *flags, int *dama)
+const unsigned char *ax25_addr_parse(const unsigned char *buf, int len,
+ ax25_address *src, ax25_address *dest, ax25_digi *digi, int *flags,
+ int *dama)
{
int d = 0;
@@ -204,7 +206,8 @@ unsigned char *ax25_addr_parse(unsigned
/*
* Assemble an AX.25 header from the bits
*/
-int ax25_addr_build(unsigned char *buf, ax25_address *src, ax25_address *dest,
ax25_digi *d, int flag, int modulus)
+int ax25_addr_build(unsigned char *buf, const ax25_address *src,
+ const ax25_address *dest, const ax25_digi *d, int flag, int modulus)
{
int len = 0;
int ct = 0;
@@ -261,7 +264,7 @@ int ax25_addr_build(unsigned char *buf,
return len;
}
-int ax25_addr_size(ax25_digi *dp)
+int ax25_addr_size(const ax25_digi *dp)
{
if (dp == NULL)
return 2 * AX25_ADDR_LEN;
@@ -272,7 +275,7 @@ int ax25_addr_size(ax25_digi *dp)
/*
* Reverse Digipeat List. May not pass both parameters as same struct
*/
-void ax25_digi_invert(ax25_digi *in, ax25_digi *out)
+void ax25_digi_invert(const ax25_digi *in, ax25_digi *out)
{
int ct;
-
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: [AX.25] Constify ax25 utility functions
From: Ralf Baechle [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 23:40:57 + Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Applied, thanks Ralf. - 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: [AX.25] Fix default address and broadcast address initialization
From: Ralf Baechle [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 23:45:59 + Only the callsign but not the SSID part of an AX.25 address is ASCII based but Linux by initializes the SSID which should be just a 4-bit number from ASCII anyway. Fix that and convert the code to use a shared constant for both default addresses. While at it, use the same style for null_ax25_address also. Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Applied, thanks Ralf. - 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
[AX.25] Fix default address and broadcast address initialization
Only the callsign but not the SSID part of an AX.25 address is ASCII
based but Linux by initializes the SSID which should be just a 4-bit
number from ASCII anyway.
Fix that and convert the code to use a shared constant for both default
addresses. While at it, use the same style for null_ax25_address also.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
drivers/net/hamradio/6pack.c |9 ++---
drivers/net/hamradio/baycom_epp.c | 10 ++
drivers/net/hamradio/bpqether.c |9 ++---
drivers/net/hamradio/dmascc.c | 10 ++
drivers/net/hamradio/hdlcdrv.c| 16 ++--
drivers/net/hamradio/mkiss.c |9 ++---
drivers/net/hamradio/scc.c|9 ++---
drivers/net/hamradio/yam.c|9 ++---
include/net/ax25.h|6 +++---
net/ax25/ax25_addr.c | 15 ---
10 files changed, 31 insertions(+), 71 deletions(-)
Index: linux-net/drivers/net/hamradio/6pack.c
===
--- linux-net.orig/drivers/net/hamradio/6pack.c
+++ linux-net/drivers/net/hamradio/6pack.c
@@ -325,11 +325,6 @@ static int sp_rebuild_header(struct sk_b
static void sp_setup(struct net_device *dev)
{
- static char ax25_bcast[AX25_ADDR_LEN] =
- {'Q'1,'S'1,'T'1,' '1,' '1,' '1,'0'1};
- static char ax25_test[AX25_ADDR_LEN] =
- {'L'1,'I'1,'N'1,'U'1,'X'1,' '1,'1'1};
-
/* Finish setting up the DEVICE info. */
dev-mtu= SIXP_MTU;
dev-hard_start_xmit= sp_xmit;
@@ -347,8 +342,8 @@ static void sp_setup(struct net_device *
dev-tx_timeout = NULL;
/* Only activated in AX.25 mode */
- memcpy(dev-broadcast, ax25_bcast, AX25_ADDR_LEN);
- memcpy(dev-dev_addr, ax25_test, AX25_ADDR_LEN);
+ memcpy(dev-broadcast, ax25_bcast, AX25_ADDR_LEN);
+ memcpy(dev-dev_addr, ax25_defaddr, AX25_ADDR_LEN);
SET_MODULE_OWNER(dev);
Index: linux-net/drivers/net/hamradio/baycom_epp.c
===
--- linux-net.orig/drivers/net/hamradio/baycom_epp.c
+++ linux-net/drivers/net/hamradio/baycom_epp.c
@@ -1141,12 +1141,6 @@ static int baycom_ioctl(struct net_devic
*/
static void baycom_probe(struct net_device *dev)
{
- static char ax25_bcast[AX25_ADDR_LEN] = {
- 'Q' 1, 'S' 1, 'T' 1, ' ' 1, ' ' 1, ' ' 1, '0'
1
- };
- static char ax25_nocall[AX25_ADDR_LEN] = {
- 'L' 1, 'I' 1, 'N' 1, 'U' 1, 'X' 1, ' ' 1, '1'
1
- };
const struct hdlcdrv_channel_params dflt_ch_params = {
20, 2, 10, 40, 0
};
@@ -1182,8 +1176,8 @@ static void baycom_probe(struct net_devi
dev-hard_header_len = AX25_MAX_HEADER_LEN + AX25_BPQ_HEADER_LEN;
dev-mtu = AX25_DEF_PACLEN;/* eth_mtu is the default */
dev-addr_len = AX25_ADDR_LEN; /* sizeof an ax.25 address */
- memcpy(dev-broadcast, ax25_bcast, AX25_ADDR_LEN);
- memcpy(dev-dev_addr, ax25_nocall, AX25_ADDR_LEN);
+ memcpy(dev-broadcast, ax25_bcast, AX25_ADDR_LEN);
+ memcpy(dev-dev_addr, ax25_nocall, AX25_ADDR_LEN);
dev-tx_queue_len = 16;
/* New style flags */
Index: linux-net/drivers/net/hamradio/bpqether.c
===
--- linux-net.orig/drivers/net/hamradio/bpqether.c
+++ linux-net/drivers/net/hamradio/bpqether.c
@@ -88,11 +88,6 @@
static char banner[] __initdata = KERN_INFO AX.25: bpqether driver version
004\n;
-static unsigned char ax25_bcast[AX25_ADDR_LEN] =
- {'Q' 1, 'S' 1, 'T' 1, ' ' 1, ' ' 1, ' ' 1, '0' 1};
-static unsigned char ax25_defaddr[AX25_ADDR_LEN] =
- {'L' 1, 'I' 1, 'N' 1, 'U' 1, 'X' 1, ' ' 1, '1' 1};
-
static char bcast_addr[6]={0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};
static char bpq_eth_addr[6];
@@ -487,8 +482,8 @@ static void bpq_setup(struct net_device
dev-do_ioctl= bpq_ioctl;
dev-destructor = free_netdev;
- memcpy(dev-broadcast, ax25_bcast, AX25_ADDR_LEN);
- memcpy(dev-dev_addr, ax25_defaddr, AX25_ADDR_LEN);
+ memcpy(dev-broadcast, ax25_bcast, AX25_ADDR_LEN);
+ memcpy(dev-dev_addr, ax25_defaddr, AX25_ADDR_LEN);
dev-flags = 0;
Index: linux-net/drivers/net/hamradio/dmascc.c
===
--- linux-net.orig/drivers/net/hamradio/dmascc.c
+++ linux-net/drivers/net/hamradio/dmascc.c
@@ -264,12 +264,6 @@ static int io[MAX_NUM_DEVS] __initdata =
/* Beware! hw[] is also used in cleanup_module(). */
static struct scc_hardware hw[NUM_TYPES] __initdata_or_module = HARDWARE;
-static char ax25_broadcast[7] __initdata =
-{ 'Q' 1, 'S' 1, 'T' 1, ' ' 1, ' ' 1, ' ' 1,
-'0' 1 };
-static char ax25_test[7] __initdata =
-{ 'L' 1, 'I' 1, 'N' 1, 'U' 1, 'X' 1, ' ' 1,
-'1' 1 };
/* Global
[IPROUTE2 PATCH][XFRM] update xfrm async events
[XFRM] update xfrm async events
Report abbreviated async xfrm aevents.
---
commit 06f5ab6e44fd60430c1b25cd6144d93d3c598bb0
tree a2fe589d73fe8a0e565ae4a73790b0a6b14c96d4
parent 74ca97373a2c98ac49156bd76d6df6a0d2a27ffc
author Jamal Hadi Salim [EMAIL PROTECTED] Thu, 07 Dec 2006 20:27:06 -0500
committer Jamal Hadi Salim [EMAIL PROTECTED] Thu, 07 Dec 2006 20:27:06 -0500
ip/xfrm_monitor.c | 53 +
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/ip/xfrm_monitor.c b/ip/xfrm_monitor.c
index 154bbee..b2014b4 100644
--- a/ip/xfrm_monitor.c
+++ b/ip/xfrm_monitor.c
@@ -150,6 +150,49 @@ static int xfrm_report_print(const struct sockaddr_nl *who,
return 0;
}
+void xfrm_ae_flags_print(__u32 flags, void *arg)
+{
+ FILE *fp = (FILE*)arg;
+ fprintf(fp, (0x%x) , flags);
+ if (!flags)
+ return;
+ if (flags XFRM_AE_CR)
+ fprintf(fp, replay update );
+ if (flags XFRM_AE_CE)
+ fprintf(fp, timer expired );
+ if (flags XFRM_AE_CU)
+ fprintf(fp, policy updated );
+
+}
+
+static int xfrm_ae_print(const struct sockaddr_nl *who,
+struct nlmsghdr *n, void *arg)
+{
+ FILE *fp = (FILE*)arg;
+ struct xfrm_aevent_id *id = NLMSG_DATA(n);
+ char abuf[256];
+
+ fprintf(fp, Async event );
+ xfrm_ae_flags_print(id-flags, arg);
+ fprintf(fp,\n\t);
+ memset(abuf, '\0', sizeof(abuf));
+ fprintf(fp, src %s , rt_addr_n2a(id-sa_id.family,
+ sizeof(id-saddr), id-saddr,
+ abuf, sizeof(abuf)));
+ memset(abuf, '\0', sizeof(abuf));
+ fprintf(fp, dst %s , rt_addr_n2a(id-sa_id.family,
+ sizeof(id-sa_id.daddr), id-sa_id.daddr,
+ abuf, sizeof(abuf)));
+ fprintf(fp, reqid 0x%x, id-reqid);
+ fprintf(fp, protocol %s , strxf_proto(id-sa_id.proto));
+ fprintf(fp, SPI 0x%x, ntohl(id-sa_id.spi));
+
+ fprintf(fp, \n);
+ fflush(fp);
+
+ return 0;
+}
+
static int xfrm_accept_msg(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg)
{
@@ -190,6 +233,10 @@ static int xfrm_accept_msg(const struct sockaddr_nl *who,
xfrm_report_print(who, n, arg);
return 0;
}
+ if (n-nlmsg_type == XFRM_MSG_NEWAE) {
+ xfrm_ae_print(who, n, arg);
+ return 0;
+ }
if (n-nlmsg_type != NLMSG_ERROR n-nlmsg_type != NLMSG_NOOP
n-nlmsg_type != NLMSG_DONE) {
fprintf(fp, Unknown message: %08d 0x%08x 0x%08x\n,
@@ -206,6 +253,7 @@ int do_xfrm_monitor(int argc, char **argv)
unsigned groups = ~((unsigned)0); /* XXX */
int lacquire=0;
int lexpire=0;
+ int laevent=0;
int lpolicy=0;
int lsa=0;
int lreport=0;
@@ -225,6 +273,9 @@ int do_xfrm_monitor(int argc, char **argv)
} else if (matches(*argv, SA) == 0) {
lsa=1;
groups = 0;
+ } else if (matches(*argv, aevent) == 0) {
+ laevent=1;
+ groups = 0;
} else if (matches(*argv, policy) == 0) {
lpolicy=1;
groups = 0;
@@ -248,6 +299,8 @@ int do_xfrm_monitor(int argc, char **argv)
groups |= XFRMGRP_SA;
if (lpolicy)
groups |= XFRMGRP_POLICY;
+ if (laevent)
+ groups |= (1 (XFRMNLGRP_AEVENTS - 1));
if (lreport)
groups |= XFRMGRP_REPORT;
[IPROUTE2 PATCH][utils] make muticast group to bitmask conversion generic
[utils] make muticast group to bitmask conversion generic
Signed-off-by: J Hadi Salim [EMAIL PROTECTED]
---
commit 1326d6a1eb107e3b9ea7a3254e621dd3f827bb4d
tree 47387be512f44a27ee73678d3775801dfafaf03d
parent 06f5ab6e44fd60430c1b25cd6144d93d3c598bb0
author Jamal Hadi Salim [EMAIL PROTECTED] Thu, 07 Dec 2006 20:44:29 -0500
committer Jamal Hadi Salim [EMAIL PROTECTED] Thu, 07 Dec 2006 20:44:29 -0500
genl/genl_utils.h |7 +--
include/utils.h |6 ++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/genl/genl_utils.h b/genl/genl_utils.h
index 22e9210..85b5183 100644
--- a/genl/genl_utils.h
+++ b/genl/genl_utils.h
@@ -1,6 +1,7 @@
#ifndef _TC_UTIL_H_
#define _TC_UTIL_H_ 1
+#include utils.h
#include linux/genetlink.h
struct genl_util
@@ -13,10 +14,4 @@ struct genl_util
extern int genl_ctrl_resolve_family(const char *family);
-/* seems to have dissapeared from netlink.h */
-static inline __u32 nl_mgrp(__u32 group)
-{
- return group ? (1 (group -1)) : 0;
-}
-
#endif
diff --git a/include/utils.h b/include/utils.h
index a4133c9..1769ca1 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -127,6 +127,12 @@ static __inline__ int get_user_hz(void)
return __iproute2_user_hz_internal;
}
+static inline __u32 nl_mgrp(__u32 group)
+{
+ return group ? (1 (group -1)) : 0;
+}
+
+
int print_timestamp(FILE *fp);
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
RE: [openib-general] [RFC] [PATCH V2 0/3] bonding support foroperation over IPoIB
Or, Can you please forward me (or to the email alias) an example bonding sysfs script which can be used to set bonding to work with patches 1-3? Thanks, Carl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Or Gerlitz Sent: Thursday, November 30, 2006 2:57 AM To: netdev@vger.kernel.org Cc: Roland Dreier (rdreier); Jay Vosburgh; openib-general@openib.org Subject: [openib-general] [RFC] [PATCH V2 0/3] bonding support foroperation over IPoIB This patch series is a second version (see below link to V1) of the suggested changes to the bonding driver such that it would be able to support non ARPHRD_ETHER netdevices for its High-Availability (active-backup) mode. The motivation is to enable the bonding driver on its HA mode to work with the IP over Infiniband (IPoIB) driver. With these patches I was able to enslave IPoIB netdevices and run TCP, UDP, IP (UDP) Multicast and ICMP traffic with fail-over and fail-back working fine. My working env was the net-2.6.20 git. More over, as IPoIB is also the IB ARP provider for the RDMA CM driver which is used by native IB ULPs whose addressing scheme is based on IP (eg iSER, SDP, Lustre, NFSoRDMA, RDS), bonding support for IPoIB devices **enables** HA for these ULPs. This holds as when the ULP is informed by the IB HW on the failure of the current IB connection, it just need to reconnect, where the bonding device will now issue the IB ARP over the active IPoIB slave. The first patch changes some of the bond netdevice attributes and functions to be that of the active slave for the case of the enslaved device not being of ARPHRD_ETHER type. Basically it overrides those setting done by ether_setup(), which are netdevice **type** dependent and hence might be not appropriate for devices of other types. It also enforces mutual exclusion on bonding slaves from dissimilar ether types, as was concluded over the v1 discussion. IPoIB (see Documentation/infiniband/ipoib.txt) MAC address is made of a 3 bytes IB QP (Queue Pair) number and 16 bytes IB port GID (Global ID) of the port this IPoIB device is bounded to. The QP is a resource created by the IB HW and the GID is an identifier burned into the HCA (i have omitted here some details which are not important for the bonding RFC). Basically the IPoIB spec and impl. do not allow for setting the MAC address of an IPoIB device and this work was made under this assumption. Hence, the second patch allows for enslaving netdevices which do not support the set_mac_address() function. In that case the bond mac address is the one of the active slave, where remote peers are notified on the mac address (neighbour) change by Gratuitous ARP sent by bonding when fail-over occurs (this is already done by the bonding code). Normally, the bonding driver is UP before any enslavement takes place. Once a netdevice is UP, the network stack acts to have it join some multicast groups (eg the all-hosts 224.0.0.1). Now, since ether_setup() have set the bonding device type to be ARPHRD_ETHER and address len to be ETHER_ALEN, the net core code computes a wrong multicast link address. This is b/c ip_eth_mc_map() is called where for mcast joins taking place **after** the enslavement another ip_xxx_mc_map() is called (eg ip_ib_mc_map() when the bond type is ARPHRD_INFINIBAND) The third patch handles this problem by allowing to enslave devices when the bonding device is not up. Over the discussion held at the previous post this seemed to be the most clean way to go, where it is not expected to cause instabilities. These patches are not enough for configuration of IPoIB bonding through tools (eg /sbin/ifenslave and /sbin/ifup) provided by packages such as sysconfig and initscripts, specifically since these tools sets the bonding device to be UP before enslaving anything. Once this patchset gets positive/feedback the next step would be to look how to enhance the tools/packages so it would be possible to bond/enslave with the modified code. As suggested by the bonding maintainer, this step can potentially involve converting ifenslave to be a script based on the bonding sysfs infrastructure rather on the somehow obsoleted Documentation/networking/ifenslave.c For the ease of potential testers, I will post an example bonding sysfs script which can be used to set bonding to work with patches 1-3 (let me know!) Or. changes from V1 (the links point to V1 0-3/3) http://marc.theaimsgroup.com/?l=linux-netdevm=115926582209736w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=115926599515568w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=115926599430055w=2 http://marc.theaimsgroup.com/?l=linux-netdevm=115926599415729w=2 + enforce mutual exclusion on the slaves ether types don't attempt to + set the bond mtu when enslaving a non ARPHRD_ETHER device rather than + hack the bond device ether type through mod params allow enslavement when the bond device is not up ___
drivers/net/chelsio/my3126.c: inconsequent NULL checking
The Coverity checker spotted the following inconsequent NULL checking
introduced by commit f1d3d38af75789f1b82969b83b69cab540609789:
-- snip --
...
static struct cphy *my3126_phy_create(adapter_t *adapter,
int phy_addr, struct mdio_ops *mdio_ops)
{
struct cphy *cphy = kzalloc(sizeof (*cphy), GFP_KERNEL);
if (cphy)
cphy_init(cphy, adapter, phy_addr, my3126_ops, mdio_ops);
INIT_WORK(cphy-phy_update, my3216_poll, cphy);
cphy-bmsr = 0;
return (cphy);
}
...
-- snip --
It doesn't make sense to first check whether cphy is NULL and
dereference it unconditionally later.
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
-
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
[git patches] net driver updates
[just sent this upstream] Random schtuff. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: drivers/net/3c501.c|2 drivers/net/3c503.c|2 drivers/net/3c505.c|2 drivers/net/3c507.c|2 drivers/net/3c523.c|2 drivers/net/3c527.c|2 drivers/net/ac3200.c |2 drivers/net/apne.c |4 drivers/net/appletalk/cops.c |2 drivers/net/arm/at91_ether.c | 88 ++-- drivers/net/arm/at91_ether.h |1 drivers/net/arm/ether1.c |6 drivers/net/arm/ether3.c |8 drivers/net/at1700.c |2 drivers/net/atarilance.c |4 drivers/net/bonding/bond_main.c|2 drivers/net/cs89x0.c |2 drivers/net/declance.c | 404 ++-- drivers/net/e2100.c|2 drivers/net/eepro.c|2 drivers/net/eexpress.c |2 drivers/net/es3210.c |2 drivers/net/eth16i.c |2 drivers/net/hp-plus.c |2 drivers/net/hp.c |2 drivers/net/lance.c|2 drivers/net/lne390.c |2 drivers/net/mv643xx_eth.c |4 drivers/net/mvme147.c |4 drivers/net/myri10ge/myri10ge.c| 95 +++-- drivers/net/myri10ge/myri10ge_mcp.h| 56 +-- drivers/net/myri10ge/myri10ge_mcp_gen_header.h |2 drivers/net/ne.c |2 drivers/net/ne2.c |2 drivers/net/netxen/netxen_nic.h| 331 drivers/net/netxen/netxen_nic_ethtool.c| 65 ++- drivers/net/netxen/netxen_nic_hdr.h|6 drivers/net/netxen/netxen_nic_hw.c | 483 +++- drivers/net/netxen/netxen_nic_hw.h | 10 drivers/net/netxen/netxen_nic_init.c | 361 ++ drivers/net/netxen/netxen_nic_ioctl.h |8 drivers/net/netxen/netxen_nic_isr.c| 51 +-- drivers/net/netxen/netxen_nic_main.c | 306 +-- drivers/net/netxen/netxen_nic_niu.c| 32 +- drivers/net/netxen/netxen_nic_phan_reg.h | 228 +++ drivers/net/ni52.c |2 drivers/net/ni65.c |2 drivers/net/ns83820.c | 25 + drivers/net/r8169.c| 84 +++- drivers/net/seeq8005.c |2 drivers/net/sk98lin/skgesirq.c |2 drivers/net/skge.h | 150 --- drivers/net/sky2.c | 117 +++--- drivers/net/sky2.h | 54 +-- drivers/net/smc-ultra.c|2 drivers/net/smc-ultra32.c |2 drivers/net/smc9194.c |2 drivers/net/smc91x.h | 24 + drivers/net/sun3lance.c|4 drivers/net/tokenring/smctr.c |2 drivers/net/wd.c |2 drivers/net/wireless/hostap/hostap_ap.c|4 drivers/net/wireless/hostap/hostap_cs.c|3 drivers/net/wireless/hostap/hostap_download.c |4 drivers/net/wireless/hostap/hostap_hw.c| 12 - drivers/net/wireless/hostap/hostap_info.c |3 drivers/net/wireless/hostap/hostap_ioctl.c | 12 - drivers/net/wireless/hostap/hostap_pci.c |3 drivers/net/wireless/hostap/hostap_plx.c |3 drivers/net/wireless/ipw2100.c |2 drivers/net/wireless/ipw2200.c | 24 + drivers/net/wireless/prism54/isl_ioctl.c |9 drivers/net/wireless/prism54/oid_mgt.c |4 drivers/net/wireless/zd1211rw/zd_chip.c| 13 + drivers/net/wireless/zd1211rw/zd_chip.h| 43 ++ drivers/net/wireless/zd1211rw/zd_mac.c | 53 ++- drivers/net/wireless/zd1211rw/zd_mac.h |3 drivers/net/wireless/zd1211rw/zd_netdev.c |2 net/ieee80211/softmac/ieee80211softmac_assoc.c | 14 + net/ieee80211/softmac/ieee80211softmac_auth.c |2 net/ieee80211/softmac/ieee80211softmac_priv.h |2 net/ieee80211/softmac/ieee80211softmac_wx.c|3 82 files changed, 2115 insertions(+), 1180
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 2006-12-06 at 22:41 +0100, Ivo van Doorn wrote: Hi, That is my point. Given the fact that there are keys that are not directly connected with the radio switch userspace will have to handle them (wait for events then turn off radios somehow). You are advocating that userspace should also implement 2nd method for buttons that belong to rfkill interface. I do not understand the need for 2nd interface. If you separate radio switch from button code then userspace only need to implement 1st interface and be done with it. You will have set of cards that provide interface to enable/disable their transmitters and set of buttons that signal userspace desired state change. If both switch and button is implemented by the same driver then the driver can implement automatic button handling. Otherwise userspace help is necessary. Well there are 3 possible hardware key approaches: 1 - Hardware key that controls the hardware radio, and does not report anything to userspace Can't do anything here so just ignore it. Ok. 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. My take: if there is a button on your keyboard or laptop labeled Kill my radio now, it _NEEDS_ to be somehow communicated to userspace what happened when the user just pressed it a second ago. Personally, I don't particularly care how that happens, and I don't particularly care what the driver does. But if the driver, or the hardware, decides that the button press means turning off the transmitter on whatever device that button is for, a tool like NetworkManager needs to know this somehow. Ideally, this would be a HAL event, and HAL would get it from somewhere. The current situation with NM is unacceptable, and I can't do anything about it because there is no standard interface for determining whether the wireless card was disabled/enabled via rfkill. I simply refuse to code solutions to every vendor's rfkill mechanism (for ipw, reading iwpriv or sysfs, for example). I don't care how HAL gets the event, but when HAL gets the event, it needs to broadcast it and NM needs to tear down the connection and release the device. That means (a) an event gets sent to userspace in some way that HAL can read it, and (b) the event is clearly associated with specific piece[s] of hardware on your system. If HAL can't easily figure out what device the event is for, then the event is also useless to both HAL and NetworkManager and whatever else might use it. Again, I don't care how that happens, but I like the fact that there's renewed interest in getting this fixed. Dan 3 - Hardware key that does not control the hardware radio and reports the key to userspace So rfkill should not be used in the case of (1) and (3), but we still need something to support (2) or should the keys not be handled by userspace and always by the driver? This is making rfkill moving slowly away from the generic approach for all rfkill keys as the initial intention was. I my vision rfkill would represent userspace namageable radio switch. We have the followng possible configurations: 1. A device that does not allow controlling its transmitter from userspace. The driver should not use/register with rfkill subsystem as userspace can't do anyhting with it. If device has a button killing the transmitter the driver can still signal userspace appropriate event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was presssed so userspace can monitor state of the transmitter and probably shut down other transmitters to keep everything in sync. And this event should be reported by a generic approach right? So it should be similar as with your point 2 below. But this would mean that the driver should create the input device. Or can a driver send the KEY_WIFI event over a main layer without the need of a personal input device? I am not that familiar with the input device layer in the kernel, and this is my first attempt on creating something for it, so I might have missed something. ;) Because it could still register with rfkill, only not give the callback functions for changing the radio or polling. Then the driver can use the send_event function to inform rfkill of the event and process it further. The sysfs attributes could even be reduced to only add the change_status attribute when the radio_enable and radio_disable callback functions are implemented. 2. A device that does allow controlling its transmitter. The driver may (should) register with rfkill subsystem.
Re: drivers/net/chelsio/my3126.c: inconsequent NULL checking
On 07/12/06, Adrian Bunk [EMAIL PROTECTED] wrote:
The Coverity checker spotted the following inconsequent NULL checking
introduced by commit f1d3d38af75789f1b82969b83b69cab540609789:
-- snip --
...
static struct cphy *my3126_phy_create(adapter_t *adapter,
int phy_addr, struct mdio_ops *mdio_ops)
{
struct cphy *cphy = kzalloc(sizeof (*cphy), GFP_KERNEL);
if (cphy)
cphy_init(cphy, adapter, phy_addr, my3126_ops, mdio_ops);
INIT_WORK(cphy-phy_update, my3216_poll, cphy);
cphy-bmsr = 0;
return (cphy);
}
...
-- snip --
It doesn't make sense to first check whether cphy is NULL and
dereference it unconditionally later.
How about simply changing
if (cphy)
cphy_init(cphy, adapter, phy_addr, my3126_ops, mdio_ops);
into
if (!cphy)
return NULL;
callers need to be able to handle that ofcourse, but I haven't checked that yet.
--
Jesper Juhl [EMAIL PROTECTED]
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.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: [RFC] rfkill - Add support for input key to control wireless radio
Hi, 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. My take: if there is a button on your keyboard or laptop labeled Kill my radio now, it _NEEDS_ to be somehow communicated to userspace what happened when the user just pressed it a second ago. Personally, I don't particularly care how that happens, and I don't particularly care what the driver does. But if the driver, or the hardware, decides that the button press means turning off the transmitter on whatever device that button is for, a tool like NetworkManager needs to know this somehow. Ideally, this would be a HAL event, and HAL would get it from somewhere. The current situation with NM is unacceptable, and I can't do anything about it because there is no standard interface for determining whether the wireless card was disabled/enabled via rfkill. I simply refuse to code solutions to every vendor's rfkill mechanism (for ipw, reading iwpriv or sysfs, for example). I don't care how HAL gets the event, but when HAL gets the event, it needs to broadcast it and NM needs to tear down the connection and release the device. That means (a) an event gets sent to userspace in some way that HAL can read it, and (b) the event is clearly associated with specific piece[s] of hardware on your system. If HAL can't easily figure out what device the event is for, then the event is also useless to both HAL and NetworkManager and whatever else might use it. This would be possible with rfkill and the ideas from Dmitry. The vendors that have a button that directly toggle the radio, should create an input device themselves and just send the KEY_RFKILL event when toggled. All other types should use rfkill for the toggling handling, that way HAL only needs to listen to KEY_RFKILL coming from the input devices that are associated to the keys. Again, I don't care how that happens, but I like the fact that there's renewed interest in getting this fixed. Ivo - 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] rfkill - Add support for input key to control wireless radio
Hi, 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. So what does such a button do? I am confused here... Without a handler like rfkill, it does nothing besides toggling a bit in a register. The Ralink chipsets have a couple of registers that represent the state of that key. Besides that, there are no notifications to the userspace nor does it directly control the radio. That is where rfkill came in with the toggle handler that will listen to the register to check if the key has been pressed and properly process the key event. And this event should be reported by a generic approach right? So it should be similar as with your point 2 below. But this would mean that the driver should create the input device. Or can a driver send the KEY_WIFI event over a main layer without the need of a personal input device? I am not that familiar with the input device layer in the kernel, and this is my first attempt on creating something for it, so I might have missed something. ;) Yes, I think the driver should just create an input device. You may provide a generic implementation for a polled button and have driver instantiate it but I do not think that a single RFkill button device is needed - you won't have too many of them in a single system anyway (I think you will normally have 1, 2 at the most). Ok, this is something that can be added as notice in the rfkill description to make sure drivers which supports keys that handle the radio event themselves should handle everything themselves and just use the KEY_RFKILL event for the input device. 3. A device without transmitter but with a button - just register with input core. Userspace will have to manage state of other devices with transmitters in response to button presses. This is clear too. Rfkill is only intended for drivers that control a device with a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to do something with the radio/transmitter. Does this make sense? Yes, this was what I intended to do with rfkill, so at that point we have the same goal. I think it is almost the same. I also want support RF devices that can control radio state but lack a button. This is covered by mixing 2) and 3) in kernel and for userspace looks exactly like 2) with a button. Ok, this means making the change in rfkill to instead support 1) and 2) and change it into 2) and 3) that would be possible and would make it possible again to change the radio state to something different then the key indicates. That was previously removed because of support for 1) devices. ... I don't think a config option is a good idea unless by config option you mean a sysfs attribute. I indeed meant a sysfs attribute. I should have been more clear on this. :) OK :) Ivo - 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/10] cxgb3 - main header files
From: Divy Le Ray [EMAIL PROTECTED]
This patch implements the main header files of
the Chelsio T3 network driver.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/adapter.h | 255
drivers/net/cxgb3/common.h | 710 ++
drivers/net/cxgb3/cxgb3_ioctl.h | 165
drivers/net/cxgb3/firmware_exports.h | 144 +++
4 files changed, 1274 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
new file mode 100755
index 000..16643f6
--- /dev/null
+++ b/drivers/net/cxgb3/adapter.h
@@ -0,0 +1,255 @@
+/*
+ * This file is part of the Chelsio T3 Ethernet driver for Linux.
+ *
+ * Copyright (C) 2003-2006 Chelsio Communications. All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+/* This file should not be included directly. Include common.h instead. */
+
+#ifndef __T3_ADAPTER_H__
+#define __T3_ADAPTER_H__
+
+#include linux/pci.h
+#include linux/spinlock.h
+#include linux/interrupt.h
+#include linux/timer.h
+#include linux/cache.h
+#include t3cdev.h
+#include asm/semaphore.h
+#include asm/bitops.h
+#include asm/io.h
+
+typedef irqreturn_t(*intr_handler_t) (int, void *);
+
+struct vlan_group;
+
+struct port_info {
+ struct vlan_group *vlan_grp;
+ const struct port_type_info *port_type;
+ u8 port_id;
+ u8 rx_csum_offload;
+ u8 nqsets;
+ u8 first_qset;
+ struct cphy phy;
+ struct cmac mac;
+ struct link_config link_config;
+ struct net_device_stats netstats;
+ int activity;
+};
+
+enum { /* adapter flags */
+ FULL_INIT_DONE = (1 0),
+ USING_MSI = (1 1),
+ USING_MSIX = (1 2),
+};
+
+struct rx_desc;
+struct rx_sw_desc;
+
+struct sge_fl {/* SGE per free-buffer list state */
+ unsigned int buf_size; /* size of each Rx buffer */
+ unsigned int credits; /* # of available Rx buffers */
+ unsigned int size; /* capacity of free list */
+ unsigned int cidx; /* consumer index */
+ unsigned int pidx; /* producer index */
+ unsigned int gen; /* free list generation */
+ struct rx_desc *desc; /* address of HW Rx descriptor ring */
+ struct rx_sw_desc *sdesc; /* address of SW Rx descriptor ring */
+ dma_addr_t phys_addr; /* physical address of HW ring start */
+ unsigned int cntxt_id; /* SGE context id for the free list */
+ unsigned long empty;/* # of times queue ran out of buffers */
+};
+
+/*
+ * Bundle size for grouping offload RX packets for delivery to the stack.
+ * Don't make this too big as we do prefetch on each packet in a bundle.
+ */
+# define RX_BUNDLE_SIZE 8
+
+struct rsp_desc;
+
+struct sge_rspq { /* state for an SGE response queue */
+ unsigned int credits; /* # of pending response credits */
+ unsigned int size; /* capacity of response queue */
+ unsigned int cidx; /* consumer index */
+ unsigned int gen; /* current generation bit */
+ unsigned int polling; /* is the queue serviced through NAPI? */
+ unsigned int holdoff_tmr; /* interrupt holdoff timer in 100ns */
+ unsigned int next_holdoff; /* holdoff time for next interrupt */
+ struct rsp_desc *desc; /* address of HW response ring */
+ dma_addr_t phys_addr; /* physical address of the ring */
+ unsigned int cntxt_id; /* SGE context id for the response q */
+ spinlock_t lock;/* guards response processing */
+ struct sk_buff *rx_head;/* offload packet receive queue head */
+ struct sk_buff *rx_tail;/* offload packet receive queue tail */
+
+ unsigned long offload_pkts;
+ unsigned long offload_bundles;
+ unsigned long eth_pkts; /* # of ethernet packets */
+ unsigned long pure_rsps;/* # of pure (non-data) responses */
+ unsigned long imm_data; /* responses with immediate data */
+ unsigned long rx_drops; /* # of packets dropped due to no mem */
+ unsigned long async_notif; /* # of asynchronous notification events */
+ unsigned long empty;/* # of times queue ran out of credits */
+ unsigned long nomem;/* # of responses deferred due to no mem */
+ unsigned long unhandled_irqs; /* # of spurious intrs */
+};
+
+struct tx_desc;
+struct tx_sw_desc;
+
+struct sge_txq { /* state for an SGE Tx queue */
+ unsigned long flags;/* HW DMA fetch status */
+ unsigned int in_use;/* # of in-use Tx descriptors */
+ unsigned int size; /* # of descriptors */
+ unsigned int
[PATCH 0/10] cxgb3: Chelsio T3 1G/10G ethernet device driver
Hi, I resubmit the patch supporting the latest Chelsio T3 adapter. It incorporates feedbacks from Stephen: - per port data accessed through netdev_priv() - remove locking in netpoll() method It also adapts to the new workqueue rules. This patch adds support for the latest Chelsio adapter, T3. It is built against 2.6.19. A corresponding monolithic patch against 2.6.19 is posted at the following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2 We wish this patch to be considered for inclusion in 2.6.20. This driver is required by the Chelsio T3 RDMA driver which was updated on 12/02/2006. Cheers, Divy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/10] cxgb3 - HW access routines - part 2
From: Divy Le Ray [EMAIL PROTECTED]
This patch implements the HW access routines for the
Chelsio T3 network adapter's driver.
This patch is split. This is the second part.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
--
+/**
+ * t3_sge_write_context - write an SGE context
+ * @adapter: the adapter
+ * @id: the context id
+ * @type: the context type
+ *
+ * Program an SGE context with the values already loaded in the
+ * CONTEXT_DATA? registers.
+ */
+static int t3_sge_write_context(struct adapter *adapter, unsigned int id,
+ unsigned int type)
+{
+ t3_write_reg(adapter, A_SG_CONTEXT_MASK0, 0x);
+ t3_write_reg(adapter, A_SG_CONTEXT_MASK1, 0x);
+ t3_write_reg(adapter, A_SG_CONTEXT_MASK2, 0x);
+ t3_write_reg(adapter, A_SG_CONTEXT_MASK3, 0x);
+ t3_write_reg(adapter, A_SG_CONTEXT_CMD,
+V_CONTEXT_CMD_OPCODE(1) | type | V_CONTEXT(id));
+ return t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
+ 0, 5, 1);
+}
+
+/**
+ * t3_sge_init_ecntxt - initialize an SGE egress context
+ * @adapter: the adapter to configure
+ * @id: the context id
+ * @gts_enable: whether to enable GTS for the context
+ * @type: the egress context type
+ * @respq: associated response queue
+ * @base_addr: base address of queue
+ * @size: number of queue entries
+ * @token: uP token
+ * @gen: initial generation value for the context
+ * @cidx: consumer pointer
+ *
+ * Initialize an SGE egress context and make it ready for use. If the
+ * platform allows concurrent context operations, the caller is
+ * responsible for appropriate locking.
+ */
+int t3_sge_init_ecntxt(struct adapter *adapter, unsigned int id, int
gts_enable,
+ enum sge_context_type type, int respq, u64 base_addr,
+ unsigned int size, unsigned int token, int gen,
+ unsigned int cidx)
+{
+ unsigned int credits = type == SGE_CNTXT_OFLD ? 0 : FW_WR_NUM;
+
+ if (base_addr 0xfff) /* must be 4K aligned */
+ return -EINVAL;
+ if (t3_read_reg(adapter, A_SG_CONTEXT_CMD) F_CONTEXT_CMD_BUSY)
+ return -EBUSY;
+
+ base_addr = 12;
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA0, V_EC_INDEX(cidx) |
+V_EC_CREDITS(credits) | V_EC_GTS(gts_enable));
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA1, V_EC_SIZE(size) |
+V_EC_BASE_LO((u32) base_addr 0x));
+ base_addr = 16;
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA2, (u32) base_addr);
+ base_addr = 32;
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA3,
+V_EC_BASE_HI((u32) base_addr 0xf) | V_EC_RESPQ(respq) |
+V_EC_TYPE(type) | V_EC_GEN(gen) | V_EC_UP_TOKEN(token) |
+F_EC_VALID);
+ return t3_sge_write_context(adapter, id, F_EGRESS);
+}
+
+/**
+ * t3_sge_init_flcntxt - initialize an SGE free-buffer list context
+ * @adapter: the adapter to configure
+ * @id: the context id
+ * @gts_enable: whether to enable GTS for the context
+ * @base_addr: base address of queue
+ * @size: number of queue entries
+ * @bsize: size of each buffer for this queue
+ * @cong_thres: threshold to signal congestion to upstream producers
+ * @gen: initial generation value for the context
+ * @cidx: consumer pointer
+ *
+ * Initialize an SGE free list context and make it ready for use. The
+ * caller is responsible for ensuring only one context operation occurs
+ * at a time.
+ */
+int t3_sge_init_flcntxt(struct adapter *adapter, unsigned int id,
+ int gts_enable, u64 base_addr, unsigned int size,
+ unsigned int bsize, unsigned int cong_thres, int gen,
+ unsigned int cidx)
+{
+ if (base_addr 0xfff) /* must be 4K aligned */
+ return -EINVAL;
+ if (t3_read_reg(adapter, A_SG_CONTEXT_CMD) F_CONTEXT_CMD_BUSY)
+ return -EBUSY;
+
+ base_addr = 12;
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA0, (u32) base_addr);
+ base_addr = 32;
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA1,
+V_FL_BASE_HI((u32) base_addr) |
+V_FL_INDEX_LO(cidx M_FL_INDEX_LO));
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA2, V_FL_SIZE(size) |
+V_FL_GEN(gen) | V_FL_INDEX_HI(cidx 12) |
+V_FL_ENTRY_SIZE_LO(bsize M_FL_ENTRY_SIZE_LO));
+ t3_write_reg(adapter, A_SG_CONTEXT_DATA3,
+V_FL_ENTRY_SIZE_HI(bsize (32 - S_FL_ENTRY_SIZE_LO)) |
+V_FL_CONG_THRES(cong_thres) | V_FL_GTS(gts_enable));
+ return t3_sge_write_context(adapter, id, F_FREELIST);
+}
+
+/**
+ * t3_sge_init_rspcntxt - initialize an SGE response queue context
+ *
[PATCH 10/10] cxgb3 - build files and versioning
From: Divy Le Ray [EMAIL PROTECTED] This patch implements build files and versioning for the Chelsio T3 network adapter's driver. Signed-off-by: Divy Le Ray [EMAIL PROTECTED] --- drivers/net/Kconfig | 18 ++ drivers/net/Makefile|1 + drivers/net/cxgb3/Makefile |8 drivers/net/cxgb3/version.h | 24 4 files changed, 51 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 9de0eed..7fdf4ca 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2384,6 +2384,24 @@ config CHELSIO_T1_1G Enables support for Chelsio's gigabit Ethernet PCI cards. If you are using only 10G cards say 'N' here. +config CHELSIO_T3 +tristate Chelsio Communications T3 10Gb Ethernet support +depends on PCI +help + This driver supports Chelsio T3-based gigabit and 10Gb Ethernet + adapters. + + For general information about Chelsio and our products, visit + our website at http://www.chelsio.com. + + For customer support, please visit our customer support page at + http://www.chelsio.com/support.htm. + + Please send feedback to [EMAIL PROTECTED]. + + To compile this driver as a module, choose M here: the module + will be called cxgb3. + config EHEA tristate eHEA Ethernet support depends on IBMEBUS diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 4c0d4e5..5c66643 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_E1000) += e1000/ obj-$(CONFIG_IBM_EMAC) += ibm_emac/ obj-$(CONFIG_IXGB) += ixgb/ obj-$(CONFIG_CHELSIO_T1) += chelsio/ +obj-$(CONFIG_CHELSIO_T3) += cxgb3/ obj-$(CONFIG_EHEA) += ehea/ obj-$(CONFIG_BONDING) += bonding/ obj-$(CONFIG_GIANFAR) += gianfar_driver.o diff --git a/drivers/net/cxgb3/Makefile b/drivers/net/cxgb3/Makefile new file mode 100755 index 000..3434679 --- /dev/null +++ b/drivers/net/cxgb3/Makefile @@ -0,0 +1,8 @@ +# +# Chelsio T3 driver +# + +obj-$(CONFIG_CHELSIO_T3) += cxgb3.o + +cxgb3-objs := cxgb3_main.o ael1002.o vsc8211.o t3_hw.o mc5.o \ + xgmac.o sge.o l2t.o cxgb3_offload.o diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h new file mode 100755 index 000..5a29475 --- /dev/null +++ b/drivers/net/cxgb3/version.h @@ -0,0 +1,24 @@ +/* + * * + * File: * + * version.h* + * * + * Description: * + * Chelsio driver version defines. * + * * + * Copyright (c) 2003 - 2006 Chelsio Communications, Inc.* + * All rights reserved. * + * * + * Maintainers: [EMAIL PROTECTED] * + * * + * http://www.chelsio.com* + * * + / +/* $Date: 2006/10/31 18:57:51 $ $RCSfile: version.h,v $ $Revision: 1.3 $ */ +#ifndef __CHELSIO_VERSION_H +#define __CHELSIO_VERSION_H +#define DRV_DESC Chelsio T3 Network Driver +#define DRV_NAME cxgb3 +// Driver version +#define DRV_VERSION 1.0 +#endif //__CHELSIO_VERSION_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
[PATCH 8/10] cxgb3 - offload capabilities
From: Divy Le Ray [EMAIL PROTECTED]
This patch implements the offload capabilities of the
Chelsio network adapter's driver.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/cxgb3_offload.c | 1221 +
drivers/net/cxgb3/l2t.c | 445 +
2 files changed, 1666 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_offload.c
b/drivers/net/cxgb3/cxgb3_offload.c
new file mode 100755
index 000..1c9c0f2
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_offload.c
@@ -0,0 +1,1221 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include linux/list.h
+#include net/neighbour.h
+#include linux/notifier.h
+#include asm/atomic.h
+#include linux/proc_fs.h
+#include linux/if_vlan.h
+#include net/netevent.h
+#include linux/vmalloc.h
+
+#include common.h
+#include regs.h
+#include cxgb3_ioctl.h
+#include cxgb3_ctl_defs.h
+#include cxgb3_defs.h
+#include l2t.h
+#include firmware_exports.h
+#include cxgb3_offload.h
+
+static LIST_HEAD(client_list);
+static LIST_HEAD(ofld_dev_list);
+static DEFINE_MUTEX(cxgb3_db_lock);
+
+static DEFINE_RWLOCK(adapter_list_lock);
+static LIST_HEAD(adapter_list);
+
+static const unsigned int MAX_ATIDS = 64 * 1024;
+static const unsigned int ATID_BASE = 0x10;
+
+static inline int offload_activated(struct t3cdev *tdev)
+{
+ const struct adapter *adapter = tdev2adap(tdev);
+
+ return (test_bit(OFFLOAD_DEVMAP_BIT, adapter-open_device_map));
+}
+
+/**
+ * cxgb3_register_client - register an offload client
+ * @client: the client
+ *
+ * Add the client to the client list,
+ * and call backs the client for each activated offload device
+ */
+void cxgb3_register_client(struct cxgb3_client *client)
+{
+ struct t3cdev *tdev;
+
+ mutex_lock(cxgb3_db_lock);
+ list_add_tail(client-client_list, client_list);
+
+ if (client-add) {
+ list_for_each_entry(tdev, ofld_dev_list, ofld_dev_list) {
+ if (offload_activated(tdev))
+ client-add(tdev);
+ }
+ }
+ mutex_unlock(cxgb3_db_lock);
+}
+
+EXPORT_SYMBOL(cxgb3_register_client);
+
+/**
+ * cxgb3_unregister_client - unregister an offload client
+ * @client: the client
+ *
+ * Remove the client to the client list,
+ * and call backs the client for each activated offload device.
+ */
+void cxgb3_unregister_client(struct cxgb3_client *client)
+{
+ struct t3cdev *tdev;
+
+ mutex_lock(cxgb3_db_lock);
+ list_del(client-client_list);
+
+ if (client-remove) {
+ list_for_each_entry(tdev, ofld_dev_list, ofld_dev_list) {
+ if (offload_activated(tdev))
+ client-remove(tdev);
+ }
+ }
+ mutex_unlock(cxgb3_db_lock);
+}
+
+EXPORT_SYMBOL(cxgb3_unregister_client);
+
+/**
+ * cxgb3_add_clients - activate registered clients for an offload device
+ * @tdev: the offload device
+ *
+ * Call backs all registered clients once a offload device is activated
+ */
+void cxgb3_add_clients(struct t3cdev *tdev)
+{
+ struct cxgb3_client *client;
+
+ mutex_lock(cxgb3_db_lock);
+ list_for_each_entry(client, client_list, client_list) {
+ if (client-add)
+ client-add(tdev);
+ }
+ mutex_unlock(cxgb3_db_lock);
+}
+
+/**
+ * cxgb3_remove_clients - deactivates registered clients
+ *for an
[PATCH 6/10] cxgb3 - on board memory, MAC and PHY
From: Divy Le Ray [EMAIL PROTECTED]
This patch implements on board memory, MAC and PHY management
for the Chelsio T3 network adapter's driver.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/ael1002.c | 231 ++
drivers/net/cxgb3/mc5.c | 456 +++
drivers/net/cxgb3/vsc8211.c | 208
drivers/net/cxgb3/xgmac.c | 389 +
4 files changed, 1284 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c
new file mode 100755
index 000..5f4eb7e
--- /dev/null
+++ b/drivers/net/cxgb3/ael1002.c
@@ -0,0 +1,231 @@
+/*
+ * This file is part of the Chelsio T3 Ethernet driver.
+ *
+ * Copyright (C) 2005-2006 Chelsio Communications. All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+#include common.h
+#include regs.h
+
+enum {
+ AEL100X_TX_DISABLE = 9,
+ AEL100X_TX_CONFIG1 = 0xc002,
+ AEL1002_PWR_DOWN_HI = 0xc011,
+ AEL1002_PWR_DOWN_LO = 0xc012,
+ AEL1002_XFI_EQL = 0xc015,
+ AEL1002_LB_EN = 0xc017,
+
+ LASI_CTRL = 0x9002,
+ LASI_STAT = 0x9005
+};
+
+static void ael100x_txon(struct cphy *phy)
+{
+ int tx_on_gpio = phy-addr == 0 ? F_GPIO7_OUT_VAL : F_GPIO2_OUT_VAL;
+
+ msleep(100);
+ t3_set_reg_field(phy-adapter, A_T3DBG_GPIO_EN, 0, tx_on_gpio);
+ msleep(30);
+}
+
+static int ael1002_power_down(struct cphy *phy, int enable)
+{
+ int err;
+
+ err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL100X_TX_DISABLE, !!enable);
+ if (!err)
+ err = t3_mdio_change_bits(phy, MDIO_DEV_PMA_PMD, MII_BMCR,
+ BMCR_PDOWN, enable ? BMCR_PDOWN : 0);
+ return err;
+}
+
+static int ael1002_reset(struct cphy *phy, int wait)
+{
+ int err;
+
+ if ((err = ael1002_power_down(phy, 0)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL100X_TX_CONFIG1, 1)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_PWR_DOWN_HI, 0)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_PWR_DOWN_LO, 0)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_XFI_EQL, 0x18)) ||
+ (err = t3_mdio_change_bits(phy, MDIO_DEV_PMA_PMD, AEL1002_LB_EN,
+ 0, 1 5)))
+ return err;
+ return 0;
+}
+
+static int ael1002_intr_noop(struct cphy *phy)
+{
+ return 0;
+}
+
+static int ael100x_get_link_status(struct cphy *phy, int *link_ok,
+ int *speed, int *duplex, int *fc)
+{
+ if (link_ok) {
+ unsigned int status;
+ int err = mdio_read(phy, MDIO_DEV_PMA_PMD, MII_BMSR, status);
+
+ /*
+* BMSR_LSTATUS is latch-low, so if it is 0 we need to read it
+* once more to get the current link state.
+*/
+ if (!err !(status BMSR_LSTATUS))
+ err = mdio_read(phy, MDIO_DEV_PMA_PMD, MII_BMSR,
+ status);
+ if (err)
+ return err;
+ *link_ok = !!(status BMSR_LSTATUS);
+ }
+ if (speed)
+ *speed = SPEED_1;
+ if (duplex)
+ *duplex = DUPLEX_FULL;
+ return 0;
+}
+
+static struct cphy_ops ael1002_ops = {
+ .reset = ael1002_reset,
+ .intr_enable = ael1002_intr_noop,
+ .intr_disable = ael1002_intr_noop,
+ .intr_clear = ael1002_intr_noop,
+ .intr_handler = ael1002_intr_noop,
+ .get_link_status = ael100x_get_link_status,
+ .power_down = ael1002_power_down,
+};
+
+void t3_ael1002_phy_prep(struct cphy *phy, struct adapter *adapter,
+int phy_addr, const struct mdio_ops *mdio_ops)
+{
+ cphy_init(phy, adapter, phy_addr, ael1002_ops, mdio_ops);
+ ael100x_txon(phy);
+}
+
+static int ael1006_reset(struct cphy *phy, int wait)
+{
+ return t3_phy_reset(phy, MDIO_DEV_PMA_PMD, wait);
+}
+
+static int ael1006_intr_enable(struct cphy *phy)
+{
+ return mdio_write(phy, MDIO_DEV_PMA_PMD, LASI_CTRL, 1);
+}
+
+static int ael1006_intr_disable(struct cphy *phy)
+{
+ return mdio_write(phy, MDIO_DEV_PMA_PMD, LASI_CTRL, 0);
+}
+
+static int ael1006_intr_clear(struct cphy *phy)
+{
+ u32 val;
+
+ return mdio_read(phy, MDIO_DEV_PMA_PMD, LASI_STAT, val);
+}
+
+static int ael1006_intr_handler(struct cphy *phy)
+{
+ unsigned int status;
+ int err = mdio_read(phy, MDIO_DEV_PMA_PMD, LASI_STAT, status);
+
+ if (err)
+ return err;
+ return (status 1) ? cphy_cause_link_change : 0;
+}
+
Re: Marvell Libertas wifi
On 12/7/06, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2006-12-07 at 12:32 -0500, Alex Deucher wrote: I just wanted to check on the status of the libertas driver from Marvell for the OLPC project. I haven't really been able to find out The driver needs quite a bit of love. It's only been used for embedded devices so far and has quite a few NDIS-isms sprinkled throughout. It's also something like 30,000 LoC, which is completely bogus. There's no reason it should be that large given that it's a FullMAC-type part. We're slowly working on cleaning it up for submission to the kernel. That process will probably take until after the holidays. We are removing unused code/defines, cleaning up WEXT compliance, making operations like association and scanning asynchronous, converting private IOCTLs to debugfs, fixing the power-saving code, and adding draft 802.11s wireless mesh functionality to the firmware and the driver. Are you developing a device based on the 8388? AFAIK, the chip does not appear in any consumer devices that are generally available to the public, and certainly isn't sold to Linksys or DLink for consumer USB dongles. It does show up in embedded situations like the Nokia N80 mobile phone and a few other small gadgets like that. much about this driver other than the commits to the olpc and infradead libertas git trees. The olpc laptop uses the usb interface Correct; the 8388 module is connected directly to the USB traces coming out of the 5536 Geode companion chip on the OLPC motherboard. and that seems to be what is supported at the moment (although some comments in the code allude to pci and sdio interfaces as well). Does Yes; the part evidently has other interface variants, though code for those variants was not provided in the initial driver sources which Marvell GPL-ed in April. anyone know what the plan is for merging this driver into mainline? What about pci support? Did Marvell donate any code for the PCI interface? If not how hard would it be to add PCI support? I No code for PCI was donated, and we don't have any 8388 PCI cards at OLPC. requested databooks from Marvell months ago, but never got anywhere. I'd like to see better support for this chip and would be willing to help out. Any updates would be much appreciated. Be aware that I _think_ there are a few chips in the Libertas line; we are using the 8388. The current driver only supports that specific part. That said, if you've got hardware, we'd love patches, certainly accept patches that provided PCI support and fixed bugs in the driver. We may also be able to provide USB 8388 reference dongles for people willing to help out with the development of the driver. Yes, that appears to be the case. I just wasn't sure how similar/dissimilar they are. I have a 11ab:1fa7 on my motherboard, and I've seen quite a few Marvel chips floating around on cardbus and pci cards. I'm hoping the cores are pretty similar and one could just add some pci glue to make the olpc driver work. Does anyone at the olpc have any contacts at Marvell that could clarify the situation or might know if they are willing to release the code for the pci variants, etc.? Thanks, Alex Cheers, Dan Thanks, Alex PS, please CC: me on replies as I'm not on this list. - 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: [NETLINK]: Restore API compatibility of address and neighbour bits
From: David Woodhouse [EMAIL PROTECTED] Date: Thu, 07 Dec 2006 11:28:28 + On Thu, 2006-12-07 at 11:55 +0100, Thomas Graf wrote: Restore API compatibility due to bits moved from rtnetlink.h to separate headers. For 2.6.19.1 too, please. I will, thanks for reminding me. - 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 7/10] cxgb3 - offload header files
From: Divy Le Ray [EMAIL PROTECTED]
This patch implements the offload operations header files
for the Chelsio T3 network adapter's driver.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/cxgb3_ctl_defs.h | 142
drivers/net/cxgb3/cxgb3_defs.h | 99 ++
drivers/net/cxgb3/cxgb3_offload.h | 193 +
drivers/net/cxgb3/l2t.h| 143
drivers/net/cxgb3/t3_cpl.h | 1426
drivers/net/cxgb3/t3cdev.h | 72 ++
6 files changed, 2075 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_ctl_defs.h
b/drivers/net/cxgb3/cxgb3_ctl_defs.h
new file mode 100755
index 000..0fdc365
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_ctl_defs.h
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2003-2006 Chelsio Communications. All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+#ifndef _CXGB3_OFFLOAD_CTL_DEFS_H
+#define _CXGB3_OFFLOAD_CTL_DEFS_H
+
+enum {
+ GET_MAX_OUTSTANDING_WR,
+ GET_TX_MAX_CHUNK,
+ GET_TID_RANGE,
+ GET_STID_RANGE,
+ GET_RTBL_RANGE,
+ GET_L2T_CAPACITY,
+ GET_MTUS,
+ GET_WR_LEN,
+ GET_IFF_FROM_MAC,
+ GET_DDP_PARAMS,
+ GET_PORTS,
+
+ ULP_ISCSI_GET_PARAMS,
+ ULP_ISCSI_SET_PARAMS,
+
+ RDMA_GET_PARAMS,
+ RDMA_CQ_OP,
+ RDMA_CQ_SETUP,
+ RDMA_CQ_DISABLE,
+ RDMA_CTRL_QP_SETUP,
+ RDMA_GET_MEM,
+};
+
+/*
+ * Structure used to describe a TID range. Valid TIDs are [base, base+num).
+ */
+struct tid_range {
+ unsigned int base; /* first TID */
+ unsigned int num; /* number of TIDs in range */
+};
+
+/*
+ * Structure used to request the size and contents of the MTU table.
+ */
+struct mtutab {
+ unsigned int size; /* # of entries in the MTU table */
+ const unsigned short *mtus; /* the MTU table values */
+};
+
+struct net_device;
+
+/*
+ * Structure used to request the adapter net_device owning a given MAC address.
+ */
+struct iff_mac {
+ struct net_device *dev; /* the net_device */
+ const unsigned char *mac_addr; /* MAC address to lookup */
+ u16 vlan_tag;
+};
+
+struct pci_dev;
+
+/*
+ * Structure used to request the TCP DDP parameters.
+ */
+struct ddp_params {
+ unsigned int llimit;/* TDDP region start address */
+ unsigned int ulimit;/* TDDP region end address */
+ unsigned int tag_mask; /* TDDP tag mask */
+ struct pci_dev *pdev;
+};
+
+struct adap_ports {
+ unsigned int nports;/* number of ports on this adapter */
+ struct net_device *lldevs[2];
+};
+
+/*
+ * Structure used to return information to the iscsi layer.
+ */
+struct ulp_iscsi_info {
+ unsigned int offset;
+ unsigned int llimit;
+ unsigned int ulimit;
+ unsigned int tagmask;
+ unsigned int pgsz3;
+ unsigned int pgsz2;
+ unsigned int pgsz1;
+ unsigned int pgsz0;
+ unsigned int max_rxsz;
+ unsigned int max_txsz;
+ struct pci_dev *pdev;
+};
+
+/*
+ * Structure used to return information to the RDMA layer.
+ */
+struct rdma_info {
+ unsigned int tpt_base; /* TPT base address */
+ unsigned int tpt_top; /* TPT last entry address */
+ unsigned int pbl_base; /* PBL base address */
+ unsigned int pbl_top; /* PBL last entry address */
+ unsigned int rqt_base; /* RQT base address */
+ unsigned int rqt_top; /* RQT last entry address */
+ unsigned int udbell_len;/* user doorbell region length */
+ unsigned long udbell_physbase; /* user doorbell physical start addr */
+ void __iomem *kdb_addr; /* kernel doorbell register address */
+ struct pci_dev *pdev; /* associated PCI device */
+};
+
+/*
+ * Structure used to request an operation on an RDMA completion queue.
+ */
+struct rdma_cq_op {
+ unsigned int id;
+ unsigned int op;
+ unsigned int credits;
+};
+
+/*
+ * Structure used to setup RDMA completion queues.
+ */
+struct rdma_cq_setup {
+ unsigned int id;
+ unsigned long long base_addr;
+ unsigned int size;
+ unsigned int credits;
+ unsigned int credit_thres;
+ unsigned int ovfl_mode;
+};
+
+/*
+ * Structure used to setup the RDMA control egress context.
+ */
+struct rdma_ctrlqp_setup {
+ unsigned long long base_addr;
+ unsigned int size;
+};
+#endif /* _CXGB3_OFFLOAD_CTL_DEFS_H */
diff --git a/drivers/net/cxgb3/cxgb3_defs.h b/drivers/net/cxgb3/cxgb3_defs.h
new file mode 100755
index 000..82344c2
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_defs.h
@@ -0,0 +1,99 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c)
[PATCH 9/10] cxgb3 - register definitions
From: Divy Le Ray [EMAIL PROTECTED] This patch implements the registers definitions for the Chelsio network adapter's driver. Signed-off-by: Divy Le Ray [EMAIL PROTECTED] --- drivers/net/cxgb3/regs.h | 2177 ++ 1 files changed, 2177 insertions(+), 0 deletions(-) diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h new file mode 100755 index 000..11a0864 --- /dev/null +++ b/drivers/net/cxgb3/regs.h @@ -0,0 +1,2177 @@ +#define A_SG_CONTROL 0x0 + +#define S_DROPPKT20 +#define V_DROPPKT(x) ((x) S_DROPPKT) +#define F_DROPPKTV_DROPPKT(1U) + +#define S_EGRGENCTRL19 +#define V_EGRGENCTRL(x) ((x) S_EGRGENCTRL) +#define F_EGRGENCTRLV_EGRGENCTRL(1U) + +#define S_USERSPACESIZE14 +#define M_USERSPACESIZE0x1f +#define V_USERSPACESIZE(x) ((x) S_USERSPACESIZE) + +#define S_HOSTPAGESIZE11 +#define M_HOSTPAGESIZE0x7 +#define V_HOSTPAGESIZE(x) ((x) S_HOSTPAGESIZE) + +#define S_FLMODE9 +#define V_FLMODE(x) ((x) S_FLMODE) +#define F_FLMODEV_FLMODE(1U) + +#define S_PKTSHIFT6 +#define M_PKTSHIFT0x7 +#define V_PKTSHIFT(x) ((x) S_PKTSHIFT) + +#define S_ONEINTMULTQ5 +#define V_ONEINTMULTQ(x) ((x) S_ONEINTMULTQ) +#define F_ONEINTMULTQV_ONEINTMULTQ(1U) + +#define S_BIGENDIANINGRESS2 +#define V_BIGENDIANINGRESS(x) ((x) S_BIGENDIANINGRESS) +#define F_BIGENDIANINGRESSV_BIGENDIANINGRESS(1U) + +#define S_ISCSICOALESCING1 +#define V_ISCSICOALESCING(x) ((x) S_ISCSICOALESCING) +#define F_ISCSICOALESCINGV_ISCSICOALESCING(1U) + +#define S_GLOBALENABLE0 +#define V_GLOBALENABLE(x) ((x) S_GLOBALENABLE) +#define F_GLOBALENABLEV_GLOBALENABLE(1U) + +#define S_AVOIDCQOVFL24 +#define V_AVOIDCQOVFL(x) ((x) S_AVOIDCQOVFL) +#define F_AVOIDCQOVFLV_AVOIDCQOVFL(1U) + +#define S_OPTONEINTMULTQ23 +#define V_OPTONEINTMULTQ(x) ((x) S_OPTONEINTMULTQ) +#define F_OPTONEINTMULTQV_OPTONEINTMULTQ(1U) + +#define S_CQCRDTCTRL22 +#define V_CQCRDTCTRL(x) ((x) S_CQCRDTCTRL) +#define F_CQCRDTCTRLV_CQCRDTCTRL(1U) + +#define A_SG_KDOORBELL 0x4 + +#define S_SELEGRCNTX31 +#define V_SELEGRCNTX(x) ((x) S_SELEGRCNTX) +#define F_SELEGRCNTXV_SELEGRCNTX(1U) + +#define S_EGRCNTX0 +#define M_EGRCNTX0x +#define V_EGRCNTX(x) ((x) S_EGRCNTX) + +#define A_SG_GTS 0x8 + +#define S_RSPQ29 +#define M_RSPQ0x7 +#define V_RSPQ(x) ((x) S_RSPQ) +#define G_RSPQ(x) (((x) S_RSPQ) M_RSPQ) + +#define S_NEWTIMER16 +#define M_NEWTIMER0x1fff +#define V_NEWTIMER(x) ((x) S_NEWTIMER) + +#define S_NEWINDEX0 +#define M_NEWINDEX0x +#define V_NEWINDEX(x) ((x) S_NEWINDEX) + +#define A_SG_CONTEXT_CMD 0xc + +#define S_CONTEXT_CMD_OPCODE28 +#define M_CONTEXT_CMD_OPCODE0xf +#define V_CONTEXT_CMD_OPCODE(x) ((x) S_CONTEXT_CMD_OPCODE) + +#define S_CONTEXT_CMD_BUSY27 +#define V_CONTEXT_CMD_BUSY(x) ((x) S_CONTEXT_CMD_BUSY) +#define F_CONTEXT_CMD_BUSYV_CONTEXT_CMD_BUSY(1U) + +#define S_CQ_CREDIT20 + +#define M_CQ_CREDIT0x7f + +#define V_CQ_CREDIT(x) ((x) S_CQ_CREDIT) + +#define G_CQ_CREDIT(x) (((x) S_CQ_CREDIT) M_CQ_CREDIT) + +#define S_CQ19 + +#define V_CQ(x) ((x) S_CQ) +#define F_CQV_CQ(1U) + +#define S_RESPONSEQ18 +#define V_RESPONSEQ(x) ((x) S_RESPONSEQ) +#define F_RESPONSEQV_RESPONSEQ(1U) + +#define S_EGRESS17 +#define V_EGRESS(x) ((x) S_EGRESS) +#define F_EGRESSV_EGRESS(1U) + +#define S_FREELIST16 +#define V_FREELIST(x) ((x) S_FREELIST) +#define F_FREELISTV_FREELIST(1U) + +#define S_CONTEXT0 +#define M_CONTEXT0x +#define V_CONTEXT(x) ((x) S_CONTEXT) + +#define G_CONTEXT(x) (((x) S_CONTEXT) M_CONTEXT) + +#define A_SG_CONTEXT_DATA0 0x10 + +#define A_SG_CONTEXT_DATA1 0x14 + +#define A_SG_CONTEXT_DATA2 0x18 + +#define A_SG_CONTEXT_DATA3 0x1c + +#define A_SG_CONTEXT_MASK0 0x20 + +#define A_SG_CONTEXT_MASK1 0x24 + +#define A_SG_CONTEXT_MASK2 0x28 + +#define A_SG_CONTEXT_MASK3 0x2c + +#define A_SG_RSPQ_CREDIT_RETURN 0x30 + +#define S_CREDITS0 +#define M_CREDITS0x +#define V_CREDITS(x) ((x) S_CREDITS) + +#define A_SG_DATA_INTR 0x34 + +#define S_ERRINTR31 +#define V_ERRINTR(x) ((x) S_ERRINTR) +#define F_ERRINTRV_ERRINTR(1U) + +#define A_SG_HI_DRB_HI_THRSH 0x38 + +#define A_SG_HI_DRB_LO_THRSH 0x3c + +#define A_SG_LO_DRB_HI_THRSH 0x40 + +#define A_SG_LO_DRB_LO_THRSH 0x44 + +#define A_SG_RSPQ_FL_STATUS 0x4c + +#define S_RSPQ0DISABLED8 + +#define A_SG_EGR_RCQ_DRB_THRSH 0x54 + +#define S_HIRCQDRBTHRSH16 +#define M_HIRCQDRBTHRSH0x7ff +#define V_HIRCQDRBTHRSH(x) ((x) S_HIRCQDRBTHRSH) + +#define S_LORCQDRBTHRSH0 +#define M_LORCQDRBTHRSH0x7ff +#define V_LORCQDRBTHRSH(x) ((x) S_LORCQDRBTHRSH) + +#define A_SG_EGR_CNTX_BADDR 0x58 + +#define A_SG_INT_CAUSE 0x5c + +#define S_RSPQDISABLED3 +#define V_RSPQDISABLED(x) ((x) S_RSPQDISABLED) +#define F_RSPQDISABLEDV_RSPQDISABLED(1U) + +#define S_RSPQCREDITOVERFOW2 +#define V_RSPQCREDITOVERFOW(x) ((x) S_RSPQCREDITOVERFOW)
