Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
On Thu, Apr 27, 2006 at 01:09:18PM -0700, David S. Miller ([EMAIL PROTECTED]) wrote: Evgeniy, the difference between this and your work is that you did not have an intelligent piece of hardware that could be told to recognize flows, and only put packets for a specific flow into that's flow's buffer pool. There are the most intellegent NICs which use MMIO copy like Realtek 8139 :) which were used in receiving zero-copy [1] project. There was special alorithm researched for receiving zero-copy [1] to allow to put not page-aligned TCP frames into pages, but there was other problem when page was committed, since no byte commit is allowed in VFS. In this case we do not have that problem, but instead we must force userspace to be very smart when dealing with mapped buffers, instead of simple recv(). And for sending it must be even smarter, since data must be properly aligned. And what about crappy hardware which can DMA only into limited memory area, or NIC that can not do sg? Or do we need remapping for NIC that can not do checksum calculation? If we want to dma data from nic into premapped userspace area, this will strike with message sizes/misalignment/slow read and so on, so preallocation has even more problems. I do not really think this is an issue, we put the full packet into user space and teach it where the offset is to the actual data. We'll do the same things we do today to try and get the data area aligned. User can do whatever is logical and relevant on his end to deal with strange cases. In fact we can specify that card has to take some care to get data area of packet aligned on say an 8 byte boundary or something like that. When we don't have hardware assist, we are going to be doing copies. Userspace must be too smart, and as we saw with various java tests, it can not be so even now. And what if pages are shared and several threads are trying to write into the same remapped area? Will we use COW and be blamed like Mach and FreeBSD developers? :) I do think that significant win in VJ's tests belongs not to remapping and cache-oriented changes, but to move all protocol processing into process' context. I partly disagree. The biggest win is eliminating all of the control overhead (all of softint RX + protocol demux + IP route lookup + socket lookup is turned into single flow demux), and the SMP safe data structure which makes it realistic enough to always move the bulk of the packet work to the socket's home cpu. I do not think userspace protocol implementation buys enough to justify it. We have to do the protection switch in and out of kernel space anyways, so why not still do the protected protocol processing work in the kernel? It is still being done on the user's behalf, contributes to his time slice, and avoids all of the terrible issues of userspace protocol implementations. After hard irq softirq is scheduled, then later userspace is scheduled, at least 2 context switch just to move a packet, and slow userspace code is interrupted by both irqs again... I run some tests on ppc32 embedded boards which showed that rescheduling latency tend to have milliseconds delay sometimes (about 4 running processes on 200mhz cpu), although we do not have some real-time requirements here it is not a good sign... And I also want to note that even if the whole idea explodes and cannot be made to work, there are good arguments for transitioning to SKB'less drivers for their own sake. So work will really not be lost. Let's have 100 different implementations of net channels! :-) :) -- Evgeniy Polyakov - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: So the real issue is when there is an intelligent device that uses hardware packet classification to place the packet in the correct ring. We don't want to bypass packet filtering, but it would be terribly wasteful to reclassify the packet. Intelligent NICs will have packet classification capabilities to support RDMA and iSCSI. Those capabilities should be available to benefit SOCK_STREAM and SOCK_DGRAM users as well without it being a choice of either turning all stack control over to the NIC or ignorign all NIC capabilities beyound pretending to be a dumb Ethernet NIC. Btw, how is it supposed to work without header split capabale hardware? -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: E1000 stopped transmitting in rc3.
From: Auke Kok [EMAIL PROTECTED] Date: Thu, 27 Apr 2006 18:54:28 -0700 Dave Jones wrote: With 2.6.17-rc3, my E1000 won't get a dhcp lease. Looking at tcpdump and ifconfig output, it's easy to see why. It's recieving packets, but the packets transmitted field of ifconfig never increases. The last version I have built that worked ok was 2.6.17rc2-git3 *puzzled* the only patch between 2.6.17rc2 and 2.6.17rc3 contains an rx-path patch, but nothing that affects tx. All the other patches sent earlier are queued for 2.6.18 so they don't apply. If the rx path is corrupting the packets or providing bad checksums, there will be nothing to transmit back. So RX changes could explain the behavior. - To unsubscribe from this list: send 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: [Fireflier-devel] Re: [PATCH][RFC] Security marking
Török Edwin wrote: Patrick what is the status of solving the skfilter issues? Can I help with testing patches, etc.? Not yet. If nothing gets in between I plan to get the patches ready next week. On Monday 20 February 2006 18:42, Patrick McHardy wrote: Confirmation of conntrack entries. They shouldn't be confirmed before packets have passed the socket hooks. This is the tricky part because we don't know if packets will be delivered to a raw socket or not when calling the regular LOCAL_IN hook. The only way to solve this seems to be to use the socket hooks for all incoming packets, that way we can defer confirmation unconditionally. Are there any problems with using socket hooks for all packets? Not really, just that some protocols don't use sockets, so its a bit pointless for them. OTOH it should make rule management easier if everything can be done in the same table. The nicest way would be to just move the regular LOCAL_IN hook to the socket hooks, but this doesn't work with SNAT in LOCAL_IN because the socket lookup needs the already NATed address. Move just the non SNAT part of LOCAL_IN to socket hooks?(does this make sense?) That would be my prefered way, but it changes user-visible behaviour. Currently filtering is done before SNAT, this change would reverse that. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 10:10:54 +0400 On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: So the real issue is when there is an intelligent device that uses hardware packet classification to place the packet in the correct ring. We don't want to bypass packet filtering, but it would be terribly wasteful to reclassify the packet. Intelligent NICs will have packet classification capabilities to support RDMA and iSCSI. Those capabilities should be available to benefit SOCK_STREAM and SOCK_DGRAM users as well without it being a choice of either turning all stack control over to the NIC or ignorign all NIC capabilities beyound pretending to be a dumb Ethernet NIC. Btw, how is it supposed to work without header split capabale hardware? I do not see header splitting as a requirement, let the raw headers sit in the user queue and provide an offset to the data. All of this page alignment stuff is unnecessary complexity. I know you think applications are too dumb to be expected to handle these kinds of things, but how many apps do you expect to convert over to these new interfaces? The ones that matter will, and great care will be made by the programmer who does this. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, Apr 28, 2006 at 12:20:27AM -0700, David S. Miller ([EMAIL PROTECTED]) wrote: Btw, how is it supposed to work without header split capabale hardware? I do not see header splitting as a requirement, let the raw headers sit in the user queue and provide an offset to the data. All of this page alignment stuff is unnecessary complexity. I know you think applications are too dumb to be expected to handle these kinds of things, but how many apps do you expect to convert over to these new interfaces? The ones that matter will, and great care will be made by the programmer who does this. Ugh, so it will not ring buffer of data _flow_, but ring buffer of (header+data) packets. Definitely, userspace application must be very smart to deal with ip/tcp/option headers... -- Evgeniy Polyakov - To unsubscribe from this list: send 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: IP1000 gigabit nic driver
Hi Francois, On Apr 27 at 08:56:27, Francois Romieu wrote: /me goes to http://www.icplus.com.tw/driver-pp-IP1000A.html $ unzip -c IP1000A-Linux-driver-v2.09f.zip | grep MODULE_LICENSE MODULE_LICENSE(GPL); Thanks, i didn't notice it ;-) It's a bit bloaty but it does not seem too bad (not mergeable as is though). Do you volunteer to test random cra^W^W carefully engineered code on your computer to help the rework/merging process ? Yes, i am. Send me all the the cra ;-), i'm ready to test it. cheers, -- David Gómez Jabber ID: [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: IP1000 gigabit nic driver
Hi David, On Apr 27 at 11:26:07, David Vrabel wrote: I finally got around to putting a 2nd NIC in my box that has one of this chips and was going to start fixing the driver up and preparing it for submission this weekend. Great! Or I might try rewriting from scratch based on the datasheet depending on how horrific the code looks on closer inspection. For what i've seen, the code seems quite readable. Not got a whole lot of time to do this so no timescale for completion... I could help. What things do you think need to be fixed before submitting the driver? cheers, -- David Gómez Jabber ID: [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/3] Rough VJ Channel Implementation - vj_core.patch
On Thu, 2006-04-27 at 14:12 -0700, Caitlin Bestler wrote: So the real issue is when there is an intelligent device that uses hardware packet classification to place the packet in the correct ring. We don't want to bypass packet filtering, but it would be terribly wasteful to reclassify the packet. Intelligent NICs will have packet classification capabilities to support RDMA and iSCSI. Those capabilities should be available to benefit SOCK_STREAM and SOCK_DGRAM users as well without it being a choice of either turning all stack control over to the NIC or ignorign all NIC capabilities beyound pretending to be a dumb Ethernet NIC. For example, counting packets within an approved connection is a valid goal that the final solution should support. But would a simple count be sufficient, or do we truly need the full flexibility currently found in netfilter? Note that the problem space AFAICT includes strange advanced routing setups, ingress qos and possibly others, not just netfilter. But perhaps the same solutions apply, so I'll concentrate on nf. If we start with a disable direct netchannels when netfilter hooks registered, we would inevitably refine it to disable some netchannels when netfilter hooks registered. The worst case for this filtering based on connection tracking, with its constantly changing effects as things time out. Hard problem. Is it time to re-examine the Grand Unified Lookup which Dave mentions every few years? 8) My assumption is that each input ring has a matching output ring, and that the output ring cannot be used to send packets that would not be matched by the reverse rule for the paired input ring. So the information that supports enforcing that rule needs to be stored somewhere other than the ring itself. Ah, this is a different problem. Our idea was to have a syscall which would check sanitize the buffers for output. To do this, you need the ability to chain buffers (a simple next entry in the header, for us). Sanitization would copy the header into a global buffer (ie. not one reachable by userspace), check the flowid, and chain on the rest of the user buffer. After it had sanitized the buffers, it would activate the NIC, which would only send out buffers which started with a kernel buffer. Of course, the first step (CAP_NET_RAW-only) wouldn't need this. And, if the sanitize_and_send syscall were PF_VJCHAN's write(), then the contents of the write() could actually be the header: userspace would never deal with chained buffers. Finally, it's not clear how one should sanely mix this with sendfile etc. Maybe you don't, and only use this for RDMA, etc. Cheers! Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol - To unsubscribe from this list: send 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 22/32] rt2x00: Allocate ring structures in single array
On Fri, 28 Apr 2006 00:03:13 +0200, Ivo van Doorn wrote:
Use seperate function to convert a dscape ring ID
to the address of the actual ring.
Just minor things:
[...]
@@ -1386,20 +1412,19 @@ rt2400pci_tx(struct net_device *net_dev,
rt2x00_register_read(rt2x00pci, TXCSR0, reg);
- if (control-queue == IEEE80211_TX_QUEUE_DATA0) {
- ring = rt2x00pci-prio;
- rt2x00_set_field32(reg, TXCSR0_KICK_PRIO, 1);
- } else if (control-queue == IEEE80211_TX_QUEUE_DATA1) {
- ring = rt2x00pci-tx;
- rt2x00_set_field32(reg, TXCSR0_KICK_TX, 1);
- } else if (control-queue == IEEE80211_TX_QUEUE_AFTER_BEACON) {
- ring = rt2x00pci-atim;
- rt2x00_set_field32(reg, TXCSR0_KICK_ATIM, 1);
- } else {
- ERROR(Frame received for invalid queue.);
+ /*
+ * Determine which ring to put packet on.
+ */
+ ring = rt2x00pci_get_ring(rt2x00pci, control-queue);
+ if (unlikely(!ring)) {
Should not happen. Maybe some message that user should report a bug?
+ ERROR(Attempt to send packet over invalid queue %d.\n,
+ control-queue);
return NET_RX_DROP;
}
+ if (rt2x00_ring_full(ring))
+ return NET_RX_DROP;
NET_XMIT_DROP?
+
entry = rt2x00_get_data_entry(ring);
txd = entry-desc_addr;
[...]
@@ -1780,14 +1813,17 @@ rt2400pci_conf_tx(struct net_device *net
int queue, const struct ieee80211_tx_queue_params *params)
{
struct rt2x00_pci *rt2x00pci = ieee80211_dev_hw_data(net_dev);
- struct data_ring*ring;
+ struct data_ring*ring = rt2x00pci-ring[RING_TX];
- if (queue == IEEE80211_TX_QUEUE_DATA0)
- ring = rt2x00pci-prio;
- else if (queue == IEEE80211_TX_QUEUE_DATA1)
- ring = rt2x00pci-tx;
- else
- return -EINVAL;
+ /*
+ * We don't support variating cw_min and cw_max variables
+ * per queue. So by default we only configure the TX queue,
+ * and ignore all other configurations.
+ */
+ if (queue != IEEE80211_TX_QUEUE_DATA0) {
+ NOTICE(Ignoring configuration for queue %d.\n, queue);
+ return 0;
Is there a reason for not returning a proper error code?
+ }
memcpy(ring-tx_params, params, sizeof(*params));
Ditto for rt2500pci and rt2500usb.
Thanks,
--
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: IP1000 gigabit nic driver
On 4/28/06, David Gómez [EMAIL PROTECTED] wrote: I could help. What things do you think need to be fixed before submitting the driver? Needs some serious coding style cleanup and conversion to proper 2.6 APIs for starters. - To unsubscribe from this list: send 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 29/32] rt2x00: dscape compatibilitiy
On Fri, 28 Apr 2006 00:03:19 +0200, Ivo van Doorn wrote: Latest dscape patches have broken rt2x00, fix compile issues, and support the new features. @@ -2466,6 +2568,7 @@ rt2500pci_init_hw(struct rt2x00_pci *rt2 hw-no_tkip_wmm_hwaccel = 1; hw-extra_hdr_room = 0; hw-device_strips_mic = 0; + hw-monitor_during_oper = 1; You should not set this to 1 if you support only one interface at a time. Please add support for concurrent running of one regular (i.e. STA, IBSS, AP, WDS) interface plus arbitrary number of monitor interfaces or set monitor_during_oper to 0. (Yes, I know, I definitely must reserve some time to write a documentation about monitor mode support.) Thanks, -- 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 7/32] rt2x00: make vals static
Sie schrieben: From: Ivo van Doorn [EMAIL PROTECTED] The vals[] arrays in *_init_hw_channels can be made static to optimize memory and reduce stack size. What about static const? They are also constants, right? But please try first, if this helps in terms of code size. Regards Ingo Oeser - To unsubscribe from this list: send 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: IP1000 gigabit nic driver
Hi Pekka, On Apr 28 at 01:58:04, Pekka Enberg wrote: Needs some serious coding style cleanup and conversion to proper 2.6 APIs for starters. Ok, i could take care of that, and it's a good way of getting my hands dirty with kernel programming ;). David, if it's ok to you i'll do the cleanup thing. What about 2.4/2.2 code? It's supposed to stay for compatibility or it should be removed before submitting? cheers, -- David Gómez Jabber ID: [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 17/32] rt2x00: Put net_device structure in data_ring
Hi Ivo,
Ivo van Doorn wrote:
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-27 21:48:21.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-27 21:49:08.0 +0200
@@ -760,10 +760,8 @@ rt2400pci_write_tx_desc(
static void
rt2400pci_beacondone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
- struct rt2x00_pci *rt2x00pci = (struct rt2x00_pci*)ring-dev;
- struct net_device *net_dev = pci_get_drvdata(rt2x00pci-pci_dev);
- struct sk_buff *skb;
+ struct data_ring*ring = (struct data_ring*)data;
No need for a cast here.
In C you can cast from any struct pointer to void pointer and back
without problems.
@@ -784,8 +782,8 @@ static void
rt2400pci_rxdone(void *data)
{
struct data_ring*ring = (struct data_ring*)data;
No need for casting.
@@ -835,8 +834,8 @@ static void
rt2400pci_txdone(void *data)
{
struct data_ring*ring = (struct data_ring*)data;
No need for casting.
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-27 21:48:21.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-27 21:49:08.0 +0200
@@ -834,10 +834,8 @@ rt2500pci_write_tx_desc(
static void
rt2500pci_beacondone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
- struct rt2x00_pci *rt2x00pci = (struct rt2x00_pci*)ring-dev;
- struct net_device *net_dev = pci_get_drvdata(rt2x00pci-pci_dev);
- struct sk_buff *skb;
+ struct data_ring*ring = (struct data_ring*)data;
No need for casting.
Many more of them.
I guess you could just do a fgrep for *ring = (struct data_ring*)data;
Regards
Ingo Oeser
-
To unsubscribe from this list: send 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: IP1000 gigabit nic driver
On Apr 28 at 01:58:04, Pekka Enberg wrote: Needs some serious coding style cleanup and conversion to proper 2.6 APIs for starters. On Fri, 28 Apr 2006, David Gómezz wrote: Ok, i could take care of that, and it's a good way of getting my hands dirty with kernel programming ;). David, if it's ok to you i'll do the cleanup thing. What about 2.4/2.2 code? It's supposed to stay for compatibility or it should be removed before submitting? It's preferred not to have compatability cruft for 2.6 patch submissions, so I'd say kill them. Pekka - To unsubscribe from this list: send 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: IP1000 gigabit nic driver
Hi David,
On Fri, 28 Apr 2006, David Gómezz wrote:
Ok, i could take care of that, and it's a good way of getting my hands
dirty with kernel programming ;). David, if it's ok to you i'll do the
cleanup thing.
Here are some suggestions for coding style cleanups:
- Use Lindet for initial formatting
- Kill use of LINUX_VERSION_CODE macro for compatability
- Kill obfuscating macros. For example, IPG_DEV_KFREE_SKB and
IPG_DEVICE_TYPE.
- Move changelogs outside of source files
- Convert kmalloc/memset to kzalloc and kcalloc
- Remove redundant typecasts
- Remove dead code
- Use dev_{dbg,err,info,warn} for logging
- Remove unnecessary curly braces
- Use proper naming convention for things like Length and pPHYParam
- Convert macro functions to static inline functions for type safety
Pekka
-
To unsubscribe from this list: send 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: IP1000 gigabit nic driver
Hi David, David Gómez wrote: On Apr 28 at 01:58:04, Pekka Enberg wrote: Needs some serious coding style cleanup and conversion to proper 2.6 APIs for starters. Ok, i could take care of that, and it's a good way of getting my hands dirty with kernel programming ;). David, if it's ok to you i'll do the cleanup thing. Have fun! Great that you do this. What about 2.4/2.2 code? It's supposed to stay for compatibility or it should be removed before submitting? Usually it should be removed. The way to remove 2.4/2.2. code is by reimplementation of 2.6-APIs in seperate files and headers and not submitting these into latest kernel. Keep these somewhere else (e.g. a project web site). That way your drivers ALWAYS work with latest kernels and you notice breakage of backward compatiblity quite easily. If maintaining these parts becomes a pain with no gain, you can simply stop providing these yourself. #ifdef KERNEL_VERSON stuff in submitted drivers is generally not acceptable. Since it is hard to test these parts. I ported some off-tree drivers from 2.2 to 2.4. using this technique and it works good, reduces maintainence burden and keeps your driver current to latest APIs automatically. Regards Ingo Oeser - To unsubscribe from this list: send 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 20/32] rt2x00: byte ordering correctness
On Friday 28 April 2006 00:13, Christoph Hellwig wrote: On Fri, Apr 28, 2006 at 12:03:12AM +0200, Ivo van Doorn wrote: From: Ivo van Doorn [EMAIL PROTECTED] Fix various little/big endian conversions. rt2500pci should use cpu_to_le32 and rt2500usb should not. While you're at it can you add __be* annotations to the hardware datastructures so the endianess handling can be verified using sparse? I am not sure if that would be a wise idea, there is no byte ordering done in rt2500usb except for the EEPROM contents which is little endian. So when the module is used on a normal x86 platform, there won't be any big endian structures or fields. pgpwqPRhqDtIQ.pgp Description: PGP signature
Re: [PATCH 3/32] rt2x00: use pci_*_consistent for DMA mapping
On Friday 28 April 2006 00:11, Christoph Hellwig wrote: On Fri, Apr 28, 2006 at 12:02:52AM +0200, Ivo van Doorn wrote: From: Ivo van Doorn [EMAIL PROTECTED] Instead of dma_*_coherent use pci_*consistent functions. No point in doing that, quite reverse as you use the gfp_mask argument which is a (small) pessimation here. Would it be recommended that I replace the usb_alloc_buffers in the rt2570 driver with dma_*coherent? This would get the dma rings allocation and freeing a bit more generic between PCI and USB and could reduce some duplicate code between them. But I am not sure if there is any major difference between the two. pgp5vYfSMcY0c.pgp Description: PGP signature
Re: [PATCH 3/32] rt2x00: use pci_*_consistent for DMA mapping
On Fri, Apr 28, 2006 at 02:57:31PM +0200, Ivo van Doorn wrote: On Friday 28 April 2006 00:11, Christoph Hellwig wrote: On Fri, Apr 28, 2006 at 12:02:52AM +0200, Ivo van Doorn wrote: From: Ivo van Doorn [EMAIL PROTECTED] Instead of dma_*_coherent use pci_*consistent functions. No point in doing that, quite reverse as you use the gfp_mask argument which is a (small) pessimation here. Would it be recommended that I replace the usb_alloc_buffers in the rt2570 driver with dma_*coherent? This would get the dma rings allocation and freeing a bit more generic between PCI and USB and could reduce some duplicate code between them. But I am not sure if there is any major difference between the two. I don't have the full code for your driver anywhere near me so I can't comment on this. Maybe you could send the code of 'usb_alloc_buffers' for comments? ---end quoted text--- - To unsubscribe from this list: send 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/9] natsemi: Add support for using MII port with no PHY
On Thu, Apr 27, 2006 at 05:54:58AM -0400, Jeff Garzik wrote: Provide a module option which configures the natsemi driver to use the external MII port on the chip but ignore any PHYs that may be attached to it. The link state will be left as it was when the driver started and can The proper way to do this is via the force_media boolean flag found in several net drivers. I've had a look at several of the net drivers that implement this option (e100, smc91x, starfire and the shared code in mii.c). Unless I'm misreading the code it looks like the effect of this option in those drivers is to disable autonegotiation but still configure the PHY when the NIC is configured. That is a subset of what the patch does and isn't sufficient for the hardware this patch targets: sometimes there may be a PHY visible on the MII bus but with a different configuration to the natsemi or there may be no PHY present at all. In this case the code in the natsemi driver that configures the PHY to match the configuration of the natsemi also needs to be disabled. It looks like I should implement a force_media option and redo this patch to use that. -- You grabbed my hand and we fell into it, like a daydream - or a fever. - To unsubscribe from this list: send 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/32] rt2x00: use pci_*_consistent for DMA mapping
On Friday 28 April 2006 15:24, you wrote:
struct data_ring{
/*
* net_device where this ring belongs to.
*/
struct net_device *net_dev;
/*
* Work structure for bottom half interrupt handling.
*/
struct work_struct irq_work;
/*
* Base address for the device specific data entries.
*/
void*entry;
/*
* TX queue statistic info.
*/
struct ieee80211_tx_queue_stats_datastats;
/*
* TX Queue parameters.
*/
struct ieee80211_tx_queue_paramstx_params;
/*
* Base address for data ring.
*/
dma_addr_t data_dma;
void*data_addr;
/*
* Index variables.
*/
u8 index;
u8 index_done;
/*
* Size of device specific data entry structure.
*/
u16 entry_size;
/*
* Size of packet and descriptor in bytes.
*/
u16 data_size;
u16 desc_size;
} __attribute__ ((packed));
Why is this packed? I don't believe you write such a data
structure (which contains dscape specific structs) to some
device registers.
--
Greetings Michael.
pgpq9gdp4UPZF.pgp
Description: PGP signature
Re: [PATCH 20/32] rt2x00: byte ordering correctness
On Friday 28 April 2006 15:14, Christoph Hellwig wrote: On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote: I am not sure if that would be a wise idea, there is no byte ordering done in rt2500usb except for the EEPROM contents which is little endian. So when the module is used on a normal x86 platform, there won't be any big endian structures or fields. Well, then you'll need __le* annotation and the le*_to_cpu/cpu_to_le* instead. Any new driver should be endian clean. Not exactly true for rt2570, to correctly operate with the device, no endian conversions should be made at all. Not to big endian and not to little endian. The register should be send as a regular value with the byteordering equal to the byteordering of the currently used CPU. It has been tested to send only little endian or big endian values to the device on all CPU's, and in all cases it meant that the device would not function on CPU's with the other byte ordering. pgpzFqikPPu4I.pgp Description: PGP signature
Re: [PATCH 20/32] rt2x00: byte ordering correctness
On Friday 28 April 2006 15:31, you wrote: On Friday 28 April 2006 15:14, Christoph Hellwig wrote: On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote: I am not sure if that would be a wise idea, there is no byte ordering done in rt2500usb except for the EEPROM contents which is little endian. So when the module is used on a normal x86 platform, there won't be any big endian structures or fields. Well, then you'll need __le* annotation and the le*_to_cpu/cpu_to_le* instead. Any new driver should be endian clean. Not exactly true for rt2570, to correctly operate with the device, no endian conversions should be made at all. Not to big endian and not to little endian. The register should be send as a regular value with the byteordering equal to the byteordering of the currently used CPU. It has been tested to send only little endian or big endian values to the device on all CPU's, and in all cases it meant that the device would not function on CPU's with the other byte ordering. I guess you are confusing something here: MMIO access versus values in structs (for example) that are accessed through DMA (for example). -- Greetings Michael. pgpb8sTGogxvb.pgp Description: PGP signature
Re: [PATCH 3/32] rt2x00: use pci_*_consistent for DMA mapping
On Friday 28 April 2006 15:33, Michael Buesch wrote:
On Friday 28 April 2006 15:24, you wrote:
struct data_ring{
/*
* net_device where this ring belongs to.
*/
struct net_device *net_dev;
/*
* Work structure for bottom half interrupt handling.
*/
struct work_struct irq_work;
/*
* Base address for the device specific data entries.
*/
void*entry;
/*
* TX queue statistic info.
*/
struct ieee80211_tx_queue_stats_datastats;
/*
* TX Queue parameters.
*/
struct ieee80211_tx_queue_paramstx_params;
/*
* Base address for data ring.
*/
dma_addr_t data_dma;
void*data_addr;
/*
* Index variables.
*/
u8 index;
u8 index_done;
/*
* Size of device specific data entry structure.
*/
u16 entry_size;
/*
* Size of packet and descriptor in bytes.
*/
u16 data_size;
u16 desc_size;
} __attribute__ ((packed));
Why is this packed? I don't believe you write such a data
structure (which contains dscape specific structs) to some
device registers.
I can't remember actually, I believe this came from a patch we had received
last year with the legacy drivers from a user.
Since then most structures have received the __attribute__ ((packed)) tag.
I'll create a patch to remove the tags where they are not needed.
pgpJW4vipW0xP.pgp
Description: PGP signature
Re: [PATCH 7/32] rt2x00: make vals static
On Friday 28 April 2006 13:26, Ingo Oeser wrote: Sie schrieben: From: Ivo van Doorn [EMAIL PROTECTED] The vals[] arrays in *_init_hw_channels can be made static to optimize memory and reduce stack size. What about static const? They are also constants, right? But please try first, if this helps in terms of code size. Good idea, I'll create a patch to make them constant as well. pgpZPaAWlLiHl.pgp Description: PGP signature
Re: [PATCH 17/32] rt2x00: Put net_device structure in data_ring
On Friday 28 April 2006 13:45, Ingo Oeser wrote:
Hi Ivo,
Ivo van Doorn wrote:
diff -uprN
wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-27 21:48:21.0 +0200
+++
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-27 21:49:08.0 +0200
@@ -760,10 +760,8 @@ rt2400pci_write_tx_desc(
static void
rt2400pci_beacondone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
- struct rt2x00_pci *rt2x00pci = (struct rt2x00_pci*)ring-dev;
- struct net_device *net_dev = pci_get_drvdata(rt2x00pci-pci_dev);
- struct sk_buff *skb;
+ struct data_ring*ring = (struct data_ring*)data;
No need for a cast here.
In C you can cast from any struct pointer to void pointer and back
without problems.
@@ -784,8 +782,8 @@ static void
rt2400pci_rxdone(void *data)
{
struct data_ring*ring = (struct data_ring*)data;
No need for casting.
@@ -835,8 +834,8 @@ static void
rt2400pci_txdone(void *data)
{
struct data_ring*ring = (struct data_ring*)data;
No need for casting.
diff -uprN
wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-27 21:48:21.0 +0200
+++
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-27 21:49:08.0 +0200
@@ -834,10 +834,8 @@ rt2500pci_write_tx_desc(
static void
rt2500pci_beacondone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
- struct rt2x00_pci *rt2x00pci = (struct rt2x00_pci*)ring-dev;
- struct net_device *net_dev = pci_get_drvdata(rt2x00pci-pci_dev);
- struct sk_buff *skb;
+ struct data_ring*ring = (struct data_ring*)data;
No need for casting.
Many more of them.
I guess you could just do a fgrep for *ring = (struct data_ring*)data;
Thanks,
Not only the data_ring has unneeded casts, but they are also found on some
other locations.
I'll create a patch that removes them all.
pgphbHi3TZhzS.pgp
Description: PGP signature
Re: [PATCH 29/32] rt2x00: dscape compatibilitiy
On Friday 28 April 2006 13:12, Jiri Benc wrote: On Fri, 28 Apr 2006 00:03:19 +0200, Ivo van Doorn wrote: Latest dscape patches have broken rt2x00, fix compile issues, and support the new features. @@ -2466,6 +2568,7 @@ rt2500pci_init_hw(struct rt2x00_pci *rt2 hw-no_tkip_wmm_hwaccel = 1; hw-extra_hdr_room = 0; hw-device_strips_mic = 0; + hw-monitor_during_oper = 1; You should not set this to 1 if you support only one interface at a time. Please add support for concurrent running of one regular (i.e. STA, IBSS, AP, WDS) interface plus arbitrary number of monitor interfaces or set monitor_during_oper to 0. (Yes, I know, I definitely must reserve some time to write a documentation about monitor mode support.) My fault, this was a leftover from my initial patch for the dscape update. I actually had written some code to indeed allow multiple monitor mode interfaces. But I spotted some problems with it, and removed the code and planned to rewrite it later after I had send this code series. I'll create a quick patch to correctly set the monitor_during_oper variable, because the patch for correct monitor mode behaviour might take some time. pgpFP3MNcAX5B.pgp Description: PGP signature
Re: [PATCH 20/32] rt2x00: byte ordering correctness
On Friday 28 April 2006 15:42, Michael Buesch wrote: On Friday 28 April 2006 15:31, you wrote: On Friday 28 April 2006 15:14, Christoph Hellwig wrote: On Fri, Apr 28, 2006 at 02:59:23PM +0200, Ivo van Doorn wrote: I am not sure if that would be a wise idea, there is no byte ordering done in rt2500usb except for the EEPROM contents which is little endian. So when the module is used on a normal x86 platform, there won't be any big endian structures or fields. Well, then you'll need __le* annotation and the le*_to_cpu/cpu_to_le* instead. Any new driver should be endian clean. Not exactly true for rt2570, to correctly operate with the device, no endian conversions should be made at all. Not to big endian and not to little endian. The register should be send as a regular value with the byteordering equal to the byteordering of the currently used CPU. It has been tested to send only little endian or big endian values to the device on all CPU's, and in all cases it meant that the device would not function on CPU's with the other byte ordering. I guess you are confusing something here: MMIO access versus values in structs (for example) that are accessed through DMA (for example). Ah ok. I was indeed missing that point. In that case you are right, there could be some places where the __le* annotation could be used. I'll create a quick patch to do that. pgp9JGRYGK4GM.pgp Description: PGP signature
Re: [PATCH 20/32] rt2x00: byte ordering correctness
On Fri, Apr 28, 2006 at 03:42:29PM +0200, Michael Buesch wrote:
I guess you are confusing something here:
MMIO access versus values in structs (for example) that
are accessed through DMA (for example).
so there's two general problems:
mmio/pio - linux expects the device to be le there by defalt and
{read,write}{b,s,l} do the switch automatically
dmaed data - you always need to switch data yourself, data is commonly
either be or le
now there's devices that are always be for mmio or can be switched to it
during initialization. For Linux you'd traditionally have to switch before
calling {read,write}{b,s,l} or use the __raw_ version that have other issues.
The ioread*/iowrite* APIs now have a BE version, too.
I've not heard about devices having this switch for dma payload, and it
would be rather usual as large parts of it are determined by some on the
wire protocol anyway.
--
Greetings Michael.
---end quoted text---
-
To unsubscribe from this list: send 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 20/32] rt2x00: byte ordering correctness
On Friday 28 April 2006 15:46, you wrote:
On Fri, Apr 28, 2006 at 03:42:29PM +0200, Michael Buesch wrote:
I guess you are confusing something here:
MMIO access versus values in structs (for example) that
are accessed through DMA (for example).
so there's two general problems:
mmio/pio - linux expects the device to be le there by defalt and
{read,write}{b,s,l} do the switch automatically
dmaed data - you always need to switch data yourself, data is commonly
either be or le
now there's devices that are always be for mmio or can be switched to it
during initialization. For Linux you'd traditionally have to switch before
calling {read,write}{b,s,l} or use the __raw_ version that have other issues.
The ioread*/iowrite* APIs now have a BE version, too.
I've not heard about devices having this switch for dma payload, and it
would be rather usual as large parts of it are determined by some on the
wire protocol anyway.
bcm43xx has a switch for this in PIO mode.
But we are currently not using it, because it is a little
bit tricky to get right and I did not want to do such experiments
before 2.6.17.
--
Greetings Michael.
pgp7PCZfka0qS.pgp
Description: PGP signature
Re: [PATCH 22/32] rt2x00: Allocate ring structures in single array
On Friday 28 April 2006 12:52, Jiri Benc wrote:
On Fri, 28 Apr 2006 00:03:13 +0200, Ivo van Doorn wrote:
Use seperate function to convert a dscape ring ID
to the address of the actual ring.
Just minor things:
[...]
@@ -1386,20 +1412,19 @@ rt2400pci_tx(struct net_device *net_dev,
rt2x00_register_read(rt2x00pci, TXCSR0, reg);
- if (control-queue == IEEE80211_TX_QUEUE_DATA0) {
- ring = rt2x00pci-prio;
- rt2x00_set_field32(reg, TXCSR0_KICK_PRIO, 1);
- } else if (control-queue == IEEE80211_TX_QUEUE_DATA1) {
- ring = rt2x00pci-tx;
- rt2x00_set_field32(reg, TXCSR0_KICK_TX, 1);
- } else if (control-queue == IEEE80211_TX_QUEUE_AFTER_BEACON) {
- ring = rt2x00pci-atim;
- rt2x00_set_field32(reg, TXCSR0_KICK_ATIM, 1);
- } else {
- ERROR(Frame received for invalid queue.);
+ /*
+* Determine which ring to put packet on.
+*/
+ ring = rt2x00pci_get_ring(rt2x00pci, control-queue);
+ if (unlikely(!ring)) {
Should not happen. Maybe some message that user should report a bug?
I am not really fan on such messages. But when the control-queue is indeed
invalid, it is a serious bug. Perhaps a BUG() should be used as well?
If so, I'll put it into a new patch along with the fixes below.
+ ERROR(Attempt to send packet over invalid queue %d.\n,
+ control-queue);
return NET_RX_DROP;
}
+ if (rt2x00_ring_full(ring))
+ return NET_RX_DROP;
NET_XMIT_DROP?
Absolutely true, I'll fix this as well.
+
entry = rt2x00_get_data_entry(ring);
txd = entry-desc_addr;
[...]
@@ -1780,14 +1813,17 @@ rt2400pci_conf_tx(struct net_device *net
int queue, const struct ieee80211_tx_queue_params *params)
{
struct rt2x00_pci *rt2x00pci = ieee80211_dev_hw_data(net_dev);
- struct data_ring*ring;
+ struct data_ring*ring = rt2x00pci-ring[RING_TX];
- if (queue == IEEE80211_TX_QUEUE_DATA0)
- ring = rt2x00pci-prio;
- else if (queue == IEEE80211_TX_QUEUE_DATA1)
- ring = rt2x00pci-tx;
- else
- return -EINVAL;
+ /*
+* We don't support variating cw_min and cw_max variables
+* per queue. So by default we only configure the TX queue,
+* and ignore all other configurations.
+*/
+ if (queue != IEEE80211_TX_QUEUE_DATA0) {
+ NOTICE(Ignoring configuration for queue %d.\n, queue);
+ return 0;
Is there a reason for not returning a proper error code?
Good question, in rt2400pci the behaviour is something that is not
somethign the dscape could expect. Since we don't allow the
configuration of all available tx queues.
I had made it return 0, since I wasn't sure how the stack would
appreciate this behaviour.
But I have checked this in the stack since then, and apparently,
tx_conf is called without any notice of available tx queues.
Only when WMM is available the return value is checked,
so it is safe to return a error value.
But this behaviour should never have appeared in rt2500pci and rt2500usb,
so I'll put this fix in the patch as well.
Thanks.
pgpX3vN5g2DzR.pgp
Description: PGP signature
Re: [PATCH 22/32] rt2x00: Allocate ring structures in single array
On Fri, 28 Apr 2006 16:25:09 +0200, Ivo van Doorn wrote: I am not really fan on such messages. But when the control-queue is indeed invalid, it is a serious bug. Perhaps a BUG() should be used as well? If so, I'll put it into a new patch along with the fixes below. BUG() is not a good idea, this is not critical enough to panic the kernel. -- 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 22/32] rt2x00: Allocate ring structures in single array
On Friday 28 April 2006 16:30, Jiri Benc wrote: On Fri, 28 Apr 2006 16:25:09 +0200, Ivo van Doorn wrote: I am not really fan on such messages. But when the control-queue is indeed invalid, it is a serious bug. Perhaps a BUG() should be used as well? If so, I'll put it into a new patch along with the fixes below. BUG() is not a good idea, this is not critical enough to panic the kernel. Ok, Ill just change the debug message then. :) Thanks. pgpHaIquBhJ92.pgp Description: PGP signature
[PATCH 4/6] rt2x00 update: Remove packed attributes for structures that don't need it
From: Ivo van Doorn [EMAIL PROTECTED]
Remove __attribute__ ((packed)) for structures that
are not being send to the device.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00.h
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00.h
2006-04-28 15:09:53.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00.h
2006-04-28 15:50:06.0 +0200
@@ -324,12 +324,12 @@ extern int error_bitrange_bad;
struct rt2x00_field16{
u16 bit_offset;
u16 bit_mask;
-} __attribute__ ((packed));
+};
struct rt2x00_field32{
u32 bit_offset;
u32 bit_mask;
-} __attribute__ ((packed));
+};
/*
* Before intitializing the rt2x00_field# structures,
@@ -430,7 +430,7 @@ rt2x00_get_field16_nb(const u16 reg, con
struct _rt2x00_chip{
u16 rt;
u16 rf;
-} __attribute__ ((packed));
+};
/*
* Set chipset data.
@@ -511,7 +511,7 @@ struct data_ring{
*/
u16 data_size;
u16 desc_size;
-} __attribute__ ((packed));
+};
/*
* Handlers to determine the address of the current device specific
@@ -612,7 +612,7 @@ struct scanning{
short status;
#define SCANNING_READY 0x0001
#define SCANNING_CANCELLED 0x0002
-} __attribute__ ((packed));
+};
/*
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
2006-04-28 15:09:45.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
2006-04-28 15:49:18.0 +0200
@@ -72,7 +72,7 @@ struct rt2x00_button{
short button_status:1;
short active_poll:1;
short __pad:14;
-} __attribute__ ((packed));
+};
#endif /* CONFIG_RT2X00_BUTTON */
/*
@@ -106,7 +106,7 @@ struct data_entry{
*/
void*data_addr;
dma_addr_t data_dma;
-} __attribute__ ((packed));
+};
/*
* Device specific structure.
@@ -231,7 +231,7 @@ struct rt2x00_pci{
* after that the beacon and RX ring follow.
*/
struct data_ring*ring;
-} __attribute__ ((packed));
+};
static inline struct data_ring*
rt2x00pci_get_ring(struct rt2x00_pci *rt2x00pci, const int ring)
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
2006-04-28 15:09:44.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
2006-04-28 15:49:31.0 +0200
@@ -85,7 +85,7 @@ struct data_entry{
*/
void*data_addr;
dma_addr_t data_dma;
-} __attribute__ ((packed));
+};
/*
* The location of the descriptor is variating and depends
@@ -215,7 +215,7 @@ struct rt2x00_usb{
* after that the beacon and RX ring follow.
*/
struct data_ring*ring;
-} __attribute__ ((packed));
+};
static inline struct data_ring*
rt2x00usb_get_ring(struct rt2x00_usb *rt2x00usb, const int ring)
pgpBsbi5kNCIA.pgp
Description: PGP signature
[PATCH 3/6] rt2x00 update: Use static const for the vals arrays
From: Ivo van Doorn [EMAIL PROTECTED]
Make the vals arrays static const.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 15:16:23.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 15:32:12.0 +0200
@@ -2229,7 +2229,7 @@ rt2400pci_init_hw_channels(struct rt2x00
{
int counter;
u16 eeprom;
- static u32 vals[] = {
+ static const u32 vals[] = {
0x000c1fda, 0x000c1fee, 0x000c2002, 0x000c2016,
0x000c202a, 0x000c203e, 0x000c2052, 0x000c2066,
0x000c207a, 0x000c208e, 0x000c20a2, 0x000c20b6,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 15:16:23.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 15:32:31.0 +0200
@@ -2347,7 +2347,7 @@ rt2500pci_init_hw_channels(struct rt2x00
int counter;
u32 rf2_base;
u16 eeprom;
- static struct {
+ static const struct {
unsigned int chip;
u32 val[3];
} rf[] = {
@@ -2404,7 +2404,7 @@ rt2500pci_init_hw_channels(struct rt2x00
rf2_base = 0x0008;
if (rt2x00_rf(rt2x00pci-chip, RF2522)) {
- static u32 vals[] = {
+ static const u32 vals[] = {
0x000c1fda, 0x000c1fee, 0x000c2002, 0x000c2016,
0x000c202a, 0x000c203e, 0x000c2052, 0x000c2066,
0x000c207a, 0x000c208e, 0x000c20a2, 0x000c20b6,
@@ -2416,7 +2416,7 @@ rt2500pci_init_hw_channels(struct rt2x00
} else if (rt2x00_rf(rt2x00pci-chip, RF2523)
|| rt2x00_rf(rt2x00pci-chip, RF2524)
|| rt2x00_rf(rt2x00pci-chip, RF2525)) {
- static u32 vals[] = {
+ static const u32 vals[] = {
0x0c9e, 0x0ca2, 0x0ca6, 0x0caa,
0x0cae, 0x0cb2, 0x0cb6, 0x0cba,
0x0cbe, 0x0d02, 0x0d06, 0x0d0a,
@@ -2428,7 +2428,7 @@ rt2500pci_init_hw_channels(struct rt2x00
cpu_to_le32(vals[counter] | rf2_base);
} else if (rt2x00_rf(rt2x00pci-chip, RF2525E)
|| rt2x00_rf(rt2x00pci-chip, RF5222)) {
- static u32 vals[] = {
+ static const u32 vals[] = {
0x1136, 0x113a, 0x113e, 0x1182,
0x1186, 0x118a, 0x118e, 0x1192,
0x1196, 0x119a, 0x119e, 0x11a2,
@@ -2440,7 +2440,7 @@ rt2500pci_init_hw_channels(struct rt2x00
cpu_to_le32(vals[counter] | rf2_base);
}
if (rt2x00_rf(rt2x00pci-chip, RF5222)) {
- static u32 vals[] = {
+ static const u32 vals[] = {
0x00018896, 0x0001889a, 0x0001889e, 0x000188a2,
0x000188a6, 0x000188aa, 0x000188ae, 0x000188b2,
0x8802, 0x8806, 0x880a, 0x880e,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-04-28 15:16:22.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-04-28 15:32:06.0 +0200
@@ -1968,7 +1968,7 @@ rt2500usb_init_hw_channels(struct rt2x00
int counter;
u32 rf2_base;
u16 eeprom;
- static struct {
+ static const struct {
unsigned int chip;
u32 val[3];
} rf[] = {
@@ -2024,7 +2024,7 @@ rt2500usb_init_hw_channels(struct rt2x00
rf2_base = 0x0008;
if (rt2x00_rf(rt2x00usb-chip, RF2522)) {
- static u32 vals[] = {
+ static const u32 vals[] = {
0x000c1fda, 0x000c1fee, 0x000c2002, 0x000c2016,
0x000c202a, 0x000c203e, 0x000c2052, 0x000c2066,
0x000c207a, 0x000c208e, 0x000c20a2, 0x000c20b6,
@@ -2036,7 +2036,7 @@ rt2500usb_init_hw_channels(struct rt2x00
} else if (rt2x00_rf(rt2x00usb-chip, RF2523)
|| rt2x00_rf(rt2x00usb-chip, RF2524)
||
[PATCH 6/6] rt2x00 update: Apply correct error handling to dscape stack
From: Ivo van Doorn [EMAIL PROTECTED]
Return correct error code at failure, and
request debug report when the function _tx()
has received an invalid queue.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 15:32:12.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 16:34:55.0 +0200
@@ -1538,20 +1538,21 @@ rt2400pci_tx(struct net_device *net_dev,
*/
ring = rt2x00pci_get_ring(rt2x00pci, control-queue);
if (unlikely(!ring)) {
- ERROR(Attempt to send packet over invalid queue %d.\n,
- control-queue);
- return NET_RX_DROP;
+ ERROR(Attempt to send packet over invalid queue %d.\n
+ Please file bug report to %s.\n,
+ control-queue, DRV_PROJECT);
+ return NET_XMIT_DROP;
}
if (rt2x00_ring_full(ring))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
entry = rt2x00_get_data_entry(ring);
txd = entry-desc_addr;
if (rt2x00_get_field32(txd-word0, TXD_W0_OWNER_NIC)
|| rt2x00_get_field32(txd-word0, TXD_W0_VALID))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
memcpy(entry-data_addr, skb-data, skb-len);
rt2400pci_write_tx_desc(rt2x00pci, txd, skb, control);
@@ -2032,7 +2033,7 @@ rt2400pci_conf_tx(struct net_device *net
*/
if (queue != IEEE80211_TX_QUEUE_DATA0) {
NOTICE(Ignoring configuration for queue %d.\n, queue);
- return 0;
+ return -EINVAL;
}
memcpy(ring-tx_params, params, sizeof(*params));
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 15:32:31.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 16:34:54.0 +0200
@@ -1661,20 +1661,21 @@ rt2500pci_tx(struct net_device *net_dev,
*/
ring = rt2x00pci_get_ring(rt2x00pci, control-queue);
if (unlikely(!ring)) {
- ERROR(Attempt to send packet over invalid queue %d.\n,
- control-queue);
- return NET_RX_DROP;
+ ERROR(Attempt to send packet over invalid queue %d.\n
+ Please file bug report to %s.\n,
+ control-queue, DRV_PROJECT);
+ return NET_XMIT_DROP;
}
if (rt2x00_ring_full(ring))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
entry = rt2x00_get_data_entry(ring);
txd = entry-desc_addr;
if (rt2x00_get_field32(txd-word0, TXD_W0_OWNER_NIC)
|| rt2x00_get_field32(txd-word0, TXD_W0_VALID))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
memcpy(entry-data_addr, skb-data, skb-len);
rt2500pci_write_tx_desc(rt2x00pci, txd, skb, control);
@@ -2147,7 +2148,7 @@ rt2500pci_conf_tx(struct net_device *net
ring = rt2x00pci_get_ring(rt2x00pci, queue);
if (unlikely(!ring)) {
NOTICE(Ignoring configuration for queue %d.\n, queue);
- return 0;
+ return -EINVAL;
}
memcpy(ring-tx_params, params, sizeof(*params));
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-04-28 15:32:06.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-04-28 16:34:56.0 +0200
@@ -1373,13 +1373,14 @@ rt2500usb_tx(struct net_device *net_dev,
*/
ring = rt2x00usb_get_ring(rt2x00usb, control-queue);
if (unlikely(!ring)) {
- ERROR(Attempt to send packet over invalid queue %d.\n,
- control-queue);
- return NET_RX_DROP;
+ ERROR(Attempt to send packet over invalid queue %d.\n
+ Please file bug report to %s.\n,
+ control-queue, DRV_PROJECT);
+ return NET_XMIT_DROP;
}
if (rt2x00_ring_full(ring))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
entry = rt2x00_get_data_entry(ring);
txd = rt2x00usb_txdesc_addr(entry);
@@ -1797,7 +1798,7 @@ rt2500usb_conf_tx(struct net_device *net
ring = rt2x00usb_get_ring(rt2x00usb, queue);
if (unlikely(!ring)) {
[PATCH 5/6] rt2x00 update: Apply correct endian annotation for structures that are DMA'ed to device.
From: Ivo van Doorn [EMAIL PROTECTED]
Use __le32 annotations for all fields in the descriptor,
since these should always be treated as little endian.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
2006-04-28 15:09:48.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
2006-04-28 15:59:24.0 +0200
@@ -739,7 +739,7 @@
* TX descriptor format for TX, PRIO, ATIM and Beacon Ring.
*/
struct txd{
- u32 word0;
+ __le32 word0;
#define TXD_W0_OWNER_NIC FIELD32(0x0001)
#define TXD_W0_VALID FIELD32(0x0002)
#define TXD_W0_RESULT FIELD32(0x001c)
@@ -753,32 +753,32 @@ struct txd{
#define TXD_W0_AGC FIELD32(0x00ff)
#define TXD_W0_R2 FIELD32(0xff00)
- u32 word1;
+ __le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0x)
- u32 word2;
+ __le32 word2;
#define TXD_W2_BUFFER_LENGTH FIELD32(0x)
#define TXD_W2_DATABYTE_COUNT FIELD32(0x)
- u32 word3;
+ __le32 word3;
#define TXD_W3_PLCP_SIGNAL FIELD32(0x)
#define TXD_W3_PLCP_SERVICEFIELD32(0x)
- u32 word4;
+ __le32 word4;
#define TXD_W4_PLCP_LENGTH_LOW FIELD32(0x)
#define TXD_W4_PLCP_LENGTH_HIGHFIELD32(0x)
- u32 word5;
+ __le32 word5;
#define TXD_W5_BBCR4 FIELD32(0x)
#define TXD_W5_AGC_REG FIELD32(0x007f)
#define TXD_W5_AGC_REG_VALID FIELD32(0x0080)
#define TXD_W5_XXX_REG FIELD32(0x7f00)
#define TXD_W5_XXX_REG_VALID FIELD32(0x8000)
- u32 word6;
+ __le32 word6;
#define TXD_W6_SK_BUFF FIELD32(0x)
- u32 word7;
+ __le32 word7;
#define TXD_W7_RESERVEDFIELD32(0x)
} __attribute__ ((packed));
@@ -786,7 +786,7 @@ struct txd{
* RX descriptor format for RX Ring.
*/
struct rxd{
- u32 word0;
+ __le32 word0;
#define RXD_W0_OWNER_NIC FIELD32(0x0001)
#define RXD_W0_UNICAST_TO_ME FIELD32(0x0002)
#define RXD_W0_MULTICAST FIELD32(0x0004)
@@ -796,30 +796,30 @@ struct rxd{
#define RXD_W0_PHYSICAL_ERROR FIELD32(0x0080)
#define RXD_W0_DATABYTE_COUNT FIELD32(0x)
- u32 word1;
+ __le32 word1;
#define RXD_W1_BUFFER_ADDRESS FIELD32(0x)
- u32 word2;
+ __le32 word2;
#define RXD_W2_BUFFER_LENGTH FIELD32(0x)
#define RXD_W2_BBR0FIELD32(0x00ff)
#define RXD_W2_RSSIFIELD32(0xff00)
- u32 word3;
+ __le32 word3;
#define RXD_W3_BBR2FIELD32(0x00ff)
#define RXD_W3_BBR3FIELD32(0xff00)
#define RXD_W3_BBR4FIELD32(0x00ff)
#define RXD_W3_BBR5FIELD32(0xff00)
- u32 word4;
+ __le32 word4;
#define RXD_W4_RX_END_TIME FIELD32(0x)
- u32 word5;
+ __le32 word5;
#define RXD_W5_RESERVEDFIELD32(0x)
- u32 word6;
+ __le32 word6;
#define RXD_W6_RESERVEDFIELD32(0x)
- u32 word7;
+ __le32 word7;
#define RXD_W7_RESERVEDFIELD32(0x)
} __attribute__ ((packed));
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
2006-04-28 15:09:48.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
2006-04-28 15:58:29.0 +0200
@@ -987,7 +987,7 @@
* TX descriptor format for TX, PRIO, ATIM and Beacon Ring.
*/
struct txd{
- u32 word0;
+ __le32 word0;
#define TXD_W0_OWNER_NIC FIELD32(0x0001)
#define TXD_W0_VALID FIELD32(0x0002)
#define TXD_W0_RESULT FIELD32(0x001c)
@@ -1002,40 +1002,40 @@
[PATCH 2/6] rt2x00 update: Deactivate monitor_during_oper for now
From: Ivo van Doorn [EMAIL PROTECTED] Set monitor_during_oper to 0 for the time being, this feature will be supported in the future. Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c --- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 15:13:49.0 +0200 +++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 15:16:23.0 +0200 @@ -2362,7 +2362,7 @@ rt2400pci_init_hw(struct rt2x00_pci *rt2 hw-no_tkip_wmm_hwaccel = 1; hw-extra_hdr_room = 0; hw-device_strips_mic = 0; - hw-monitor_during_oper = 1; + hw-monitor_during_oper = 0; hw-fraglist = 0; /* diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c --- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 15:12:23.0 +0200 +++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 15:16:23.0 +0200 @@ -2619,7 +2619,7 @@ rt2500pci_init_hw(struct rt2x00_pci *rt2 hw-no_tkip_wmm_hwaccel = 1; hw-extra_hdr_room = 0; hw-device_strips_mic = 0; - hw-monitor_during_oper = 1; + hw-monitor_during_oper = 0; hw-fraglist = 0; hw-channel_change_time = 2000; diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c --- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 15:13:01.0 +0200 +++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 15:16:22.0 +0200 @@ -2233,7 +2233,7 @@ rt2500usb_init_hw(struct rt2x00_usb *rt2 hw-no_tkip_wmm_hwaccel = 1; hw-extra_hdr_room = 0; hw-device_strips_mic = 0; - hw-monitor_during_oper = 1; + hw-monitor_during_oper = 0; hw-fraglist = 0; hw-channel_change_time = 50; pgpYSg0t7YSay.pgp Description: PGP signature
[PATCH 1/6] rt2x00 update: Remove casts from void* pointers
From: Ivo van Doorn [EMAIL PROTECTED]
Remove unneeded casts when working with a void* pointer.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 15:09:53.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 15:13:49.0 +0200
@@ -917,7 +917,7 @@ rt2400pci_write_tx_desc(
static void
rt2400pci_beacondone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
+ struct data_ring*ring = data;
struct rt2x00_pci *rt2x00pci =
ieee80211_dev_hw_data(ring-net_dev);
struct sk_buff *skb;
@@ -938,7 +938,7 @@ rt2400pci_beacondone(void *data)
static void
rt2400pci_rxdone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
+ struct data_ring*ring = data;
struct rt2x00_pci *rt2x00pci =
ieee80211_dev_hw_data(ring-net_dev);
struct data_entry *entry;
@@ -995,7 +995,7 @@ rt2400pci_rxdone(void *data)
static void
rt2400pci_txdone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
+ struct data_ring*ring = data;
struct rt2x00_pci *rt2x00pci =
ieee80211_dev_hw_data(ring-net_dev);
struct data_entry *entry;
@@ -1067,7 +1067,7 @@ rt2400pci_txdone(void *data)
static irqreturn_t
rt2400pci_interrupt(int irq, void *dev_instance, struct pt_regs *regs)
{
- struct rt2x00_pci *rt2x00pci = (struct rt2x00_pci*)dev_instance;
+ struct rt2x00_pci *rt2x00pci = dev_instance;
u32 reg;
/*
@@ -1187,7 +1187,7 @@ rt2400pci_alloc_ring(
* Initialize all ring entries to contain valid
* addresses.
*/
- entry = (struct data_entry*)ring-entry;
+ entry = ring-entry;
for (counter = 0; counter ring-stats.limit; counter++) {
entry[counter].skb = NULL;
entry[counter].desc_addr = ring-data_addr
@@ -1275,7 +1275,7 @@ rt2400pci_init_rxdesc(struct rt2x00_pci
memset(ring-data_addr, 0x00, rt2x00_get_ring_size(ring));
- entry = (struct data_entry*)ring-entry;
+ entry = ring-entry;
for (counter = 0; counter ring-stats.limit; counter++) {
rxd = entry[counter].desc_addr;
@@ -1298,7 +1298,7 @@ rt2400pci_init_txdesc(struct rt2x00_pci
memset(ring-data_addr, 0x00, rt2x00_get_ring_size(ring));
- entry = (struct data_entry*)ring-entry;
+ entry = ring-entry;
for (counter = 0; counter ring-stats.limit; counter++) {
txd = entry[counter].desc_addr;
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 15:09:53.0 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 15:12:23.0 +0200
@@ -994,7 +994,7 @@ rt2500pci_write_tx_desc(
static void
rt2500pci_beacondone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
+ struct data_ring*ring = data;
struct rt2x00_pci *rt2x00pci =
ieee80211_dev_hw_data(ring-net_dev);
struct sk_buff *skb;
@@ -1015,7 +1015,7 @@ rt2500pci_beacondone(void *data)
static void
rt2500pci_rxdone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
+ struct data_ring*ring = data;
struct rt2x00_pci *rt2x00pci =
ieee80211_dev_hw_data(ring-net_dev);
struct data_entry *entry;
@@ -1083,7 +1083,7 @@ rt2500pci_rxdone(void *data)
static void
rt2500pci_txdone(void *data)
{
- struct data_ring*ring = (struct data_ring*)data;
+ struct data_ring*ring = data;
struct rt2x00_pci *rt2x00pci =
ieee80211_dev_hw_data(ring-net_dev);
struct data_entry *entry;
@@ -1155,7 +1155,7 @@ rt2500pci_txdone(void *data)
static irqreturn_t
rt2500pci_interrupt(int irq, void *dev_instance, struct pt_regs *regs)
{
- struct rt2x00_pci *rt2x00pci = (struct rt2x00_pci*)dev_instance;
+ struct rt2x00_pci *rt2x00pci = dev_instance;
u32 reg;
/*
@@ -1276,7 +1276,7 @@ rt2500pci_alloc_ring(
* Initialize all ring entries to contain valid
* addresses.
*/
- entry = (struct data_entry*)ring-entry;
+ entry = ring-entry;
for (counter = 0; counter ring-stats.limit; counter++) {
entry[counter].skb = NULL;
[PATCH 0/6] rt2x00 update
Hi, Here is a small update for the rt2x00 drivers in the wireless-dev tree. They all contain fixes and requests from the feedback from the last series. And they should be applied after the last series. A short summary of all patches the are following: [PATCH 1/6] rt2x00 update: Remove casts from void* pointers [PATCH 2/6] rt2x00 update: Deactivate monitor_during_oper for now [PATCH 3/6] rt2x00 update: Use static const for the vals arrays [PATCH 4/6] rt2x00 update: Remove packed attributes for structures that don't need it [PATCH 5/6] rt2x00 update: Apply correct endian annotation for structures that are DMA'ed to device. [PATCH 6/6] rt2x00 update: Apply correct error handling to dscape stack Altough all patches are small and are inlined, I have added them to the same location of the previous patch series. http://mendiosus.nl/rt2x00/rt2x00-33-void-casts.diff http://mendiosus.nl/rt2x00/rt2x00-34-monitor-operation.diff http://mendiosus.nl/rt2x00/rt2x00-35-static-const.diff http://mendiosus.nl/rt2x00/rt2x00-36-packed.diff http://mendiosus.nl/rt2x00/rt2x00-37-endian-annotation.diff http://mendiosus.nl/rt2x00/rt2x00-38-error-handling.diff IvD pgphGF4OR0OKt.pgp Description: PGP signature
Re: [PATCH 20/32] rt2x00: byte ordering correctness
On Friday 28 April 2006 15:46, Christoph Hellwig wrote:
On Fri, Apr 28, 2006 at 03:42:29PM +0200, Michael Buesch wrote:
I guess you are confusing something here:
MMIO access versus values in structs (for example) that
are accessed through DMA (for example).
so there's two general problems:
mmio/pio - linux expects the device to be le there by defalt and
{read,write}{b,s,l} do the switch automatically
dmaed data - you always need to switch data yourself, data is commonly
either be or le
now there's devices that are always be for mmio or can be switched to it
during initialization. For Linux you'd traditionally have to switch before
calling {read,write}{b,s,l} or use the __raw_ version that have other issues.
The ioread*/iowrite* APIs now have a BE version, too.
Unless I am mistaken, or the ralink design sheets are outdated on that issue,
I do recall that there was a big endian switch in one of the registers.
I think I need to definately investigate that to see if it would be usefull. :)
Thanks,
Ivo
pgp3MJ8cktcnr.pgp
Description: PGP signature
[PATCH] bcm43xx_d80211: fix bug in open
On Wed, 26 Apr 2006 15:39:12 -0400, John W. Linville wrote: Hacky or not, I'm applying this patch to keep the bcm43xx driver from breaking. I don't suppose you have a patch for the rt2x00 driver? The patch for bcm43xx was really just quick fix, only partially tested... Signed-off-by: Jiri Benc [EMAIL PROTECTED] --- drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) --- dscape.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c +++ dscape/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c @@ -4172,7 +4172,7 @@ static int bcm43xx_net_open(struct net_d int res; res = bcm43xx_init_board(bcm); - if (!res) + if (res) return res; bcm43xx_set_iwmode(bcm, bcm-iw_mode); return 0; -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
Evgeniy Polyakov wrote: On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: So the real issue is when there is an intelligent device that uses hardware packet classification to place the packet in the correct ring. We don't want to bypass packet filtering, but it would be terribly wasteful to reclassify the packet. Intelligent NICs will have packet classification capabilities to support RDMA and iSCSI. Those capabilities should be available to benefit SOCK_STREAM and SOCK_DGRAM users as well without it being a choice of either turning all stack control over to the NIC or ignorign all NIC capabilities beyound pretending to be a dumb Ethernet NIC. Btw, how is it supposed to work without header split capabale hardware? Hardware that can classify packets is obviously capable of doing header data separation, but that does not mean that it has to do so. If the host wants header data separation it's real value is that when packets arrive in order that fewer distinct copies are required to move the data to the user buffer (because separated data can be placed back-to-back in a data-only ring). But that's an optimization, it's not needed to make the idea worth doing, or even necessarily in the first implementation. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: Btw, how is it supposed to work without header split capabale hardware? Hardware that can classify packets is obviously capable of doing header data separation, but that does not mean that it has to do so. If the host wants header data separation it's real value is that when packets arrive in order that fewer distinct copies are required to move the data to the user buffer (because separated data can be placed back-to-back in a data-only ring). But that's an optimization, it's not needed to make the idea worth doing, or even necessarily in the first implementation. If there is dataflow, not flow of packets or flow of data with holes, it could be possible to modify recv() to just return the right pointer, so in theory userspace modifications would be minimal. With copy in place it completely does not differ from current design with copy_to_user() being used since memcpy() is just slightly faster than copy*user(). -- Evgeniy Polyakov - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
Evgeniy Polyakov wrote: On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: Btw, how is it supposed to work without header split capabale hardware? Hardware that can classify packets is obviously capable of doing header data separation, but that does not mean that it has to do so. If the host wants header data separation it's real value is that when packets arrive in order that fewer distinct copies are required to move the data to the user buffer (because separated data can be placed back-to-back in a data-only ring). But that's an optimization, it's not needed to make the idea worth doing, or even necessarily in the first implementation. If there is dataflow, not flow of packets or flow of data with holes, it could be possible to modify recv() to just return the right pointer, so in theory userspace modifications would be minimal. With copy in place it completely does not differ from current design with copy_to_user() being used since memcpy() is just slightly faster than copy*user(). If the app is really ready to use a modified interface we might as well just give them a QP/CQ interface. But I suppose receive by pointer interfaces don't really stretch the sockets interface all that badly. The key is that you have to decide how the buffer is released, is it the next call? Or a separate call? Does releasing buffer N+2 release buffers N and N+1? What you want to avoid is having to keep a scoreboard of which buffers have been released. But in context, header/data separation would allow in order packets to have the data be placed back to back, which could allow a single recv to report the payload of multiple successive TCP segments. So the benefit of header/data separation remains the same, and I still say it's a optimization that should not be made a requirement. The benefits of vj_channels exist even without them. When the packet classifier runs on the host, header/data separation would not be free. I want to enable hardware offloads, not make the kernel bend over backwards to emulate how hardware would work. I'm just hoping that we can agree to let hardware do its work without being forced to work the same way the kernel does (i.e., running down a long list of arbitrary packet filter rules on a per packet basis). - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, 28 Apr 2006 10:02:10 -0700 Caitlin Bestler [EMAIL PROTECTED] wrote: Evgeniy Polyakov wrote: On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: Btw, how is it supposed to work without header split capabale hardware? Hardware that can classify packets is obviously capable of doing header data separation, but that does not mean that it has to do so. If the host wants header data separation it's real value is that when packets arrive in order that fewer distinct copies are required to move the data to the user buffer (because separated data can be placed back-to-back in a data-only ring). But that's an optimization, it's not needed to make the idea worth doing, or even necessarily in the first implementation. If there is dataflow, not flow of packets or flow of data with holes, it could be possible to modify recv() to just return the right pointer, so in theory userspace modifications would be minimal. With copy in place it completely does not differ from current design with copy_to_user() being used since memcpy() is just slightly faster than copy*user(). If the app is really ready to use a modified interface we might as well just give them a QP/CQ interface. But I suppose receive by pointer interfaces don't really stretch the sockets interface all that badly. The key is that you have to decide how the buffer is released, is it the next call? Or a separate call? Does releasing buffer N+2 release buffers N and N+1? What you want to avoid is having to keep a scoreboard of which buffers have been released. Please just use existing AIO interface. We don't need another interface. The number of interfaces increases the exposed bug surface geometrically. Which means for each new interface, it means testing and fixing bugs in every possible usage. But in context, header/data separation would allow in order packets to have the data be placed back to back, which could allow a single recv to report the payload of multiple successive TCP segments. So the benefit of header/data separation remains the same, and I still say it's a optimization that should not be made a requirement. The benefits of vj_channels exist even without them. When the packet classifier runs on the host, header/data separation would not be free. I want to enable hardware offloads, not make the kernel bend over backwards to emulate how hardware would work. I'm just hoping that we can agree to let hardware do its work without being forced to work the same way the kernel does (i.e., running down a long list of arbitrary packet filter rules on a per packet basis). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] netem: fix loss
The following one line fix is needed to make loss function of
netem work right when doing loss on the local host.
Otherwise, higher layers just recover.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- linux-2.6.orig/net/sched/sch_netem.c
+++ linux-2.6/net/sched/sch_netem.c
@@ -167,7 +167,7 @@ static int netem_enqueue(struct sk_buff
if (count == 0) {
sch-qstats.drops++;
kfree_skb(skb);
- return NET_XMIT_DROP;
+ return NET_XMIT_BYPASS;
}
/*
-
To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, Apr 28, 2006 at 10:02:10AM -0700, Caitlin Bestler ([EMAIL PROTECTED]) wrote: If the app is really ready to use a modified interface we might as well just give them a QP/CQ interface. But I suppose receive by pointer interfaces don't really stretch the sockets interface all that badly. The key is that you have to decide how the buffer is released, is it the next call? Or a separate call? Does releasing buffer N+2 release buffers N and N+1? What you want to avoid is having to keep a scoreboard of which buffers have been released. But in context, header/data separation would allow in order packets to have the data be placed back to back, which could allow a single recv to report the payload of multiple successive TCP segments. So the benefit of header/data separation remains the same, and I still say it's a optimization that should not be made a requirement. The benefits of vj_channels exist even without them. When the packet classifier runs on the host, header/data separation would not be free. I want to enable hardware offloads, not make the kernel bend over backwards to emulate how hardware would work. I'm just hoping that we can agree to let hardware do its work without being forced to work the same way the kernel does (i.e., running down a long list of arbitrary packet filter rules on a per packet basis). I see your point, and respectfully disagree. The more complex userspace interface we create the less users it will have. It is completely unconvenient to read 100 bytes and receive only 80, since 20 were eaten by header. And what if we need only 20, but packet contains 100, introduce per packet head pointer? For purpose of benchmarking it works perfectly - read the whole packet, one can event touch that data to emulate real work, but for the real world it becomes practically unusabl. But what we are talking about right now is a research project, not production system, so we can create any interface we like since the main goal, IMHO, is searching for the bottlenecks in the current stack and ways of it's removal even by introducing new complex interface. I would definitely like to see how your approach works for some kind of real workloads and does it allow to create faster and generally better systems. -- Evgeniy Polyakov - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Please just use existing AIO interface. We don't need another interface. The number of interfaces increases the exposed bug surface geometrically. Which means for each new interface, it means testing and fixing bugs in every possible usage. Networking AIO? Like [1] :) That would be really good. 1. http://tservice.net.ru/~s0mbre/old/?section=projectsitem=naio -- Evgeniy Polyakov - To unsubscribe from this list: send 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: [LARTC] how to change classful netem loss probability?
Loss was broken, patch sent. The following works now: # tc qdisc add dev eth1 root handle 1:0 netem loss 20% # tc qdisc add dev eth1 parent 1:1 handle 10: tbf \ rate 256kbit buffer 1600 limit 3000 # ping -f -c 1000 shell 1000 packets transmitted, 781 received, 21% packet loss, time 3214ms rtt min/avg/max/mdev = 0.187/0.398/3.763/0.730 ms, ipg/ewma 3.217/0.538 ms # tc qdisc chang dev eth1 handle 1: netem loss 1% # ping -f -c 1000 shell 1000 packets transmitted, 990 received, 1% packet loss, time 2922ms rtt min/avg/max/mdev = 0.187/2.739/3.298/0.789 ms, ipg/ewma 2.924/2.084 ms - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, 28 Apr 2006 21:29:32 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Please just use existing AIO interface. We don't need another interface. The number of interfaces increases the exposed bug surface geometrically. Which means for each new interface, it means testing and fixing bugs in every possible usage. Networking AIO? Like [1] :) That would be really good. 1. http://tservice.net.ru/~s0mbre/old/?section=projectsitem=naio The existing infrastructure is there in the syscall layer, it just isn't really AIO for sockets. That naio project has two problems, first they require driver changes, and he is doing it on the stupidest of hardware, optimizing a 8139too is foolish. Second, introducing kevents, seems unnecessary and hasn't been accepted in the mainline. The existing linux AIO model seems sufficient: http://lse.sourceforge.net/io/aio.html There is work to put true Posix AIO on top of this. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: On Fri, 28 Apr 2006 21:29:32 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Please just use existing AIO interface. We don't need another interface. The number of interfaces increases the exposed bug surface geometrically. Which means for each new interface, it means testing and fixing bugs in every possible usage. Networking AIO? Like [1] :) That would be really good. 1. http://tservice.net.ru/~s0mbre/old/?section=projectsitem=naio The existing infrastructure is there in the syscall layer, it just isn't really AIO for sockets. That naio project has two problems, first they require driver changes, and he is doing it on the stupidest of hardware, optimizing a 8139too is foolish. No, it does not. You confuse it with receiving zero-copy support which allows to DMA data directly into VFS cache [1]. NAIO works for any kind of hardware and was tested with e1000 and showed noticeble win in both CPU usage and network performance. Second, introducing kevents, seems unnecessary and hasn't been accepted in the mainline. kevent was never sent to lkml@ although it showed over 40% win over epoll for test web server. Sending it to lkml@ is just jumping into ... not into technical world, so I posted it first here, but without much attention though. The existing linux AIO model seems sufficient: http://lse.sourceforge.net/io/aio.html There is work to put true Posix AIO on top of this. There are a lot of discussions about combining AIO with epoll and combine them into something similar to kevent which allows to monitor level and edge triggered events, to create proper state machine for AIO compeltions. kevent [2] does exactly that. AIO works not as state machine, but it's repeated-check design is more like postponing work from one context to special thread. 1. receiving zero-copy support http://tservice.net.ru/~s0mbre/old/?section=projectsitem=recv_zero_copy 2. kevent system http://tservice.net.ru/~s0mbre/old/?section=projectsitem=kevent -- Evgeniy Polyakov - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
Evgeniy Polyakov wrote: I see your point, and respectfully disagree. The more complex userspace interface we create the less users it will have. It is completely unconvenient to read 100 bytes and receive only 80, since 20 were eaten by header. And what if we need only 20, but packet contains 100, introduce per packet head pointer? For purpose of benchmarking it works perfectly - read the whole packet, one can event touch that data to emulate real work, but for the real world it becomes practically unusabl. In a straight-forward user-mode library using existing interfaces the message would be interleaved with the headers in the inbound ring. While the inbound ring is part of user memory, it is not what the user would process from, that would be the buffer they supplied in a call to read() or recvmsg(), that buffer would have to make no allowances for interleaved headers. Enabling zero-copy when a buffer is pre-posted is possible, but modestly complex. Research on MPI and SDP have generally shown that the unless the pinning overhead is eliminated somehow that the buffers have to be quite large before zero-copy reception becomes a benefit. vj_netchannels represent a strategy of minimizing registration/pinning costs even if it means paying for an extra copy. Because the extra copy is closely tied to the activation of the data sink consumer the cost of that extra copy is greatly reduced because it places the data in the cache immediately before the application will in fact use the received data. Also keep in mind that once the issues are resolved to allow the netchannel rings to be directly visible to a user-mode client that enhanced/specialized interfaces can easily be added in user-mode libraries. So focusing on supporting existing conventional interfaces is probably the best approach for the initial efforts. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 11:32:16 +0400 Definitely, userspace application must be very smart to deal with ip/tcp/option headers... That is why we will put an offset+len in the ring so they need not parse the packet headers. - To unsubscribe from this list: send 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] rt2x00: Compile fix and kernel version cleanup
From: Ivo van Doorn [EMAIL PROTECTED]
During CVS merge I noticed several compilation errors have sneaked
into the git version of rt2x00.
- PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
- poll_delay module argument is of the type short
- Remove LINUX_VERSION_CODE checks.
- Fix missing byteordering type
- Fix typo in usb_device
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 20:49:32.0 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-04-28 20:50:40.0 +0200
@@ -1239,7 +1239,7 @@ rt2400pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, rt2x00pci-ring[RING_PRIO], rt2400pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, rt2x00pci-ring[RING_BEACON], rt2400pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -2729,14 +2729,12 @@ MODULE_PARM_DESC(debug, Set this parame
#endif /* CONFIG_RT2400PCI_DEBUG */
#ifdef CONFIG_RT2400PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, Delay between WiFi button pollings (in 100ms).);
#endif /* CONFIG_RT2400PCI_BUTTON */
static struct pci_driver rt2400pci_driver = {
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 14)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2400pci_device_table,
.probe = rt2400pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 20:49:45.0 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-04-28 20:50:39.0 +0200
@@ -1328,7 +1328,7 @@ rt2500pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, rt2x00pci-ring[RING_PRIO], rt2500pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, rt2x00pci-ring[RING_BEACON], rt2500pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -3032,14 +3032,12 @@ MODULE_PARM_DESC(debug, Set this parame
#endif /* CONFIG_RT2500PCI_DEBUG */
#ifdef CONFIG_RT2500PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, Delay between WiFi button pollings (in 100ms).);
#endif /* CONFIG_RT2500PCI_BUTTON */
static struct pci_driver rt2500pci_driver = {
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 14)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2500pci_device_table,
.probe = rt2500pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
2006-04-28 15:58:29.0 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
2006-04-28 20:28:58.0 +0200
@@ -1005,7 +1005,7 @@ struct txd{
__le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0x)
- u32 word2;
+ __le32 word2;
#define TXD_W2_IV_OFFSET FIELD32(0x003f)
#define TXD_W2_AIFSFIELD32(0x00c0)
#define TXD_W2_CWMIN FIELD32(0x0f00)
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-04-28 20:49:59.0 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-04-28 20:50:39.0 +0200
@@ -1362,7 +1362,7 @@ rt2500usb_tx(struct net_device *net_dev,
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb
Re: [PATCH 1/1]x25: fix for spinlock recurse and spinlock lockup with timer handler in x25
From: Shaun Pereira [EMAIL PROTECTED] Date: Thu, 20 Apr 2006 15:03:23 +1000 From: [EMAIL PROTECTED] When the sk_timer function x25_heartbeat_expiry() is called by the kernel in a running/terminating process, spinlock-recursion and spinlock-lockup locks up the kernel. This has happened with testing on some distro's and the patch below fixed it. Signed-off-by:Shaun Pereira [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 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 20:12:21 +0400 If there is dataflow, not flow of packets or flow of data with holes, it could be possible to modify recv() to just return the right pointer, so in theory userspace modifications would be minimal. With copy in place it completely does not differ from current design with copy_to_user() being used since memcpy() is just slightly faster than copy*user(). I very much feel that avoiding userland API changes is a complete mistake. We need new interfaces to do this right. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 10:18:33 -0700 Please just use existing AIO interface. I totally disagree, the existing AIO interface is garbage. We need new APIs to do this right, to get the ring buffer and the zero-copy'ness correct. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netem: fix loss
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 10:22:40 -0700 The following one line fix is needed to make loss function of netem work right when doing loss on the local host. Otherwise, higher layers just recover. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Applied, 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
Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 21:25:36 +0400 The more complex userspace interface we create the less users it will have. It is completely unconvenient to read 100 bytes and receive only 80, since 20 were eaten by header. These bytes are charged to socket anyways, and allowing the headers to be there is the only clean way to finesse the whole zero-copy problem. User can manage his data any way he likes. He can decide to take advantage of the zero-copy layout we've provided, or he can copy to put things into a format he is more happy with at the cost of the copy. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 21:55:39 +0400 On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Second, introducing kevents, seems unnecessary and hasn't been accepted in the mainline. kevent was never sent to lkml@ although it showed over 40% win over epoll for test web server. Sending it to lkml@ is just jumping into ... not into technical world, so I posted it first here, but without much attention though. Frankly I found kevents to be a very strong 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 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 18:24:08 +1000 Note that the problem space AFAICT includes strange advanced routing setups, ingress qos and possibly others, not just netfilter. But perhaps the same solutions apply, so I'll concentrate on nf. Yes, this hasn't been mentioned explicitly yet. The big problem is that we don't want the classifier to become overly complex. One scheme I'm thinking about right now is an ordered lookup that looks like: 1) Check for established sockets, they trump everything else. 2) Check for classifier rules, ie. netfilter and packet scheduler stuff 3) Check for listening sockets 4) default channel #2 is still an unsolved problem, we don't want this big complex classifier to be required in the hardware implementations. However, using just IP addresses and ports does not map well to what netfilter and co. want. Ah, this is a different problem. Our idea was to have a syscall which would check sanitize the buffers for output. To do this, you need the ability to chain buffers (a simple next entry in the header, for us). Sanitization would copy the header into a global buffer (ie. not one reachable by userspace), check the flowid, and chain on the rest of the user buffer. After it had sanitized the buffers, it would activate the NIC, which would only send out buffers which started with a kernel buffer. Of course, the first step (CAP_NET_RAW-only) wouldn't need this. And, if the sanitize_and_send syscall were PF_VJCHAN's write(), then the contents of the write() could actually be the header: userspace would never deal with chained buffers. I am not sure any of this is anything more than overhead. If we just pop the buffers directly into the user mmap()'d ring buffer, headers and all, and give an offset+length pair so the user knows where the data starts and how much data is there, it should all just work out. Where to put the offset+length is just a detail. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, 28 Apr 2006 12:16:36 -0700 (PDT) David S. Miller [EMAIL PROTECTED] wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 21:55:39 +0400 On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Second, introducing kevents, seems unnecessary and hasn't been accepted in the mainline. kevent was never sent to lkml@ although it showed over 40% win over epoll for test web server. Sending it to lkml@ is just jumping into ... not into technical world, so I posted it first here, but without much attention though. Frankly I found kevents to be a very strong idea. But there is this huge semantic overload of kevent, poll, epoll, aio, regular sendmsg/recv, posix aio, etc. Perhaps a clean break with the socket interface is needed. Otherwise, there are nasty complications with applications that mix old socket calls and new interface on the same connection. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, Apr 28, 2006 at 12:16:36PM -0700, David S. Miller ([EMAIL PROTECTED]) wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 21:55:39 +0400 On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: Second, introducing kevents, seems unnecessary and hasn't been accepted in the mainline. kevent was never sent to lkml@ although it showed over 40% win over epoll for test web server. Sending it to lkml@ is just jumping into ... not into technical world, so I posted it first here, but without much attention though. Frankly I found kevents to be a very strong idea. Glad to hear this. I probably should resend patches netdev@ and (mar my karma) send it to [EMAIL PROTECTED] -- Evgeniy Polyakov - To unsubscribe from this list: send 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] powerpc: ibmveth: Harden driver initilisation for kexec
Michael Ellerman wrote:
Looks like this hit the floor. Any chance of getting it into to 2.6.17
Jeff? AFAICT it should still apply cleanly.
/me knocks politely
Actually, it doesn't apply cleanly anymore. Here's a patch that does.
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
From: Michael Ellerman [EMAIL PROTECTED]
After a kexec the ibmveth driver will fail when trying to register with the
Hypervisor because the previous kernel has not unregistered.
So if the registration fails, we unregister and then try again.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Anton Blanchard [EMAIL PROTECTED]
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
ibmveth.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
Index: kexec/drivers/net/ibmveth.c
===
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13:29:49.429736784 -0500
@@ -436,6 +436,31 @@ static void ibmveth_cleanup(struct ibmve
ibmveth_free_buffer_pool(adapter, adapter-rx_buff_pool[i]);
}
+static int ibmveth_register_logical_lan(struct ibmveth_adapter *adapter,
+union ibmveth_buf_desc rxq_desc, u64 mac_address)
+{
+ int rc, try_again = 1;
+
+ /* After a kexec the adapter will still be open, so our attempt to
+ * open it will fail. So if we get a failure we free the adapter and
+ * try again, but only once. */
+retry:
+ rc = h_register_logical_lan(adapter-vdev-unit_address,
+ adapter-buffer_list_dma, rxq_desc.desc,
+ adapter-filter_list_dma, mac_address);
+
+ if (rc != H_SUCCESS try_again) {
+ do {
+ rc = h_free_logical_lan(adapter-vdev-unit_address);
+ } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+
+ try_again = 0;
+ goto retry;
+ }
+
+ return rc;
+}
+
static int ibmveth_open(struct net_device *netdev)
{
struct ibmveth_adapter *adapter = netdev-priv;
@@ -505,11 +530,7 @@ static int ibmveth_open(struct net_devic
ibmveth_debug_printk(receive q @ 0x%p\n,
adapter-rx_queue.queue_addr);
- lpar_rc = h_register_logical_lan(adapter-vdev-unit_address,
-adapter-buffer_list_dma,
-rxq_desc.desc,
-adapter-filter_list_dma,
-mac_address);
+ lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc, mac_address);
if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk(h_register_logical_lan failed with
%ld\n, lpar_rc);
[patch] cleanup unused macro in net/netlink/af_netlink.c
1 line removal, of unused macro.
ran 'egrep -r' from linux-2.6.16/ for Nprintk and
didn't see it anywhere else but here, in #define...
signed off by: soyoung park[EMAIL PROTECTED]--- linux-2.6.16/net/netlink/af_netlink.c~ Sun Mar 19 21:53:29 2006
+++ linux-2.6.16/net/netlink/af_netlink.c Fri Apr 28 13:41:52 2006
@@ -61,7 +61,6 @@
#include net/scm.h
#include net/netlink.h
-#define Nprintk(a...)
#define NLGRPSZ(x) (ALIGN(x, sizeof(unsigned long) * 8) / 8)
struct netlink_sock {
Re: [PATCH] ibmveth change buffer pools dynamically
Santiago Leon wrote: This patch provides a sysfs interface to change some properties of the ibmveth buffer pools (size of the buffers, number of buffers per pool, and whether a pool is active). Ethernet drivers use ethtool to provide this type of functionality. However, the buffers in the ibmveth driver can have an arbitrary size (not only regular, mini, and jumbo which are the only sizes that ethtool can change), and also ibmveth can have an arbitrary number of buffer pools Under heavy load we have seen dropped packets which obviously kills TCP performance. We have created several fixes that mitigate this issue, but we definitely need a way of changing the number of buffers for an adapter dynamically. Also, changing the size of the buffers allows users to change the MTU to something big (bigger than a jumbo frame) greatly improving performance on partition to partition transfers. The patch creates directories pool1...pool4 in the device directory in sysfs, each with files: num, size, and active (which default to the values in the mainline version). Comments and suggestions are welcome... Jeff, if you don't have any problem with this patch, can you apply it? Thanks, -- Santiago A. Leon Power Linux Development IBM Linux Technology Center - To unsubscribe from this list: send 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] ibmveth support for netpoll
This patch adds NETPOLL support for the ibmveth driver. Please apply.
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
ibmveth.c | 11 +++
1 file changed, 11 insertions(+)
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13:17:59.971778584 -0500
@@ -918,6 +918,14 @@ static int ibmveth_change_mtu(struct net
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void ibmveth_poll_controller(struct net_device *dev)
+{
+ ibmveth_replenish_task(dev-priv);
+ ibmveth_interrupt(dev-irq, dev, NULL);
+}
+#endif
+
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct
vio_device_id *id)
{
int rc, i;
@@ -989,6 +997,9 @@ static int __devinit ibmveth_probe(struc
netdev-ethtool_ops = netdev_ethtool_ops;
netdev-change_mtu = ibmveth_change_mtu;
SET_NETDEV_DEV(netdev, dev-dev);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ netdev-poll_controller = ibmveth_poll_controller;
+#endif
netdev-features |= NETIF_F_LLTX;
spin_lock_init(adapter-stats_lock);
Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 23:59:30 +0400 kevent can be used as poll without any changes to the socket code. There are two types of network related kevents - socket events (recv/send/accept) and network aio, which can be turned completely off in config. There are following events which are supported by kevent: o usual poll/select notifications o inode notifications (create/remove) o timer notifications o socket notifications (send/recv/accept) o network aio system o fs aio (project closed, aio_sendfile() is being developed instead) Any of the above can be turned off by config option. Feel free to post the current version of your kevent patch here so we can discuss something concrete. Maybe you have even some toy example user applications that use kevent that people can look at too? That might help in understanding how it's supposed to be used. - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, 2006-04-28 at 12:21 -0700, David S. Miller wrote: From: Rusty Russell [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 18:24:08 +1000 Note that the problem space AFAICT includes strange advanced routing setups, ingress qos and possibly others, not just netfilter. But perhaps the same solutions apply, so I'll concentrate on nf. Yes, this hasn't been mentioned explicitly yet. The big problem is that we don't want the classifier to become overly complex. One scheme I'm thinking about right now is an ordered lookup that looks like: 1) Check for established sockets, they trump everything else. 2) Check for classifier rules, ie. netfilter and packet scheduler stuff 3) Check for listening sockets 4) default channel #2 is still an unsolved problem, we don't want this big complex classifier to be required in the hardware implementations. However, using just IP addresses and ports does not map well to what netfilter and co. want. You're still thinking you can bypass classifiers for established sockets, but I really don't think you can. I think the simplest solution is to effectively remove from (or flag) the established listening hashes anything which could be effected by classifiers, so those packets get send through the default channel. This can graduate from all or nothing to some more fine-grained scheme over time. I have some early thoughts on how we could really do this with filtering by connection tracking state; serious work, but feasible. Ah, this is a different problem. Our idea was to have a syscall which would check sanitize the buffers for output. To do this, you need the ability to chain buffers (a simple next entry in the header, for us). Sanitization would copy the header into a global buffer (ie. not one reachable by userspace), check the flowid, and chain on the rest of the user buffer. After it had sanitized the buffers, it would activate the NIC, which would only send out buffers which started with a kernel buffer. Of course, the first step (CAP_NET_RAW-only) wouldn't need this. And, if the sanitize_and_send syscall were PF_VJCHAN's write(), then the contents of the write() could actually be the header: userspace would never deal with chained buffers. I am not sure any of this is anything more than overhead. If we just pop the buffers directly into the user mmap()'d ring buffer, headers and all, and give an offset+length pair so the user knows where the data starts and how much data is there, it should all just work out. Where to put the offset+length is just a detail. Agreed, but I was talking about userspace *send*, in reply to Caitlin bringing it up. A little off-topic, but I mentioned our thoughts simply to show that it's possible to do unpriv'ed output... (Kelly is taking a couple of well-earned days off ATM). Cheers! Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol - To unsubscribe from this list: send 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: IP1000 gigabit nic driver
Hi Pekka,
On Apr 28 at 02:59:01, Pekka J Enberg wrote:
Here are some suggestions for coding style cleanups:
Couple of questions,
- Use dev_{dbg,err,info,warn} for logging
Cannot, i need a struct device and most of the
there's only access to a struct net_device. Am i
missing something?
- Use proper naming convention for things like Length and pPHYParam
What's the convention for these names?
Thanks,
--
David Gómez Jabber ID: [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: [IPSEC]: Fix IP ID selection
From: Herbert Xu [EMAIL PROTECTED] Date: Thu, 27 Apr 2006 21:56:45 +1000 I was looking through the xfrm input/output code in order to abstract out the address family specific encapsulation/decapsulation code. During that process I found this bug in the IP ID selection code in xfrm4_output.c. At that point dst is still the xfrm_dst for the current SA which represents an internal flow as far as the IPsec tunnel is concerned. Since the IP ID is going to sit on the outside of the encapsulated packet, we obviously want the external flow which is just dst-child. The fix is trivial. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Thanks for catching this, applied, thanks Herbert. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix unlikely usage in tcp_transmit_skb()
From: Hua Zhong [EMAIL PROTECTED] Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT) [I hope this time it's OK - I'm sending from pine/Linux] It adds an extra space in the diff lines which corrupts the patch. I've applied this by hand, but please try to get something which works before providing new patches. Just try to email yourself a patch, then try to apply it successfully yourself. 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 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 29 Apr 2006 08:04:04 +1000 You're still thinking you can bypass classifiers for established sockets, but I really don't think you can. I think the simplest solution is to effectively remove from (or flag) the established listening hashes anything which could be effected by classifiers, so those packets get send through the default channel. OK, when rules are installed, the socket channel mappings are flushed. This is your idea right? - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 29 Apr 2006 08:17:01 +1000 On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote: vj_netchannels represent a strategy of minimizing registration/pinning costs even if it means paying for an extra copy. Because the extra copy is closely tied to the activation of the data sink consumer the cost of that extra copy is greatly reduced because it places the data in the cache immediately before the application will in fact use the received data. Just to be clear here: I agree with Dave that without classifying hardware, there's no point (and much pain) in going all the way to userspace with the channel (ie. mmap). If you're going to copy anyway, might as well do it in the socket's read() call: then the user can then aim the copy exactly where they want, too. We'll need that TCP code in the kernel for the foreseeable future anyway 8) However, in future, if intelligent cards exist, having an API which lets them do zero-copy and not overly penalize less intelligent cards makes sense. I do not think intelligent cards imply protocol in user space. You can still get the zero copy, and moving the work to the remote cpu, without all the complexity assosciated with putting the protocol in userspace. It buys nothing but complexity. Side note: my Xen I/O patches allow the implementation of exactly this kind of virtual hardware (no coincidence 8), so intelligent cards might not be as far away as you think... Such hardware can be prototyped in QEMU 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: [RFC] Geographical/regulatory information for ieee80211
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote: I am leaning toward putting the geographical information into a userland daemon. I like that idea very much. This is all control metadate that doesn't really need to be in the kernel. That way we won't have to patch the kernel every time a country modifies its regulations. that's another advantage. In addition, the kernel will be smaller. The downside is that the daemon will have to be updated and supplied in some convenient form, perhaps as part of a wireless tools package. Ideally the daemon would get the table of country restrictions from a policy file (some human-readable ascii?). That file can then be downloaded by a cronjob to keep it updated, if desired. A bit like the PCI/USB device id databases... -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpYfGS2xTcML.pgp Description: PGP signature
Re: [RFC PATCH] [IPV6]: Fix race in route selection.
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Fri, 28 Apr 2006 02:04:56 +0900 (JST) We eliminated rt6_dflt_lock (to protect default router pointer) at 2.6.17-rc1, and introduced rt6_select() for general router selection. The function is called in the context of rt6_lock read-lock held, but this means, we have some race conditions when we do round-robin. Am I correct? If so, we should put some spin_lock for serialization. Comments? Signed-off-by; YOSHIFUJI Hideaki [EMAIL PROTECTED] Or, should we run whole part of rt6_select() under some lock? I think the local lock will work and it is fine for now. I will apply this as-is to fix the bug. But in the longer term this seems a little bit heavy operation. Perhaps there is some way to use xchg() here? It is just moving a pointer around for a round robin list, if it could be reduced to just a single pointer store, we could even do it without atomic operations. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
David S. Miller wrote: From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 29 Apr 2006 08:04:04 +1000 You're still thinking you can bypass classifiers for established sockets, but I really don't think you can. I think the simplest solution is to effectively remove from (or flag) the established listening hashes anything which could be effected by classifiers, so those packets get send through the default channel. OK, when rules are installed, the socket channel mappings are flushed. This is your idea right? You mean when new rules are installed that would conflict with an existing mapping, right? Bumping every connection out of vj-channel mode whenever any new rule was installed would be very counter-productive. Ultimately, you only want a direct-to-user vj-channel when all packets assigned to it would be passed by netchannels, and maybe increment a single packet counter. Checking a single QoS rate limiter may be possible too, but if there are more complex rules then the channel has to be kept in kernel because it wouldn't make sense to trust user-mode code to apply the netchannel rules reliably. - To unsubscribe from this list: send 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 unlikely usage in tcp_transmit_skb()
On Fri, 28 Apr 2006, David S. Miller wrote: From: Hua Zhong [EMAIL PROTECTED] Date: Wed, 26 Apr 2006 09:50:28 -0700 (PDT) [I hope this time it's OK - I'm sending from pine/Linux] It adds an extra space in the diff lines which corrupts the patch. You can work around this by enabling quell-flowed-text - then pine will never mangle patches. Currently (pine4.64), if you're disabling flowed text on a per-message basis with ^V before sending, patches containing trailing whitespace will get mangled. Pine labels the message as not flowed, but does the mangling anyway :-/ Tooting my own horn here, but I submitted a pine patch this week which fixes the issue. Hopefully, the next pine release will behave correctly. You'll still have to remember to hit ^V before sending mail containing patches, and you should always use ^R to include patch files, since newlines in the input are treated magically. Or, you can enable quell-flowed-text, and pretend the whole flowed text feature never happened. I'll shut up about pine now :-) Alexey - To unsubscribe from this list: send 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: Fw: Bug: PPP dropouts in =2.6.16
On Wed, 26 Apr 2006, Sven Schuster wrote: but don't hold your breath waiting for me, kernel compile takes more than two hours on my box :-) Ouch. Takes 5/7 minutes here on the AMD64 resp. P4. Computer museum? :P Anyhow, I tested PPP for 2.5 hours on the AMD64 the day before yesterday with a bidirectional transfer that maxed out the upstream. Last night, I additionally put some load on the CPU. Another 3 hours, no problems whatsoever. Looks like the bug does not manifest on that system. The next step will be to clone .config's settings as far as possible with the different hardware and try again. Regards, Nuri - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, 2006-04-28 at 15:38 -0700, David S. Miller wrote: From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 29 Apr 2006 08:04:04 +1000 You're still thinking you can bypass classifiers for established sockets, but I really don't think you can. I think the simplest solution is to effectively remove from (or flag) the established listening hashes anything which could be effected by classifiers, so those packets get send through the default channel. OK, when rules are installed, the socket channel mappings are flushed. This is your idea right? Yeah. First off, all flushed. Later on, we get selective. Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol - To unsubscribe from this list: send 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/3] Rough VJ Channel Implementation - vj_core.patch
On Fri, 2006-04-28 at 15:40 -0700, David S. Miller wrote: From: Rusty Russell [EMAIL PROTECTED] Date: Sat, 29 Apr 2006 08:17:01 +1000 However, in future, if intelligent cards exist, having an API which lets them do zero-copy and not overly penalize less intelligent cards makes sense. I do not think intelligent cards imply protocol in user space. You can still get the zero copy, and moving the work to the remote cpu, without all the complexity assosciated with putting the protocol in userspace. It buys nothing but complexity. You're thinking the card would place the packet in the mmap'ed buffer, but the protocol handling would still be done (on that user-accessible buffer) in kernelspace? I hadn't considered that. Are the userspace-kernel interactions here are a lesser problem than telling userspace you want direct access to the packets? Great, *you* handle the whole thing. I am thinking the big payoff for this would be MPI et al (RDMA), so we might be best leaving it alone. Side note: my Xen I/O patches allow the implementation of exactly this kind of virtual hardware (no coincidence 8), so intelligent cards might not be as far away as you think... Such hardware can be prototyped in QEMU as well. Absolutely (and writing QEMU devices is easier than writing a Linux device driver, which says something sad). But the Xen virtual intelligent NIC would be a real NIC, not (just) a prototype. Cheers! Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol - To unsubscribe from this list: send 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] Geographical/regulatory information for ieee80211
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote: I don't think it would make that much difference as the user could easily lie about their locality and get any set of parameters that they wanted. Well, not any set.. One of the configured countries, yes, but that is not same as setting arbitrary TX power limit and allowed channel sets.. Anyway, users should be allowed to move from one country to another and still being able to use their wlan card (within the limits of the current location). I am leaning toward putting the geographical information into a userland daemon. That way we won't have to patch the kernel every time a country modifies its regulations. In addition, the kernel will be smaller. The downside is that the daemon will have to be updated and supplied in some convenient form, perhaps as part of a wireless tools package. I'm strongly in favor of doing this in user space, too. In order to provide some control on what end users do with this, I would consider including a signature on a data file and have the user space tool verify that signature before accepting the data. This signature need not be anything extra secure, i.e., it could just be a keyed checksum of the file using a well-known key. The main point here is that it shows some attempt on limiting end users from setting random values to regulatory limits. Of course, if someone really wants to change these values, they could do so since the source code for the tool would be available and so would the key used for signing the file in the first place. I don't know how secure a system would be needed to pass requirements that FCC and similar organizations place on wireless devices. I would like to handle this with fully open source tools and having some kind of simple signature on the data file would be good starting point. It is up to vendors then to decide whether they are fine with such a mechanism or whether some additional tool (like the Intel plan on using a closed source user space tool) would be needed on top of this. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send 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/6] tg3: Call netif_carrier_off() during phy reset
Add netif_carrier_off() call during tg3_phy_reset(). This is needed
to properly track the netif_carrier state in cases where we do a
PHY reset with interrupts disabled. The SerDes code will not run
properly if the netif_carrier state is wrong.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 73e271e..a28accb 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -974,6 +974,8 @@ static int tg3_phy_reset_5703_4_5(struct
return err;
}
+static void tg3_link_report(struct tg3 *);
+
/* This will reset the tigon3 PHY if there is no valid
* link unless the FORCE argument is non-zero.
*/
@@ -987,6 +989,11 @@ static int tg3_phy_reset(struct tg3 *tp)
if (err != 0)
return -EBUSY;
+ if (netif_running(tp-dev) netif_carrier_ok(tp-dev)) {
+ netif_carrier_off(tp-dev);
+ tg3_link_report(tp);
+ }
+
if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5703 ||
GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5704 ||
GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5705) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] tg3: Add phy workaround
Add some PHY workaround code to reduce jitter on some PHYs.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a28accb..a307340 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1030,6 +1030,12 @@ out:
tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x14e2);
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400);
}
+ else if (tp-tg3_flags2 TG3_FLG2_PHY_JITTER_BUG) {
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0c00);
+ tg3_writephy(tp, MII_TG3_DSP_ADDRESS, 0x000a);
+ tg3_writephy(tp, MII_TG3_DSP_RW_PORT, 0x010b);
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x0400);
+ }
/* Set Extended packet length bit (bit 14) on all chips that */
/* support jumbo frames */
if ((tp-phy_id PHY_ID_MASK) == PHY_ID_BCM5401) {
@@ -10360,10 +10366,13 @@ static int __devinit tg3_get_invariants(
if (tp-pci_chip_rev_id == CHIPREV_ID_5704_A0)
tp-tg3_flags2 |= TG3_FLG2_PHY_5704_A0_BUG;
- if ((tp-tg3_flags2 TG3_FLG2_5705_PLUS)
- (GET_ASIC_REV(tp-pci_chip_rev_id) != ASIC_REV_5755)
- (GET_ASIC_REV(tp-pci_chip_rev_id) != ASIC_REV_5787))
- tp-tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
+ if (tp-tg3_flags2 TG3_FLG2_5705_PLUS) {
+ if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5755 ||
+ GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5787)
+ tp-tg3_flags2 |= TG3_FLG2_PHY_JITTER_BUG;
+ else
+ tp-tg3_flags2 |= TG3_FLG2_PHY_BER_BUG;
+ }
tp-coalesce_mode = 0;
if (GET_CHIP_REV(tp-pci_chip_rev_id) != CHIPREV_5700_AX
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 8c8b987..0e29b88 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2215,6 +2215,7 @@ struct tg3 {
#define TG3_FLG2_HW_TSO_2 0x0800
#define TG3_FLG2_HW_TSO(TG3_FLG2_HW_TSO_1 |
TG3_FLG2_HW_TSO_2)
#define TG3_FLG2_1SHOT_MSI 0x1000
+#define TG3_FLG2_PHY_JITTER_BUG0x2000
u32 split_mode_max_reqs;
#define SPLIT_MODE_5704_MAX_REQ3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] tg3: Reset chip when changing MAC address
Do the full chip reset when changing MAC address if ASF is enabled.
ASF sometimes uses a different MAC address than the driver. Without
the reset, the ASF MAC address may be overwritten when the driver's
MAC address is changed.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a307340..0ccfb63 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5732,9 +5732,23 @@ static int tg3_set_mac_addr(struct net_d
if (!netif_running(dev))
return 0;
- spin_lock_bh(tp-lock);
- __tg3_set_mac_addr(tp);
- spin_unlock_bh(tp-lock);
+ if (tp-tg3_flags TG3_FLAG_ENABLE_ASF) {
+ /* Reset chip so that ASF can re-init any MAC addresses it
+* needs.
+*/
+ tg3_netif_stop(tp);
+ tg3_full_lock(tp, 1);
+
+ tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
+ tg3_init_hw(tp);
+
+ tg3_netif_start(tp);
+ tg3_full_unlock(tp);
+ } else {
+ spin_lock_bh(tp-lock);
+ __tg3_set_mac_addr(tp);
+ spin_unlock_bh(tp-lock);
+ }
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
[PATCH 4/6] tg3: Add reset_phy parameter to chip reset functions
Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
the full chip reset during MAC address change, the automatic PHY reset
during chip reset will cause a link down and bonding will not work
properly as a result. With this reset_phy parameter, we can do a chip
reset without link down when changing MAC address or MTU.
Signed-off-by: Gary Zambrano [EMAIL PROTECTED]
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0ccfb63..97e27d8 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3544,7 +3544,7 @@ static irqreturn_t tg3_test_isr(int irq,
return IRQ_RETVAL(0);
}
-static int tg3_init_hw(struct tg3 *);
+static int tg3_init_hw(struct tg3 *, int);
static int tg3_halt(struct tg3 *, int, int);
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -3580,7 +3580,7 @@ static void tg3_reset_task(void *_data)
tp-tg3_flags2 = ~TG3_FLG2_RESTART_TIMER;
tg3_halt(tp, RESET_KIND_SHUTDOWN, 0);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
@@ -4055,7 +4055,7 @@ static int tg3_change_mtu(struct net_dev
tg3_set_mtu(dev, tp, new_mtu);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
@@ -5740,7 +5740,7 @@ static int tg3_set_mac_addr(struct net_d
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
tg3_full_unlock(tp);
@@ -5798,7 +5798,7 @@ static void __tg3_set_coalesce(struct tg
}
/* tp-lock is held. */
-static int tg3_reset_hw(struct tg3 *tp)
+static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
{
u32 val, rdmac_mode;
int i, err, limit;
@@ -5813,7 +5813,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tg3_abort_hw(tp, 1);
}
- if (tp-tg3_flags2 TG3_FLG2_MII_SERDES)
+ if ((tp-tg3_flags2 TG3_FLG2_MII_SERDES) reset_phy)
tg3_phy_reset(tp);
err = tg3_chip_reset(tp);
@@ -6354,7 +6354,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tw32(GRC_LOCAL_CTRL, tp-grc_local_ctrl);
}
- err = tg3_setup_phy(tp, 1);
+ err = tg3_setup_phy(tp, reset_phy);
if (err)
return err;
@@ -6427,7 +6427,7 @@ static int tg3_reset_hw(struct tg3 *tp)
/* Called at device open time to get the chip ready for
* packet processing. Invoked with tp-lock held.
*/
-static int tg3_init_hw(struct tg3 *tp)
+static int tg3_init_hw(struct tg3 *tp, int reset_phy)
{
int err;
@@ -6440,7 +6440,7 @@ static int tg3_init_hw(struct tg3 *tp)
tw32(TG3PCI_MEM_WIN_BASE_ADDR, 0);
- err = tg3_reset_hw(tp);
+ err = tg3_reset_hw(tp, reset_phy);
out:
return err;
@@ -6710,7 +6710,7 @@ static int tg3_test_msi(struct tg3 *tp)
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
tg3_full_unlock(tp);
@@ -6775,7 +6775,7 @@ static int tg3_open(struct net_device *d
tg3_full_lock(tp, 0);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
if (err) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
tg3_free_rings(tp);
@@ -7866,7 +7866,7 @@ static int tg3_set_ringparam(struct net_
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -7911,7 +7911,7 @@ static int tg3_set_pauseparam(struct net
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -8549,7 +8549,7 @@ static int tg3_test_loopback(struct tg3
if (!netif_running(tp-dev))
return TG3_LOOPBACK_FAILED;
- tg3_reset_hw(tp);
+ tg3_reset_hw(tp, 1);
if (tg3_run_loopback(tp, TG3_MAC_LOOPBACK))
err |= TG3_MAC_LOOPBACK_FAILED;
@@ -8623,7 +8623,7 @@ static void tg3_self_test(struct net_dev
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
if (netif_running(dev)) {
tp-tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -11599,7 +11599,7 @@ static int tg3_suspend(struct pci_dev *p
tg3_full_lock(tp, 0);
tp-tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tp-timer.expires = jiffies + tp-timer_offset;
add_timer(tp-timer);
@@ -11633,7 +11633,7 @@ static int tg3_resume(struct pci_dev *pd
[PATCH 6/6] tg3: Update version and reldate
Update version to 3.57. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 0779544..beeb612 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -69,8 +69,8 @@ #define DRV_MODULE_NAMEtg3 #define PFX DRV_MODULE_NAME: -#define DRV_MODULE_VERSION 3.56 -#define DRV_MODULE_RELDATE Apr 1, 2006 +#define DRV_MODULE_VERSION 3.57 +#define DRV_MODULE_RELDATE Apr 28, 2006 #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] tg3: Fix bug in nvram write
Fix bug in nvram write function. If the starting nvram address offset happens to be the last dword of the page, the NVRAM_CMD_LAST bit will not get set in the existing code. This patch fixes the bug by changing the else if to if so that the last dword condition always gets checked. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 97e27d8..0779544 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -9404,7 +9404,7 @@ static int tg3_nvram_write_block_buffere if ((page_off == 0) || (i == 0)) nvram_cmd |= NVRAM_CMD_FIRST; - else if (page_off == (tp-nvram_pagesize - 4)) + if (page_off == (tp-nvram_pagesize - 4)) nvram_cmd |= NVRAM_CMD_LAST; if (i == (len - 4)) - To unsubscribe from this list: send 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] PCI Error Recovery: e100 network device driver
On Fri, 2006-04-07 at 06:24, Linas Vepstas wrote:
Please apply and forward upstream.
--linas
[PATCH] PCI Error Recovery: e100 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ethernet e100
device driver. The patch has been tested, and appears to work well.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Jesse Brandeburg [EMAIL PROTECTED]
I am enabling PCI-Express AER (Advanced Error Reporting) in kernel and
glad to see many drivers to support pci error handling.
drivers/net/e100.c | 65
+
1 files changed, 65 insertions(+)
Index: linux-2.6.17-rc1/drivers/net/e100.c
===
--- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-05 09:56:06.0
-0500
+++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-06 15:17:29.0
-0500
@@ -2781,6 +2781,70 @@ static void e100_shutdown(struct pci_dev
}
+/* -- PCI Error Recovery infrastructure -- */
+/** e100_io_error_detected() is called when PCI error is detected */
+static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+
+ /* Same as calling e100_down(netdev_priv(netdev)), but generic */
+ netdev-stop(netdev);
e100 stop method e100_close calls e100_down which would do IO. Does it
violate the rule defined in Documentation/pci-error-recovery.txt that
error_detected shouldn't do any IO?
Suggest to create a new function, such like e100_close_noreset.
+
+ /* Detach; put netif into state similar to hotplug unplug */
+ netif_poll_enable(netdev);
+ netif_device_detach(netdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/** e100_io_slot_reset is called after the pci bus has been reset.
+ * Restart the card from scratch. */
+static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ if(pci_enable_device(pdev)) {
+ printk(KERN_ERR e100: Cannot re-enable PCI device after
reset.\n);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ /* Only one device per card can do a reset */
+ if (0 != PCI_FUNC (pdev-devfn))
+ return PCI_ERS_RESULT_RECOVERED;
+ e100_hw_reset(nic);
+ e100_phy_init(nic);
Should pci_set_master be called after e100_hw_reset like in function
e100_probe?
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/** e100_io_resume is called when the error recovery driver
+ * tells us that its OK to resume normal operation.
+ */
+static void e100_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct nic *nic = netdev_priv(netdev);
+
+ /* ack any pending wake events, disable PME */
+ pci_enable_wake(pdev, 0, 0);
+
+ netif_device_attach(netdev);
+ if(netif_running(netdev)) {
+ e100_open (netdev);
+ mod_timer(nic-watchdog, jiffies);
e100_open calls e100_up which already sets watchdog timer. Why to set
it again?
+ }
+}
+
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
