* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Herbert Xu @ 2006-04-21 1:33 UTC (permalink / raw)
To: Michael Chan; +Cc: shawvrana, netdev, Auke Kok, David S. Miller
In-Reply-To: <20060421012701.GA29053@gondor.apana.org.au>
On Fri, Apr 21, 2006 at 11:27:01AM +1000, herbert wrote:
> On Thu, Apr 20, 2006 at 03:36:57PM -0700, Michael Chan wrote:
> >
> > If we're in tg3_close() and the reset task isn't running yet, tg3_close
> > () will proceed. However, when the reset task finally runs, it will see
> > that netif_running() is zero and will just return.
>
> Yes you're absolutely right.
Actually, what if the tg3_close is followed by a tg3_open? That could
produce a spurious reset which I suppose isn't that bad. Also if the
module is unloaded bad things will happen as well. So I still don't
feel too comfortable about leaving it scheduled after a close.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: SIOCGIWSCAN wireless event behaviour
From: Daniel Drake @ 2006-04-21 1:42 UTC (permalink / raw)
To: jt; +Cc: Dan Williams, Jouni Malinen, softmac-dev, netdev, hostap
In-Reply-To: <20060420164354.GA32409@bougret.hpl.hp.com>
Jean Tourrilhes wrote:
> The original behaviour was that the event was sent only when a
> user did request a scan. At that time, cards did not do background
> scanning, so new scan results would be produced only as a result of a
> user scan.
> After a short discussion we Dan, we agree that to change that,
> the driver should send a scan whenever a new scan result is available,
> regardless of how it happens (background scan or user scan). This
> allow smart application to synchronise on background scans and avoid
> them generating useless user scans. Minimising the number of user scan
> is actually good.
Thanks for all the responses.
I am not sure if the 'extra' SIOCGIWSCAN event is what is causing
wpa_supplicant's confusion, but the kind of behaviour I am seeing is
wpa_supplicant associating to the network, immediately disassociating,
and then associating again before the connection stabilises. This is
with wpa_supplicant 0.5.2 connecting to an unencrypted network.
I am also seeing that softmac reassociates with a network after
wpa_supplicant exits.
Johannes posted a softmac patch earlier which may help (related to
softmac's handling of SIOCGIWAP). I will do some further investigation
and provide a more complete report if that doesn't fix it.
Thanks,
Daniel
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Herbert Xu @ 2006-04-21 1:27 UTC (permalink / raw)
To: Michael Chan; +Cc: shawvrana, netdev, Auke Kok, David S. Miller
In-Reply-To: <1145572617.3310.4.camel@rh4>
On Thu, Apr 20, 2006 at 03:36:57PM -0700, Michael Chan wrote:
>
> If we're in tg3_close() and the reset task isn't running yet, tg3_close
> () will proceed. However, when the reset task finally runs, it will see
> that netif_running() is zero and will just return.
Yes you're absolutely right.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: David S. Miller @ 2006-04-21 1:13 UTC (permalink / raw)
To: rick.jones2; +Cc: olof, andrew.grover, netdev
In-Reply-To: <44482EB5.9030605@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 20 Apr 2006 18:00:37 -0700
> Actually, that brings-up a question - presently, and for reasons that
> are lost to me in the mists of time - netperf will "access" the buffer
> before it calls recv(). I'm wondering if that should be changed to an
> access of the buffer after it calls recv()?
Yes, that's what it should do, as this is whan a real
application would do.
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Rick Jones @ 2006-04-21 1:02 UTC (permalink / raw)
To: David S. Miller; +Cc: andy.grover, olof, andrew.grover, netdev
In-Reply-To: <20060420.173853.60273448.davem@davemloft.net>
David S. Miller wrote:
> From: "Andrew Grover" <andy.grover@gmail.com>
> Date: Thu, 20 Apr 2006 15:14:15 -0700
>
>
>>First obviously it's a technology for RX CPU improvement so there's no
>>benefit on TX workloads. Second it depends on there being buffers to
>>copy the data into *before* the data arrives. This happens to be the
>>case for benchmarks like netperf and Chariot, but real apps using
>>poll/select wouldn't see a benefit, Just laying the cards out here.
>>BUT we are seeing very good CPU savings on some workloads, so for
>>those apps (and if select/poll apps could make use of a
>>yet-to-be-implemented async net interface) it would be a win.
>>
>>I don't know what the breakdown is of apps doing blocking reads vs.
>>waiting, does anyone know?
>
>
> All the bandwidth benchmarks tend to block, real world servers (and
> most clients to some extent) tend to use non-blocking reads and
> poll/select except in some very limited cases and designs doing
> something like 1 thread per connection.
Another netperf2 option :) (not exported via configure though) if a
certain define is set - look at recv_tcp_stream() in nettest_bsd.c -
then netperf will call select() before it calls recv().
rick jones
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Rick Jones @ 2006-04-21 1:00 UTC (permalink / raw)
To: David S. Miller; +Cc: olof, andrew.grover, netdev
In-Reply-To: <20060420.172742.132879746.davem@davemloft.net>
> Unfortunately, many benchmarks just do raw bandwidth tests sending to
> a receiver that just doesn't even look at the data. They just return
> from recvmsg() and loop back into it. This is not what applications
> using networking actually do, so it's important to make sure we look
> intelligently at any benchmarks done and do not fall into the trap of
> saying "even without cache warming it made things faster" when in fact
> the tested receiver did not touch the data at all so was a false test.
FWIW, netperf can be configured to access the buffers it gives to send()
or gets from recv(). A ./configure --enable-dirty in TOT:
http://www.netperf.org/svn/netperf2/trunk
will enable two global options:
-k dirty,clean # bytes to dirty, bytes to read clean on netperf side
-K dirty,clean # as above, on netserver side.
And in such a netperf the test banner will include the string "dirty
data" (alas the default output will not say how much :)
In say a TCP_STREAM test -k will affect what is done with a buffer
before send() is called, and -K will affect what is done with a buffer
_before_ recv() is called with that buffer.
-k N will cause the first N bytes of the buffer to be dirtied, and the
next N bytes to be read clean
-k N, will cause the first N bytes of the buffer to be dirtied
-k ,N will cause the first N bytes of the buffer to be read clean
-k M,N will cause the first M bytes to be dirtied, the next N bytes to
be read clean
Actually, that brings-up a question - presently, and for reasons that
are lost to me in the mists of time - netperf will "access" the buffer
before it calls recv(). I'm wondering if that should be changed to an
access of the buffer after it calls recv()?
And I suspect related to all this is whether or not one should alter the
size of the buffer ring being used by netperf, which by default is the
SO_*BUF size divided by the send_size (or recv_size) plus one buffers -
the -W option can control that.
rick jones
^ permalink raw reply
* Re: Cannot receive multicast packets
From: Andrew Athan @ 2006-04-21 0:51 UTC (permalink / raw)
To: David Stevens; +Cc: netdev
In-Reply-To: <OF10DE8AFB.1FB28740-ON88257156.0083D32C-88257157.0000E5BE@us.ibm.com>
David:
Thank you for taking the time to respond.
The packets are arriving via a switched network composed of Cisco
devices in PIM dense mode. The packets pass through several switch
hops, but no routing hops that have been documented to me. I did not
think the source IP was relevant to the matching code in linux, since
there are no source squelching socket options.
There are no firewall rules active on this machine, and the packets are
definitely visible at the interface (see tcpdump output in my email).
I am going to try upgrading the kernel, and turning off the multicast
router kernel options as a next step. But if you have any other ideas
at all, I'm all ears.
This seems too much like Mr. Murphy's in the room.
A.
David Stevens wrote:
> I've run your test program and it receives fine for me.
>
> I note that the source address is not on the same subnet as
> (any of) the receiver's addresses. Are the packets being
> routed? The default multicasting TTL is 1, though I don't
> know if it'll be checked or dropped on the receiver, seeing
> as we aren't forwarding it.
>
> Also, you might want to run "netstat -s" to see if any of the
> drop counters are being incremented (e.g., checksum error).
>
> Finally, I'm assuming you don't have any firewall rules that
> are matching, right?
>
> +-DLS
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: David S. Miller @ 2006-04-21 0:44 UTC (permalink / raw)
To: olof; +Cc: andy.grover, netdev
In-Reply-To: <20060420233343.GL26746@pb15.lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Thu, 20 Apr 2006 18:33:43 -0500
> On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> > In
> > addition, there may be workloads (file serving? backup?) where we
> > could do a skb->page-in-page-cache copy and avoid cache pollution?
>
> Yes, NFS is probably a prime example of where most of the data isn't
> looked at; just written to disk. I'm not sure how well-optimized the
> receive path is there already w.r.t. avoiding copying though. I don't
> remember seeing memcpy and friends being high on the profile when I
> looked at SPECsfs last.
If that makes sense then the cpu copy can be made to use non-temporal
stores.
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: David S. Miller @ 2006-04-21 0:38 UTC (permalink / raw)
To: andy.grover; +Cc: olof, andrew.grover, netdev
In-Reply-To: <c0a09e5c0604201514x16490b13v68644a24078b99de@mail.gmail.com>
From: "Andrew Grover" <andy.grover@gmail.com>
Date: Thu, 20 Apr 2006 15:14:15 -0700
> First obviously it's a technology for RX CPU improvement so there's no
> benefit on TX workloads. Second it depends on there being buffers to
> copy the data into *before* the data arrives. This happens to be the
> case for benchmarks like netperf and Chariot, but real apps using
> poll/select wouldn't see a benefit, Just laying the cards out here.
> BUT we are seeing very good CPU savings on some workloads, so for
> those apps (and if select/poll apps could make use of a
> yet-to-be-implemented async net interface) it would be a win.
>
> I don't know what the breakdown is of apps doing blocking reads vs.
> waiting, does anyone know?
All the bandwidth benchmarks tend to block, real world servers (and
most clients to some extent) tend to use non-blocking reads and
poll/select except in some very limited cases and designs doing
something like 1 thread per connection.
This is an issue for the TCP prequeue and as a consequence VJ's net
channel ideas. We need something to wakeup some context in order to
push channel data.
All the net channel stuff really wants is an execution context to
run the TCP stack outside of software interrupts. I/O AT wants
something similar.
For net channels the probably best thing to do is to just queue
to the socket's netchannel, and mark poll state appropriately
and just wait for the thread to get back into recvmsg() to run
the queue. So I think net channels can be handled in all cases
and application I/O models.
For I/O AT you'd really want to get the DMA engine going as soon
as you had those packets, but I do not see a clean and reliable way
to determine the target pages before the app gets back to recvmsg().
I/O AT really expects a lot of things to be in place in order for it
to function at all. And sadly, that set of requirements isn't
actually very common outside of benchmarking tools and a few
uncommonly designed servers. Even a web browser does non-blocking
reads and poll().
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: David S. Miller @ 2006-04-21 0:27 UTC (permalink / raw)
To: olof; +Cc: andrew.grover, netdev
In-Reply-To: <20060420213305.GK26746@pb15.lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Thu, 20 Apr 2006 16:33:05 -0500
> From the wiki:
>
> > 3. Data copied by I/OAT is not cached
>
> This is a I/OAT device limitation and not a global statement of the
> DMA infrastructure. Other platforms might be able to prime caches
> with the DMA traffic. Hint flags should be added on either the channel
> allocation calls, or per-operation calls, depending on where it makes
> sense driver/client wise.
This sidesteps the whole question of _which_ cache to warm. And if
you choose wrongly, then what?
Besides the control overhead of the DMA engines, the biggest thing
lost in my opinion is the perfect cache warming that a cpu based copy
does from the kernel socket buffer into userspace.
The first thing an application is going to do is touch that data. So
I think it's very important to prewarm the caches and the only
straightforward way I know of to always warm up the correct cpu's
caches is copy_to_user().
Unfortunately, many benchmarks just do raw bandwidth tests sending to
a receiver that just doesn't even look at the data. They just return
from recvmsg() and loop back into it. This is not what applications
using networking actually do, so it's important to make sure we look
intelligently at any benchmarks done and do not fall into the trap of
saying "even without cache warming it made things faster" when in fact
the tested receiver did not touch the data at all so was a false test.
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Michael Chan @ 2006-04-20 22:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: shawvrana, netdev, Auke Kok, David S. Miller
In-Reply-To: <20060420235149.GA28503@gondor.apana.org.au>
On Fri, 2006-04-21 at 09:51 +1000, Herbert Xu wrote:
>
> Actually TG3 is buggy too. If the reset task is scheduled but
> isn't running yet there is no synchronisation here to prevent the
> reset task from running after tg3_close releases the tp lock.
>
If we're in tg3_close() and the reset task isn't running yet, tg3_close
() will proceed. However, when the reset task finally runs, it will see
that netif_running() is zero and will just return.
^ permalink raw reply
* Re: Cannot receive multicast packets
From: David Stevens @ 2006-04-21 0:15 UTC (permalink / raw)
To: Andrew Athan; +Cc: netdev
In-Reply-To: <4447DFDD.8010008@cloakmail.com>
I've run your test program and it receives fine for me.
I note that the source address is not on the same subnet as
(any of) the receiver's addresses. Are the packets being
routed? The default multicasting TTL is 1, though I don't
know if it'll be checked or dropped on the receiver, seeing
as we aren't forwarding it.
Also, you might want to run "netstat -s" to see if any of the
drop counters are being incremented (e.g., checksum error).
Finally, I'm assuming you don't have any firewall rules that
are matching, right?
+-DLS
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Herbert Xu @ 2006-04-20 23:51 UTC (permalink / raw)
To: shawvrana; +Cc: netdev, Auke Kok, David S. Miller, Michael Chan
In-Reply-To: <20060420233631.GA28380@gondor.apana.org.au>
On Fri, Apr 21, 2006 at 09:36:31AM +1000, herbert wrote:
>
> Yes that's definitely buggy. There needs to be some form of
> synchronisation as the TG3 driver does. However, to be frank
> I'm not too fond of what the TG3 driver does either. Is there
> no better way than an msleep loop?
Actually TG3 is buggy too. If the reset task is scheduled but
isn't running yet there is no synchronisation here to prevent the
reset task from running after tg3_close releases the tp lock.
It needs to kill the reset task and make sure it doesn't get
rescheduled by someone else.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] Netlink and user-space buffer pointers
From: Andrew Vasquez @ 2006-04-20 23:44 UTC (permalink / raw)
To: James Smart; +Cc: Mike Christie, linux-scsi, netdev, linux-kernel
In-Reply-To: <4447E91E.7030603@emulex.com>
On Thu, 20 Apr 2006, James Smart wrote:
> Note: We've transitioned off topic. If what this means is "there isn't a
> good
> way except by ioctls (which still isn't easily portable) or system calls",
> then that's ok. Then at least we know the limits and can look at other
> implementation alternatives.
this topic has been brought-up many times in the past, most recently:
http://thread.gmane.org/gmane.linux.drivers.openib/19525/focus=19525
http://thread.gmane.org/gmane.linux.kernel/387375/focus=387455
where is was suggested to pathscale folks to use some blend of sysfs,
netlink sockets and debugfs:
http://kerneltrap.org/node/4394
> >>Mike Christie wrote:
> >Instead of netlink for scsi commands and transport requests....
> >
> >For scsi commands could we just use sg io, or is there something special
> >about the command you want to send? If you can use sg io for scsi
> >commands, maybe for transport level requests (in my example iscsi pdu)
> >we could modify something like sg/bsg/block layer scsi_ioctl.c to send
> >down transport requests to the classes and encapsulate them in some new
> >struct transport_requests or use the existing struct request but do that
> >thing people keep taling about using the request/request_queue for
> >message passing.
>
> Well - there's 2 parts to this answer:
>
> First : IOCTL's are considered dangerous/bad practice and therefore it would
> be nice to find a replacement mechanism that eliminates them. If that
> mechanism has some of the cool features that netlink does, even better.
> Using sg io, in the manner you indicate, wouldn't remove the ioctl use.
> Note: I have OEMs/users that are very confused about the community's
> statement
> about ioctls. They've heard they are bad, should never be allowed, will no
> be longer supported, but yet they are at the heart of DM and sg io and
> other
> subsystems. Other than a "grandfathered" explanation, they don't
> understand
> why the rules bend for one piece of code but not for another. To them, all
> the features are just as critical regardless of whose providing them.
I believe it to be the same for most hardware-vendor's customers...
> Second: transport level i/o could be done like you suggest, and we've
> prototyped some of this as well. However, there's something very wrong
> about putting "block device" wrappers and settings around something that
> is not a block device.
Eeww... no wrappers. Your netlink prototypes certainly get FC-
transport further along, but would also be nice if there could be some
subsystem consensus on *the* interface.
I honestly don't know which interface is *best*, but from a HBA
vendors perspective managing per-request locally allocated memory is
undesirable.
Thanks,
av
^ permalink raw reply
* RE: [PATCH 2.6.16-rc5] S2io: Receive packet classification and steering mechanisms
From: Ravinandan Arakali @ 2006-04-20 23:41 UTC (permalink / raw)
To: Andi Kleen; +Cc: jgarzik, netdev
In-Reply-To: <200604200251.14309.ak@suse.de>
Andi,
The driver will be polling(listening) to netlink for
any configuration requests. We could release the user
tools but not sure where(in the tree) they would reside.
Thanks,
Ravi
-----Original Message-----
From: Andi Kleen [mailto:ak@suse.de]
Sent: Wednesday, April 19, 2006 5:51 PM
To: ravinandan.arakali@neterion.com
Cc: jgarzik@pobox.com; netdev@vger.kernel.org
Subject: Re: [PATCH 2.6.16-rc5] S2io: Receive packet classification and
steering mechanisms
On Thursday 20 April 2006 00:45, Ravinandan Arakali wrote:
> Andi,
> We would like to explain that this patch is tier-1 of a two
> tiered approach. It implements all the steering
> functionality at driver-only level, and it is fairly Neterion-specific.
That's fine for experiments, but probably not something
that should be in tree.
>
> The second upcoming submission will add a generic netlink-based
> interface for channel data flow and configuration(including receive
steering
> parameters) on per-channel basis, that will utilize the lower level
> implementation from the current patch.
Will the driver itself listening to netlink?
My feeling would be to teach the stack to use this would require
efficient interfaces and netlink isn't particularly. But if it's just
a glue module outside the driver that would be reasonable as a first
step I guess.
Do you also plan to release user tools to use it?
-Andi
^ permalink raw reply
* Re: e1000_down and tx_timeout worker race cleaning the transmit buffers
From: Herbert Xu @ 2006-04-20 23:36 UTC (permalink / raw)
To: shawvrana; +Cc: netdev, Auke Kok, David S. Miller, Michael Chan
In-Reply-To: <200604201035.00100.shaw@vranix.com>
On Thu, Apr 20, 2006 at 05:35:00PM +0000, shawvrana@gmail.com wrote:
>
> If the e1000_tx_timeout_task were running concurrently with e1000_down, it
> seems that they could both attempt to kfree_skb concurrently when running
> e1000_unmap_and_free_tx_resource. I googled around to find mention of this
> anywhere with no luck. Has this been discussed already?
Yes that's definitely buggy. There needs to be some form of
synchronisation as the TG3 driver does. However, to be frank
I'm not too fond of what the TG3 driver does either. Is there
no better way than an msleep loop?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Olof Johansson @ 2006-04-20 23:33 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev
In-Reply-To: <c0a09e5c0604201514x16490b13v68644a24078b99de@mail.gmail.com>
On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> Hah, I was just writing an email covering those. I'll incorporate that
> into this reponse.
>
> On 4/20/06, Olof Johansson <olof@lixom.net> wrote:
> > I guess the overall question is, how much of this needs to be addressed
> > in the implementation before merge, and how much should be done when
> > more drivers (with more features) are merged down the road. It might not
> > make sense to implement all of it now if the only available public
> > driver lacks the abilities. But I'm bringing up the points anyway.
>
> Yeah. But I would think maybe this is a reason to merge at least the
> DMA subsystem code, so people with other HW (ARM? I'm still not
> exactly sure) can start trying to write a DMA driver and see where the
> architecture needs to be generalized further.
The interfaces need to evolve as people implement drivers, yes. If it
should be before or after merging can be discussed, but as long as
everyone is on the same page w.r.t. the interfaces being volatile for a
while, merge should be OK.
Having a roadmap of known-todo improvements could be beneficial for
everyone involved, especially if several people start looking at drivers
in parallel. However, so far, (public) activity seems to have been
fairly low.
> > I would also prefer to see the series clearly split between the DMA
> > framework and first clients (networking) and the I/OAT driver. Right now
> > "I/OAT" and "DMA" is used interchangeably, especially when describing
> > the later patches. It might help you in the perception that this is
> > something unique to the Intel chipsets as well. :-)
>
> I think we have this reasonably well split-out in the patches, but yes
> you're right about how we've been using the terms.
The patches are well split up already, it was mostly that the network
stack changes were marked as I/OAT changes instead of DMA dito.
> > > 1. Performance improvement may be on too narrow a set of workloads
> > Maybe from I/OAT and the current client, but the introduction of the
> > DMA infrastructure opens up for other uses that are not yet possible in
> > the API. For example, DMA with functions is a very natural extension,
> > and something that's very common on various platforms (XOR for RAID use,
> > checksums, encryption).
>
> Yes. Does this hardware exist in shipping platforms, so we could use
> actual hw to start evaluating the DMA interfaces?
Freescale has it on several processors that are shipping, as far as I
know. Other embedded families likely has them as well (MIPS, ARM), but
I don't know details. The platform I am working on is not yet shipping;
I've just started looking at drivers.
> > For people who might want to play with it, a reference software-based
> > implementation might be useful.
>
> Yeah I'll ask if I can post the one we have. Or it would be trivial to write.
I was going to look at it myself, but if you have one to post that's
even more trivial. :-)
> > > 3. Data copied by I/OAT is not cached
> >
> > This is a I/OAT device limitation and not a global statement of the
> > DMA infrastructure. Other platforms might be able to prime caches
> > with the DMA traffic. Hint flags should be added on either the channel
> > allocation calls, or per-operation calls, depending on where it makes
> > sense driver/client wise.
>
> Furthermore in our implementation's defense I would say I think the
> smart prefetching that modern CPUs do is helping here.
Yes. It's also not obvious that warming the cache at copy time is always
a gain, it will depends on the receiver and what it does with the data.
> In any case, we
> are seeing performance gains (see benchmarks), which seems to indicate
> this is not an immediate deal-breaker for the technology..
There's always the good old benefit-vs-added-complexity tradeoff, which
I guess is the sore spot right now.
> In
> addition, there may be workloads (file serving? backup?) where we
> could do a skb->page-in-page-cache copy and avoid cache pollution?
Yes, NFS is probably a prime example of where most of the data isn't
looked at; just written to disk. I'm not sure how well-optimized the
receive path is there already w.r.t. avoiding copying though. I don't
remember seeing memcpy and friends being high on the profile when I
looked at SPECsfs last.
> > > 4. Intrusiveness of net stack modifications
> > > 5. Compatibility with upcoming VJ net channel architecture
> > Both of these are outside my scope, so I won't comment on them at this
> > time.
>
> Yeah I don't have much to say about these except we made the patch as
> unintrusive as we could, and we think there may be ways to use async
> DMA to
> help VJ channels, whenever they arrive.
Not that I know all the tricks they are using, but it seems to me that it
would be hard to both be efficient w.r.t memory use (i.e. more than one
IP packet per page) AND avoid copying once. At least without device-level
flow classification and per-flow (process) buffer rings.
-Olof
^ permalink raw reply
* Open ethernet hardware specs
From: Jeff Garzik @ 2006-04-20 22:55 UTC (permalink / raw)
To: Netdev List; +Cc: Linux Kernel
I started a specs section on the linux-net wiki:
http://linux-net.osdl.org/index.php?title=Network-Adapters#Hardware_specifications
If you add to this list, please be SURE of the specification's origin.
We do not want to link to any "fell off the back of a truck" specs of
questionable origin.
Also, janitors, there are more NIC specs at
http://gkernel.sourceforge.net/specs/ than are listed on the wiki. What
I posted is just a starter list. If someone were to comb through each
PDF in the /specs/ sub-directories, and make sure it is linked on the
wiki, I would be grateful.
Jeff
^ permalink raw reply
* Re: Please pull upstream-fixes branch of wireless-2.6
From: Linus Torvalds @ 2006-04-20 22:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: John W. Linville, mb, jeff, netdev
In-Reply-To: <20060420125816.678901bd.akpm@osdl.org>
On Thu, 20 Apr 2006, Andrew Morton wrote:
> "John W. Linville" <linville@tuxdriver.com> wrote:
> >
> > At present, all the branches in wireless-2.6 only pull from linux-2.6.
> > I am still pushing (i.e. requesting Jeff's pull) to netdev-2.6,
> > if that matters.
> >
> > Maybe the current wireless-2.6 tree fits into your system better?
>
> Works well, thanks. I have some patches for you ;)
Well, since Jeff pushed it on to me, if you have patches that fix obvious
problems and should go in before 2.6.17, you can now push those directly
to me too ;)
Linus
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Andrew Grover @ 2006-04-20 22:14 UTC (permalink / raw)
To: Olof Johansson; +Cc: Andrew Grover, netdev
In-Reply-To: <20060420213305.GK26746@pb15.lixom.net>
Hah, I was just writing an email covering those. I'll incorporate that
into this reponse.
On 4/20/06, Olof Johansson <olof@lixom.net> wrote:
> I guess the overall question is, how much of this needs to be addressed
> in the implementation before merge, and how much should be done when
> more drivers (with more features) are merged down the road. It might not
> make sense to implement all of it now if the only available public
> driver lacks the abilities. But I'm bringing up the points anyway.
Yeah. But I would think maybe this is a reason to merge at least the
DMA subsystem code, so people with other HW (ARM? I'm still not
exactly sure) can start trying to write a DMA driver and see where the
architecture needs to be generalized further.
> Maybe it could make sense to add a software-based driver for reference,
> and for others to play around with.
We wrote one, but just for testing. I think we've been focused on the
performance story, so it didn't seem a priority.
> I would also prefer to see the series clearly split between the DMA
> framework and first clients (networking) and the I/OAT driver. Right now
> "I/OAT" and "DMA" is used interchangeably, especially when describing
> the later patches. It might help you in the perception that this is
> something unique to the Intel chipsets as well. :-)
I think we have this reasonably well split-out in the patches, but yes
you're right about how we've been using the terms.
> (I have also proposed DMA offload discussions as a topic for the Kernel
> Summit. I have kept Chris Leech Cc:d on most of the emails in question. It
> should be a good place to get input from other subsystems regarding what
> functionality they would like to see provided, etc.)
I think that would be a good topic for the KS - like you say not
necessarily I/OAT but general DMA offload.
> > 1. Performance improvement may be on too narrow a set of workloads
> Maybe from I/OAT and the current client, but the introduction of the
> DMA infrastructure opens up for other uses that are not yet possible in
> the API. For example, DMA with functions is a very natural extension,
> and something that's very common on various platforms (XOR for RAID use,
> checksums, encryption).
Yes. Does this hardware exist in shipping platforms, so we could use
actual hw to start evaluating the DMA interfaces?
While you may not care (:-) I'd like to address the network
performance aspect above, for other netdev readers:
First obviously it's a technology for RX CPU improvement so there's no
benefit on TX workloads. Second it depends on there being buffers to
copy the data into *before* the data arrives. This happens to be the
case for benchmarks like netperf and Chariot, but real apps using
poll/select wouldn't see a benefit, Just laying the cards out here.
BUT we are seeing very good CPU savings on some workloads, so for
those apps (and if select/poll apps could make use of a
yet-to-be-implemented async net interface) it would be a win.
I don't know what the breakdown is of apps doing blocking reads vs.
waiting, does anyone know?
> > 2. Limited availability of hardware supporting I/OAT
>
> DMA engines are fairly common, even though I/OAT might not be yet. They
> just haven't had a common infrastructure until now.
We've engaged early that's a good thing :) I think we'd like to see
some netdev people do some independent performance analysis of it. If
anyone is willing to do so and has time to do so, email us and let's
see what we can work out.
> For people who might want to play with it, a reference software-based
> implementation might be useful.
Yeah I'll ask if I can post the one we have. Or it would be trivial to write.
> > 3. Data copied by I/OAT is not cached
>
> This is a I/OAT device limitation and not a global statement of the
> DMA infrastructure. Other platforms might be able to prime caches
> with the DMA traffic. Hint flags should be added on either the channel
> allocation calls, or per-operation calls, depending on where it makes
> sense driver/client wise.
Furthermore in our implementation's defense I would say I think the
smart prefetching that modern CPUs do is helping here. In any case, we
are seeing performance gains (see benchmarks), which seems to indicate
this is not an immediate deal-breaker for the technology.. In
addition, there may be workloads (file serving? backup?) where we
could do a skb->page-in-page-cache copy and avoid cache pollution?
> > 4. Intrusiveness of net stack modifications
> > 5. Compatibility with upcoming VJ net channel architecture
> Both of these are outside my scope, so I won't comment on them at this
> time.
Yeah I don't have much to say about these except we made the patch as
unintrusive as we could, and we think there may be ways to use async
DMA to
help VJ channels, whenever they arrive.
> I would like to add, for longer term:
> * Userspace interfaces:
> Are there any plans yet on how to export some of this to userspace? It
> might not make full sense for just memcpy due to overheads, but it makes
> sense for more advanced dma/offload engines.
I agree.
Regards -- Andy
^ permalink raw reply
* Re: e1000 breakage in git-netdev-all
From: Jeff Garzik @ 2006-04-20 21:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: John Ronciak, Auke Kok, Jesse Brandeburg, netdev
In-Reply-To: <20060417234147.6c1802de.akpm@osdl.org>
Andrew Morton wrote:
> A bunch of e1000 changes just hit Jeff's tree.
Hopefully things are now fixed in git-netdev-all...
Jeff
^ permalink raw reply
* [git patches] net driver fixes
From: Jeff Garzik @ 2006-04-20 21:46 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, linux-kernel
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/ne.c | 2
drivers/net/wireless/Kconfig | 2
drivers/net/wireless/airo.c | 46 +++-------
drivers/net/wireless/atmel.c | 11 ++
drivers/net/wireless/bcm43xx/Kconfig | 3
drivers/net/wireless/bcm43xx/bcm43xx.h | 17 +++
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 8 -
drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 13 +-
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 2
drivers/net/wireless/bcm43xx/bcm43xx_phy.c | 1
drivers/net/wireless/bcm43xx/bcm43xx_power.c | 115 ++++++++++++++-----------
drivers/net/wireless/bcm43xx/bcm43xx_power.h | 9 +
drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c | 115 ++++++++++++++-----------
drivers/net/wireless/bcm43xx/bcm43xx_sysfs.h | 16 ---
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 8 -
drivers/net/wireless/orinoco.c | 2
include/net/ieee80211softmac.h | 3
net/core/dev.c | 3
net/core/wireless.c | 8 +
net/ieee80211/softmac/Kconfig | 1
net/ieee80211/softmac/ieee80211softmac_assoc.c | 5 -
net/ieee80211/softmac/ieee80211softmac_event.c | 40 +++++++-
net/ieee80211/softmac/ieee80211softmac_io.c | 18 +++
net/ieee80211/softmac/ieee80211softmac_scan.c | 2
net/ieee80211/softmac/ieee80211softmac_wx.c | 10 ++
25 files changed, 289 insertions(+), 171 deletions(-)
Adrian Bunk:
bcm43xx: fix dyn tssi2dbm memleak
Dan Williams:
wireless/airo: clean up WEXT association and scan events
wireless/atmel: send WEXT scan completion events
Erik Mouw:
bcm43xx: iw_priv_args names should be <16 characters
Jean Tourrilhes:
wext: Fix IWENCODEEXT security permissions
Revert NET_RADIO Kconfig title change
wext: Fix RtNetlink ENCODE security permissions
Johannes Berg:
softmac: fix event sending
softmac: report when scanning has finished
johannes@sipsolutions.net:
softmac: return -EAGAIN from getscan while scanning
softmac: dont send out packets while scanning
softmac: handle iw_mode properly
Michael Buesch:
softmac: fix spinlock recursion on reassoc
bcm43xx: set trans_start on TX to prevent bogus timeouts
bcm43xx: fix pctl slowclock limit calculation
bcm43xx: sysfs code cleanup
Pavel Roskin:
orinoco: fix truncating commsquality RID with the latest Symbol firmware
Randy Dunlap:
softmac uses Wiress Ext.
bcm43xx wireless: fix printk format warnings
bcm43xx: fix config menu alignment
Sergei Shtylyov:
NEx000: fix RTL8019AS base address for RBTX4938
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index 08b218c..93c494b 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -226,7 +226,7 @@ struct net_device * __init ne_probe(int
netdev_boot_setup_check(dev);
#ifdef CONFIG_TOSHIBA_RBTX4938
- dev->base_addr = 0x07f20280;
+ dev->base_addr = RBTX4938_RTL_8019_BASE;
dev->irq = RBTX4938_RTL_8019_IRQ;
#endif
err = do_ne_probe(dev);
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index bad09eb..e0874cb 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -6,7 +6,7 @@ menu "Wireless LAN (non-hamradio)"
depends on NETDEVICES
config NET_RADIO
- bool "Wireless LAN drivers (non-hamradio)"
+ bool "Wireless LAN drivers (non-hamradio) & Wireless Extensions"
select WIRELESS_EXT
---help---
Support for wireless LANs and everything having to do with radio,
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 108d9fe..00764dd 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -3139,6 +3139,7 @@ static irqreturn_t airo_interrupt ( int
}
if ( status & EV_LINK ) {
union iwreq_data wrqu;
+ int scan_forceloss = 0;
/* The link status has changed, if you want to put a
monitor hook in, do it here. (Remember that
interrupts are still disabled!)
@@ -3157,7 +3158,8 @@ static irqreturn_t airo_interrupt ( int
code) */
#define AUTHFAIL 0x0300 /* Authentication failure (low byte is reason
code) */
-#define ASSOCIATED 0x0400 /* Assocatied */
+#define ASSOCIATED 0x0400 /* Associated */
+#define REASSOCIATED 0x0600 /* Reassociated? Only on firmware >= 5.30.17 */
#define RC_RESERVED 0 /* Reserved return code */
#define RC_NOREASON 1 /* Unspecified reason */
#define RC_AUTHINV 2 /* Previous authentication invalid */
@@ -3174,44 +3176,30 @@ static irqreturn_t airo_interrupt ( int
leaving BSS */
#define RC_NOAUTH 9 /* Station requesting (Re)Association is not
Authenticated with the responding station */
- if (newStatus != ASSOCIATED) {
- if (auto_wep && !apriv->expires) {
- apriv->expires = RUN_AT(3*HZ);
- wake_up_interruptible(&apriv->thr_wait);
- }
- } else {
- struct task_struct *task = apriv->task;
+ if (newStatus == FORCELOSS && apriv->scan_timeout > 0)
+ scan_forceloss = 1;
+ if(newStatus == ASSOCIATED || newStatus == REASSOCIATED) {
if (auto_wep)
apriv->expires = 0;
- if (task)
- wake_up_process (task);
+ if (apriv->task)
+ wake_up_process (apriv->task);
set_bit(FLAG_UPDATE_UNI, &apriv->flags);
set_bit(FLAG_UPDATE_MULTI, &apriv->flags);
- }
- /* Question : is ASSOCIATED the only status
- * that is valid ? We want to catch handover
- * and reassociations as valid status
- * Jean II */
- if(newStatus == ASSOCIATED) {
-#if 0
- /* FIXME: Grabbing scan results here
- * seems to be too early??? Just wait for
- * timeout instead. */
- if (apriv->scan_timeout > 0) {
- set_bit(JOB_SCAN_RESULTS, &apriv->flags);
- wake_up_interruptible(&apriv->thr_wait);
- }
-#endif
+
if (down_trylock(&apriv->sem) != 0) {
set_bit(JOB_EVENT, &apriv->flags);
wake_up_interruptible(&apriv->thr_wait);
} else
airo_send_event(dev);
- } else {
- memset(wrqu.ap_addr.sa_data, '\0', ETH_ALEN);
- wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ } else if (!scan_forceloss) {
+ if (auto_wep && !apriv->expires) {
+ apriv->expires = RUN_AT(3*HZ);
+ wake_up_interruptible(&apriv->thr_wait);
+ }
/* Send event to user space */
+ memset(wrqu.ap_addr.sa_data, '\0', ETH_ALEN);
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
wireless_send_event(dev, SIOCGIWAP, &wrqu,NULL);
}
}
@@ -7136,10 +7124,10 @@ static int airo_set_scan(struct net_devi
goto out;
/* Initiate a scan command */
+ ai->scan_timeout = RUN_AT(3*HZ);
memset(&cmd, 0, sizeof(cmd));
cmd.cmd=CMD_LISTBSS;
issuecommand(ai, &cmd, &rsp);
- ai->scan_timeout = RUN_AT(3*HZ);
wake = 1;
out:
diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
index 87afa68..8606c88 100644
--- a/drivers/net/wireless/atmel.c
+++ b/drivers/net/wireless/atmel.c
@@ -3463,6 +3463,7 @@ static void atmel_command_irq(struct atm
u8 status = atmel_rmem8(priv, atmel_co(priv, CMD_BLOCK_STATUS_OFFSET));
u8 command = atmel_rmem8(priv, atmel_co(priv, CMD_BLOCK_COMMAND_OFFSET));
int fast_scan;
+ union iwreq_data wrqu;
if (status == CMD_STATUS_IDLE ||
status == CMD_STATUS_IN_PROGRESS)
@@ -3487,6 +3488,7 @@ static void atmel_command_irq(struct atm
atmel_scan(priv, 1);
} else {
int bss_index = retrieve_bss(priv);
+ int notify_scan_complete = 1;
if (bss_index != -1) {
atmel_join_bss(priv, bss_index);
} else if (priv->operating_mode == IW_MODE_ADHOC &&
@@ -3495,8 +3497,14 @@ static void atmel_command_irq(struct atm
} else {
priv->fast_scan = !fast_scan;
atmel_scan(priv, 1);
+ notify_scan_complete = 0;
}
priv->site_survey_state = SITE_SURVEY_COMPLETED;
+ if (notify_scan_complete) {
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ wireless_send_event(priv->dev, SIOCGIWSCAN, &wrqu, NULL);
+ }
}
break;
@@ -3509,6 +3517,9 @@ static void atmel_command_irq(struct atm
priv->site_survey_state = SITE_SURVEY_COMPLETED;
if (priv->station_is_associated) {
atmel_enter_state(priv, STATION_STATE_READY);
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ wireless_send_event(priv->dev, SIOCGIWSCAN, &wrqu, NULL);
} else {
atmel_scan(priv, 1);
}
diff --git a/drivers/net/wireless/bcm43xx/Kconfig b/drivers/net/wireless/bcm43xx/Kconfig
index 4184656..25ea474 100644
--- a/drivers/net/wireless/bcm43xx/Kconfig
+++ b/drivers/net/wireless/bcm43xx/Kconfig
@@ -17,8 +17,11 @@ config BCM43XX_DEBUG
config BCM43XX_DMA
bool
+ depends on BCM43XX
+
config BCM43XX_PIO
bool
+ depends on BCM43XX
choice
prompt "BCM43xx data transfer mode"
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h b/drivers/net/wireless/bcm43xx/bcm43xx.h
index dcadd29..2e83083 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -15,7 +15,6 @@
#include "bcm43xx_debugfs.h"
#include "bcm43xx_leds.h"
-#include "bcm43xx_sysfs.h"
#define PFX KBUILD_MODNAME ": "
@@ -638,8 +637,6 @@ struct bcm43xx_key {
};
struct bcm43xx_private {
- struct bcm43xx_sysfs sysfs;
-
struct ieee80211_device *ieee;
struct ieee80211softmac_device *softmac;
@@ -772,6 +769,20 @@ struct bcm43xx_private * bcm43xx_priv(st
return ieee80211softmac_priv(dev);
}
+struct device;
+
+static inline
+struct bcm43xx_private * dev_to_bcm(struct device *dev)
+{
+ struct net_device *net_dev;
+ struct bcm43xx_private *bcm;
+
+ net_dev = dev_get_drvdata(dev);
+ bcm = bcm43xx_priv(net_dev);
+
+ return bcm;
+}
+
/* Helper function, which returns a boolean.
* TRUE, if PIO is used; FALSE, if DMA is used.
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c b/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
index d2c3401..35a4fcb 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
@@ -452,12 +452,12 @@ void bcm43xx_printk_dump(const char *dat
size_t i;
char c;
- printk(KERN_INFO PFX "Data dump (%s, %u bytes):",
+ printk(KERN_INFO PFX "Data dump (%s, %zd bytes):",
description, size);
for (i = 0; i < size; i++) {
c = data[i];
if (i % 8 == 0)
- printk("\n" KERN_INFO PFX "0x%08x: 0x%02x, ", i, c & 0xff);
+ printk("\n" KERN_INFO PFX "0x%08zx: 0x%02x, ", i, c & 0xff);
else
printk("0x%02x, ", c & 0xff);
}
@@ -472,12 +472,12 @@ void bcm43xx_printk_bitdump(const unsign
int j;
const unsigned char *d;
- printk(KERN_INFO PFX "*** Bitdump (%s, %u bytes, %s) ***",
+ printk(KERN_INFO PFX "*** Bitdump (%s, %zd bytes, %s) ***",
description, bytes, msb_to_lsb ? "MSB to LSB" : "LSB to MSB");
for (i = 0; i < bytes; i++) {
d = data + i;
if (i % 8 == 0)
- printk("\n" KERN_INFO PFX "0x%08x: ", i);
+ printk("\n" KERN_INFO PFX "0x%08zx: ", i);
if (msb_to_lsb) {
for (j = 7; j >= 0; j--) {
if (*d & (1 << j))
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index c3681b8..bbecba0 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -196,8 +196,9 @@ static int alloc_ringmemory(struct bcm43
}
if (ring->dmabase + BCM43xx_DMA_RINGMEMSIZE > BCM43xx_DMA_BUSADDRMAX) {
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RINGMEMORY >1G "
- "(0x%08x, len: %lu)\n",
- ring->dmabase, BCM43xx_DMA_RINGMEMSIZE);
+ "(0x%llx, len: %lu)\n",
+ (unsigned long long)ring->dmabase,
+ BCM43xx_DMA_RINGMEMSIZE);
dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
ring->vbase, ring->dmabase);
return -ENOMEM;
@@ -307,8 +308,8 @@ static int setup_rx_descbuffer(struct bc
unmap_descbuffer(ring, dmaaddr, ring->rx_buffersize, 0);
dev_kfree_skb_any(skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RX SKB >1G "
- "(0x%08x, len: %u)\n",
- dmaaddr, ring->rx_buffersize);
+ "(0x%llx, len: %u)\n",
+ (unsigned long long)dmaaddr, ring->rx_buffersize);
return -ENOMEM;
}
meta->skb = skb;
@@ -729,8 +730,8 @@ static int dma_tx_fragment(struct bcm43x
if (unlikely(meta->dmaaddr + skb->len > BCM43xx_DMA_BUSADDRMAX)) {
return_slot(ring, slot);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA TX SKB >1G "
- "(0x%08x, len: %u)\n",
- meta->dmaaddr, skb->len);
+ "(0x%llx, len: %u)\n",
+ (unsigned long long)meta->dmaaddr, skb->len);
return -ENOMEM;
}
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index c37371f..9a06e61 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -52,6 +52,7 @@
#include "bcm43xx_wx.h"
#include "bcm43xx_ethtool.h"
#include "bcm43xx_xmit.h"
+#include "bcm43xx_sysfs.h"
MODULE_DESCRIPTION("Broadcom BCM43xx wireless driver");
@@ -3522,6 +3523,7 @@ static inline int bcm43xx_tx(struct bcm4
err = bcm43xx_pio_tx(bcm, txb);
else
err = bcm43xx_dma_tx(bcm, txb);
+ bcm->net_dev->trans_start = jiffies;
return err;
}
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
index 0a66f43..3313716 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -2151,6 +2151,7 @@ int bcm43xx_phy_init_tssi2dbm_table(stru
phy->tssi2dbm = NULL;
printk(KERN_ERR PFX "Could not generate "
"tssi2dBm table\n");
+ kfree(dyn_tssi2dbm);
return -ENODEV;
}
phy->tssi2dbm = dyn_tssi2dbm;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_power.c b/drivers/net/wireless/bcm43xx/bcm43xx_power.c
index 3c92b62..6569da3 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_power.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_power.c
@@ -35,77 +35,101 @@
#include "bcm43xx_main.h"
+/* Get the Slow Clock Source */
+static int bcm43xx_pctl_get_slowclksrc(struct bcm43xx_private *bcm)
+{
+ u32 tmp;
+ int err;
+
+ assert(bcm->current_core == &bcm->core_chipcommon);
+ if (bcm->current_core->rev < 6) {
+ if (bcm->bustype == BCM43xx_BUSTYPE_PCMCIA ||
+ bcm->bustype == BCM43xx_BUSTYPE_SB)
+ return BCM43xx_PCTL_CLKSRC_XTALOS;
+ if (bcm->bustype == BCM43xx_BUSTYPE_PCI) {
+ err = bcm43xx_pci_read_config32(bcm, BCM43xx_PCTL_OUT, &tmp);
+ assert(!err);
+ if (tmp & 0x10)
+ return BCM43xx_PCTL_CLKSRC_PCI;
+ return BCM43xx_PCTL_CLKSRC_XTALOS;
+ }
+ }
+ if (bcm->current_core->rev < 10) {
+ tmp = bcm43xx_read32(bcm, BCM43xx_CHIPCOMMON_SLOWCLKCTL);
+ tmp &= 0x7;
+ if (tmp == 0)
+ return BCM43xx_PCTL_CLKSRC_LOPWROS;
+ if (tmp == 1)
+ return BCM43xx_PCTL_CLKSRC_XTALOS;
+ if (tmp == 2)
+ return BCM43xx_PCTL_CLKSRC_PCI;
+ }
+
+ return BCM43xx_PCTL_CLKSRC_XTALOS;
+}
+
/* Get max/min slowclock frequency
* as described in http://bcm-specs.sipsolutions.net/PowerControl
*/
static int bcm43xx_pctl_clockfreqlimit(struct bcm43xx_private *bcm,
int get_max)
{
- int limit = 0;
+ int limit;
+ int clocksrc;
int divisor;
- int selection;
- int err;
u32 tmp;
- struct bcm43xx_coreinfo *old_core;
- if (!(bcm->chipcommon_capabilities & BCM43xx_CAPABILITIES_PCTL))
- goto out;
- old_core = bcm->current_core;
- err = bcm43xx_switch_core(bcm, &bcm->core_chipcommon);
- if (err)
- goto out;
+ assert(bcm->chipcommon_capabilities & BCM43xx_CAPABILITIES_PCTL);
+ assert(bcm->current_core == &bcm->core_chipcommon);
+ clocksrc = bcm43xx_pctl_get_slowclksrc(bcm);
if (bcm->current_core->rev < 6) {
- if ((bcm->bustype == BCM43xx_BUSTYPE_PCMCIA) ||
- (bcm->bustype == BCM43xx_BUSTYPE_SB)) {
- selection = 1;
+ switch (clocksrc) {
+ case BCM43xx_PCTL_CLKSRC_PCI:
+ divisor = 64;
+ break;
+ case BCM43xx_PCTL_CLKSRC_XTALOS:
divisor = 32;
- } else {
- err = bcm43xx_pci_read_config32(bcm, BCM43xx_PCTL_OUT, &tmp);
- if (err) {
- printk(KERN_ERR PFX "clockfreqlimit pcicfg read failure\n");
- goto out_switchback;
- }
- if (tmp & 0x10) {
- /* PCI */
- selection = 2;
- divisor = 64;
- } else {
- /* XTAL */
- selection = 1;
- divisor = 32;
- }
+ break;
+ default:
+ assert(0);
+ divisor = 1;
}
} else if (bcm->current_core->rev < 10) {
- selection = (tmp & 0x07);
- if (selection) {
+ switch (clocksrc) {
+ case BCM43xx_PCTL_CLKSRC_LOPWROS:
+ divisor = 1;
+ break;
+ case BCM43xx_PCTL_CLKSRC_XTALOS:
+ case BCM43xx_PCTL_CLKSRC_PCI:
tmp = bcm43xx_read32(bcm, BCM43xx_CHIPCOMMON_SLOWCLKCTL);
- divisor = 4 * (1 + ((tmp & 0xFFFF0000) >> 16));
- } else
+ divisor = ((tmp & 0xFFFF0000) >> 16) + 1;
+ divisor *= 4;
+ break;
+ default:
+ assert(0);
divisor = 1;
+ }
} else {
tmp = bcm43xx_read32(bcm, BCM43xx_CHIPCOMMON_SYSCLKCTL);
- divisor = 4 * (1 + ((tmp & 0xFFFF0000) >> 16));
- selection = 1;
+ divisor = ((tmp & 0xFFFF0000) >> 16) + 1;
+ divisor *= 4;
}
-
- switch (selection) {
- case 0:
- /* LPO */
+
+ switch (clocksrc) {
+ case BCM43xx_PCTL_CLKSRC_LOPWROS:
if (get_max)
limit = 43000;
else
limit = 25000;
break;
- case 1:
- /* XTAL */
+ case BCM43xx_PCTL_CLKSRC_XTALOS:
if (get_max)
limit = 20200000;
else
limit = 19800000;
break;
- case 2:
- /* PCI */
+ case BCM43xx_PCTL_CLKSRC_PCI:
if (get_max)
limit = 34000000;
else
@@ -113,17 +137,14 @@ static int bcm43xx_pctl_clockfreqlimit(s
break;
default:
assert(0);
+ limit = 0;
}
limit /= divisor;
-out_switchback:
- err = bcm43xx_switch_core(bcm, old_core);
- assert(err == 0);
-
-out:
return limit;
}
+
/* init power control
* as described in http://bcm-specs.sipsolutions.net/PowerControl
*/
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_power.h b/drivers/net/wireless/bcm43xx/bcm43xx_power.h
index 5f63640..c966ab3 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_power.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_power.h
@@ -33,6 +33,15 @@
#include <linux/types.h>
+/* Clock sources */
+enum {
+ /* PCI clock */
+ BCM43xx_PCTL_CLKSRC_PCI,
+ /* Crystal slow clock oscillator */
+ BCM43xx_PCTL_CLKSRC_XTALOS,
+ /* Low power oscillator */
+ BCM43xx_PCTL_CLKSRC_LOPWROS,
+};
struct bcm43xx_private;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c b/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
index c44d890..b438f48 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
@@ -71,14 +71,46 @@ static int get_boolean(const char *buf,
return -EINVAL;
}
+static int sprom2hex(const u16 *sprom, char *buf, size_t buf_len)
+{
+ int i, pos = 0;
+
+ for (i = 0; i < BCM43xx_SPROM_SIZE; i++) {
+ pos += snprintf(buf + pos, buf_len - pos - 1,
+ "%04X", swab16(sprom[i]) & 0xFFFF);
+ }
+ pos += snprintf(buf + pos, buf_len - pos - 1, "\n");
+
+ return pos + 1;
+}
+
+static int hex2sprom(u16 *sprom, const char *dump, size_t len)
+{
+ char tmp[5] = { 0 };
+ int cnt = 0;
+ unsigned long parsed;
+
+ if (len < BCM43xx_SPROM_SIZE * sizeof(u16) * 2)
+ return -EINVAL;
+
+ while (cnt < BCM43xx_SPROM_SIZE) {
+ memcpy(tmp, dump, 4);
+ dump += 4;
+ parsed = simple_strtoul(tmp, NULL, 16);
+ sprom[cnt++] = swab16((u16)parsed);
+ }
+
+ return 0;
+}
+
static ssize_t bcm43xx_attr_sprom_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct bcm43xx_private *bcm = devattr_to_bcm(attr, attr_sprom);
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
u16 *sprom;
unsigned long flags;
- int i, err;
+ int err;
if (!capable(CAP_NET_ADMIN))
return -EPERM;
@@ -91,55 +123,53 @@ static ssize_t bcm43xx_attr_sprom_show(s
bcm43xx_lock_mmio(bcm, flags);
assert(bcm->initialized);
err = bcm43xx_sprom_read(bcm, sprom);
- if (!err) {
- for (i = 0; i < BCM43xx_SPROM_SIZE; i++) {
- buf[i * 2] = sprom[i] & 0x00FF;
- buf[i * 2 + 1] = (sprom[i] & 0xFF00) >> 8;
- }
- }
+ if (!err)
+ err = sprom2hex(sprom, buf, PAGE_SIZE);
bcm43xx_unlock_mmio(bcm, flags);
kfree(sprom);
- return err ? err : BCM43xx_SPROM_SIZE * sizeof(u16);
+ return err;
}
static ssize_t bcm43xx_attr_sprom_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct bcm43xx_private *bcm = devattr_to_bcm(attr, attr_sprom);
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
u16 *sprom;
unsigned long flags;
- int i, err;
+ int err;
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- if (count != BCM43xx_SPROM_SIZE * sizeof(u16))
- return -EINVAL;
sprom = kmalloc(BCM43xx_SPROM_SIZE * sizeof(*sprom),
GFP_KERNEL);
if (!sprom)
return -ENOMEM;
- for (i = 0; i < BCM43xx_SPROM_SIZE; i++) {
- sprom[i] = buf[i * 2] & 0xFF;
- sprom[i] |= ((u16)(buf[i * 2 + 1] & 0xFF)) << 8;
- }
+ err = hex2sprom(sprom, buf, count);
+ if (err)
+ goto out_kfree;
bcm43xx_lock_mmio(bcm, flags);
assert(bcm->initialized);
err = bcm43xx_sprom_write(bcm, sprom);
bcm43xx_unlock_mmio(bcm, flags);
+out_kfree:
kfree(sprom);
return err ? err : count;
}
+static DEVICE_ATTR(sprom, 0600,
+ bcm43xx_attr_sprom_show,
+ bcm43xx_attr_sprom_store);
+
static ssize_t bcm43xx_attr_interfmode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct bcm43xx_private *bcm = devattr_to_bcm(attr, attr_interfmode);
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
unsigned long flags;
int err;
ssize_t count = 0;
@@ -175,7 +205,7 @@ static ssize_t bcm43xx_attr_interfmode_s
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct bcm43xx_private *bcm = devattr_to_bcm(attr, attr_interfmode);
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
unsigned long flags;
int err;
int mode;
@@ -215,11 +245,15 @@ static ssize_t bcm43xx_attr_interfmode_s
return err ? err : count;
}
+static DEVICE_ATTR(interference, 0644,
+ bcm43xx_attr_interfmode_show,
+ bcm43xx_attr_interfmode_store);
+
static ssize_t bcm43xx_attr_preamble_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct bcm43xx_private *bcm = devattr_to_bcm(attr, attr_preamble);
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
unsigned long flags;
int err;
ssize_t count;
@@ -245,7 +279,7 @@ static ssize_t bcm43xx_attr_preamble_sto
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct bcm43xx_private *bcm = devattr_to_bcm(attr, attr_preamble);
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
unsigned long flags;
int err;
int value;
@@ -267,56 +301,41 @@ static ssize_t bcm43xx_attr_preamble_sto
return err ? err : count;
}
+static DEVICE_ATTR(shortpreamble, 0644,
+ bcm43xx_attr_preamble_show,
+ bcm43xx_attr_preamble_store);
+
int bcm43xx_sysfs_register(struct bcm43xx_private *bcm)
{
struct device *dev = &bcm->pci_dev->dev;
- struct bcm43xx_sysfs *sysfs = &bcm->sysfs;
int err;
assert(bcm->initialized);
- sysfs->attr_sprom.attr.name = "sprom";
- sysfs->attr_sprom.attr.owner = THIS_MODULE;
- sysfs->attr_sprom.attr.mode = 0600;
- sysfs->attr_sprom.show = bcm43xx_attr_sprom_show;
- sysfs->attr_sprom.store = bcm43xx_attr_sprom_store;
- err = device_create_file(dev, &sysfs->attr_sprom);
+ err = device_create_file(dev, &dev_attr_sprom);
if (err)
goto out;
-
- sysfs->attr_interfmode.attr.name = "interference";
- sysfs->attr_interfmode.attr.owner = THIS_MODULE;
- sysfs->attr_interfmode.attr.mode = 0600;
- sysfs->attr_interfmode.show = bcm43xx_attr_interfmode_show;
- sysfs->attr_interfmode.store = bcm43xx_attr_interfmode_store;
- err = device_create_file(dev, &sysfs->attr_interfmode);
+ err = device_create_file(dev, &dev_attr_interference);
if (err)
goto err_remove_sprom;
-
- sysfs->attr_preamble.attr.name = "shortpreamble";
- sysfs->attr_preamble.attr.owner = THIS_MODULE;
- sysfs->attr_preamble.attr.mode = 0600;
- sysfs->attr_preamble.show = bcm43xx_attr_preamble_show;
- sysfs->attr_preamble.store = bcm43xx_attr_preamble_store;
- err = device_create_file(dev, &sysfs->attr_preamble);
+ err = device_create_file(dev, &dev_attr_shortpreamble);
if (err)
goto err_remove_interfmode;
out:
return err;
err_remove_interfmode:
- device_remove_file(dev, &sysfs->attr_interfmode);
+ device_remove_file(dev, &dev_attr_interference);
err_remove_sprom:
- device_remove_file(dev, &sysfs->attr_sprom);
+ device_remove_file(dev, &dev_attr_sprom);
goto out;
}
void bcm43xx_sysfs_unregister(struct bcm43xx_private *bcm)
{
struct device *dev = &bcm->pci_dev->dev;
- struct bcm43xx_sysfs *sysfs = &bcm->sysfs;
- device_remove_file(dev, &sysfs->attr_preamble);
- device_remove_file(dev, &sysfs->attr_interfmode);
- device_remove_file(dev, &sysfs->attr_sprom);
+ device_remove_file(dev, &dev_attr_shortpreamble);
+ device_remove_file(dev, &dev_attr_interference);
+ device_remove_file(dev, &dev_attr_sprom);
}
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.h b/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.h
index 57f1451..cc701df 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.h
@@ -1,22 +1,6 @@
#ifndef BCM43xx_SYSFS_H_
#define BCM43xx_SYSFS_H_
-#include <linux/device.h>
-
-
-struct bcm43xx_sysfs {
- struct device_attribute attr_sprom;
- struct device_attribute attr_interfmode;
- struct device_attribute attr_preamble;
-};
-
-#define devattr_to_bcm(attr, attr_name) ({ \
- struct bcm43xx_sysfs *__s; struct bcm43xx_private *__p; \
- __s = container_of((attr), struct bcm43xx_sysfs, attr_name); \
- __p = container_of(__s, struct bcm43xx_private, sysfs); \
- __p; \
- })
-
struct bcm43xx_private;
int bcm43xx_sysfs_register(struct bcm43xx_private *bcm);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index 3daee82..3edbb48 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -962,22 +962,22 @@ static const struct iw_priv_args bcm43xx
{
.cmd = PRIV_WX_SET_SHORTPREAMBLE,
.set_args = IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1,
- .name = "set_shortpreambl",
+ .name = "set_shortpreamb",
},
{
.cmd = PRIV_WX_GET_SHORTPREAMBLE,
.get_args = IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | MAX_WX_STRING,
- .name = "get_shortpreambl",
+ .name = "get_shortpreamb",
},
{
.cmd = PRIV_WX_SET_SWENCRYPTION,
.set_args = IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1,
- .name = "set_swencryption",
+ .name = "set_swencrypt",
},
{
.cmd = PRIV_WX_GET_SWENCRYPTION,
.get_args = IW_PRIV_TYPE_CHAR | IW_PRIV_SIZE_FIXED | MAX_WX_STRING,
- .name = "get_swencryption",
+ .name = "get_swencrypt",
},
{
.cmd = PRIV_WX_SPROM_WRITE,
diff --git a/drivers/net/wireless/orinoco.c b/drivers/net/wireless/orinoco.c
index 8dfdfbd..06523e2 100644
--- a/drivers/net/wireless/orinoco.c
+++ b/drivers/net/wireless/orinoco.c
@@ -390,7 +390,7 @@ static struct iw_statistics *orinoco_get
}
} else {
struct {
- __le16 qual, signal, noise;
+ __le16 qual, signal, noise, unused;
} __attribute__ ((packed)) cq;
err = HERMES_READ_RECORD(hw, USER_BAP,
diff --git a/include/net/ieee80211softmac.h b/include/net/ieee80211softmac.h
index b971d8c..6b3693f 100644
--- a/include/net/ieee80211softmac.h
+++ b/include/net/ieee80211softmac.h
@@ -267,8 +267,9 @@ extern void ieee80211softmac_stop(struct
#define IEEE80211SOFTMAC_EVENT_AUTH_FAILED 5
#define IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT 6
#define IEEE80211SOFTMAC_EVENT_ASSOCIATE_NET_NOT_FOUND 7
+#define IEEE80211SOFTMAC_EVENT_DISASSOCIATED 8
/* keep this updated! */
-#define IEEE80211SOFTMAC_EVENT_LAST 7
+#define IEEE80211SOFTMAC_EVENT_LAST 8
/*
* If you want to be notified of certain events, you can call
* ieee80211softmac_notify[_atomic] with
diff --git a/net/core/dev.c b/net/core/dev.c
index 83231a2..3bad1af 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2698,7 +2698,8 @@ int dev_ioctl(unsigned int cmd, void __u
/* If command is `set a parameter', or
* `get the encoding parameters', check if
* the user has the right to do it */
- if (IW_IS_SET(cmd) || cmd == SIOCGIWENCODE) {
+ if (IW_IS_SET(cmd) || cmd == SIOCGIWENCODE
+ || cmd == SIOCGIWENCODEEXT) {
if (!capable(CAP_NET_ADMIN))
return -EPERM;
}
diff --git a/net/core/wireless.c b/net/core/wireless.c
index 81d6995..d2bc72d 100644
--- a/net/core/wireless.c
+++ b/net/core/wireless.c
@@ -1726,6 +1726,14 @@ int wireless_rtnetlink_get(struct net_de
if(!IW_IS_GET(request->cmd))
return -EOPNOTSUPP;
+ /* If command is `get the encoding parameters', check if
+ * the user has the right to do it */
+ if (request->cmd == SIOCGIWENCODE ||
+ request->cmd == SIOCGIWENCODEEXT) {
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ }
+
/* Special cases */
if(request->cmd == SIOCGIWSTATS)
/* Get Wireless Stats */
diff --git a/net/ieee80211/softmac/Kconfig b/net/ieee80211/softmac/Kconfig
index 6cd9f34..f2a27cc 100644
--- a/net/ieee80211/softmac/Kconfig
+++ b/net/ieee80211/softmac/Kconfig
@@ -1,6 +1,7 @@
config IEEE80211_SOFTMAC
tristate "Software MAC add-on to the IEEE 802.11 networking stack"
depends on IEEE80211 && EXPERIMENTAL
+ select WIRELESS_EXT
---help---
This option enables the hardware independent software MAC addon
for the IEEE 802.11 networking stack.
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index be61de7..4498023 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -101,6 +101,7 @@ ieee80211softmac_disassoc(struct ieee802
/* Do NOT clear bssvalid as that will break ieee80211softmac_assoc_work! */
mac->associated = 0;
mac->associnfo.associating = 0;
+ ieee80211softmac_call_events_locked(mac, IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
spin_unlock_irqrestore(&mac->lock, flags);
}
@@ -373,6 +374,7 @@ ieee80211softmac_handle_disassoc(struct
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.bssvalid = 0;
mac->associated = 0;
+ ieee80211softmac_call_events_locked(mac, IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
schedule_work(&mac->associnfo.work);
spin_unlock_irqrestore(&mac->lock, flags);
@@ -391,6 +393,7 @@ ieee80211softmac_handle_reassoc_req(stru
dprintkl(KERN_INFO PFX "reassoc request from unknown network\n");
return 0;
}
- ieee80211softmac_assoc(mac, network);
+ schedule_work(&mac->associnfo.work);
+
return 0;
}
diff --git a/net/ieee80211/softmac/ieee80211softmac_event.c b/net/ieee80211/softmac/ieee80211softmac_event.c
index 0a52bbd..8cc8f3f 100644
--- a/net/ieee80211/softmac/ieee80211softmac_event.c
+++ b/net/ieee80211/softmac/ieee80211softmac_event.c
@@ -67,6 +67,7 @@ static char *event_descriptions[IEEE8021
"authenticating failed",
"authenticating timed out",
"associating failed because no suitable network was found",
+ "disassociated",
};
@@ -128,13 +129,42 @@ void
ieee80211softmac_call_events_locked(struct ieee80211softmac_device *mac, int event, void *event_ctx)
{
struct ieee80211softmac_event *eventptr, *tmp;
- union iwreq_data wrqu;
- char *msg;
+ struct ieee80211softmac_network *network;
if (event >= 0) {
- msg = event_descriptions[event];
- wrqu.data.length = strlen(msg);
- wireless_send_event(mac->dev, IWEVCUSTOM, &wrqu, msg);
+ union iwreq_data wrqu;
+ int we_event;
+ char *msg = NULL;
+
+ switch(event) {
+ case IEEE80211SOFTMAC_EVENT_ASSOCIATED:
+ network = (struct ieee80211softmac_network *)event_ctx;
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ memcpy(wrqu.ap_addr.sa_data, &network->bssid[0], ETH_ALEN);
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ we_event = SIOCGIWAP;
+ break;
+ case IEEE80211SOFTMAC_EVENT_DISASSOCIATED:
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ memset(&wrqu, '\0', sizeof (union iwreq_data));
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ we_event = SIOCGIWAP;
+ break;
+ case IEEE80211SOFTMAC_EVENT_SCAN_FINISHED:
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ memset(&wrqu, '\0', sizeof (union iwreq_data));
+ we_event = SIOCGIWSCAN;
+ break;
+ default:
+ msg = event_descriptions[event];
+ wrqu.data.length = strlen(msg);
+ we_event = IWEVCUSTOM;
+ break;
+ }
+ wireless_send_event(mac->dev, we_event, &wrqu, msg);
}
if (!list_empty(&mac->events))
diff --git a/net/ieee80211/softmac/ieee80211softmac_io.c b/net/ieee80211/softmac/ieee80211softmac_io.c
index febc51d..cc6cd56 100644
--- a/net/ieee80211/softmac/ieee80211softmac_io.c
+++ b/net/ieee80211/softmac/ieee80211softmac_io.c
@@ -180,9 +180,21 @@ ieee80211softmac_assoc_req(struct ieee80
ieee80211softmac_hdr_3addr(mac, &((*pkt)->header), IEEE80211_STYPE_ASSOC_REQ, net->bssid, net->bssid);
/* Fill in capability Info */
- (*pkt)->capability = (mac->ieee->iw_mode == IW_MODE_MASTER) || (mac->ieee->iw_mode == IW_MODE_INFRA) ?
- cpu_to_le16(WLAN_CAPABILITY_ESS) :
- cpu_to_le16(WLAN_CAPABILITY_IBSS);
+ switch (mac->ieee->iw_mode) {
+ case IW_MODE_INFRA:
+ (*pkt)->capability = cpu_to_le16(WLAN_CAPABILITY_ESS);
+ break;
+ case IW_MODE_ADHOC:
+ (*pkt)->capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
+ break;
+ case IW_MODE_AUTO:
+ (*pkt)->capability = net->capabilities & (WLAN_CAPABILITY_ESS|WLAN_CAPABILITY_IBSS);
+ break;
+ default:
+ /* bleh. we don't ever go to these modes */
+ printk(KERN_ERR PFX "invalid iw_mode!\n");
+ break;
+ }
/* Need to add this
(*pkt)->capability |= mac->ieee->short_slot ?
cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT_TIME) : 0;
diff --git a/net/ieee80211/softmac/ieee80211softmac_scan.c b/net/ieee80211/softmac/ieee80211softmac_scan.c
index bb9ab8b..2b9e7ed 100644
--- a/net/ieee80211/softmac/ieee80211softmac_scan.c
+++ b/net/ieee80211/softmac/ieee80211softmac_scan.c
@@ -47,6 +47,7 @@ ieee80211softmac_start_scan(struct ieee8
sm->scanning = 1;
spin_unlock_irqrestore(&sm->lock, flags);
+ netif_tx_disable(sm->ieee->dev);
ret = sm->start_scan(sm->dev);
if (ret) {
spin_lock_irqsave(&sm->lock, flags);
@@ -239,6 +240,7 @@ void ieee80211softmac_scan_finished(stru
if (net)
sm->set_channel(sm->dev, net->channel);
}
+ netif_wake_queue(sm->ieee->dev);
ieee80211softmac_call_events(sm, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, NULL);
}
EXPORT_SYMBOL_GPL(ieee80211softmac_scan_finished);
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index b559aa9..00f0d4f 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -41,13 +41,23 @@ ieee80211softmac_wx_trigger_scan(struct
EXPORT_SYMBOL_GPL(ieee80211softmac_wx_trigger_scan);
+/* if we're still scanning, return -EAGAIN so that userspace tools
+ * can get the complete scan results, otherwise return 0. */
int
ieee80211softmac_wx_get_scan_results(struct net_device *net_dev,
struct iw_request_info *info,
union iwreq_data *data,
char *extra)
{
+ unsigned long flags;
struct ieee80211softmac_device *sm = ieee80211_priv(net_dev);
+
+ spin_lock_irqsave(&sm->lock, flags);
+ if (sm->scanning) {
+ spin_unlock_irqrestore(&sm->lock, flags);
+ return -EAGAIN;
+ }
+ spin_unlock_irqrestore(&sm->lock, flags);
return ieee80211_wx_get_scan(sm->ieee, info, data, extra);
}
EXPORT_SYMBOL_GPL(ieee80211softmac_wx_get_scan_results);
^ permalink raw reply related
* [PATCH] bridge: allow full size vlan tagged packets to be bridged
From: Stephen Hemminger @ 2006-04-20 21:44 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, bridge
The Ethernet bridge code silently drops packets when forwarding a packet
that is too large for the destination interface (as per 802.1d). But it
should allow for VLAN tagged frames.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- bridge.orig/net/bridge/br_forward.c 2006-04-10 16:17:51.000000000 -0700
+++ bridge/net/bridge/br_forward.c 2006-04-19 13:50:42.000000000 -0700
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
#include <linux/skbuff.h>
+#include <linux/if_vlan.h>
#include <linux/netfilter_bridge.h>
#include "br_private.h"
@@ -29,10 +30,15 @@
return 1;
}
+static inline unsigned packet_length(const struct sk_buff *skb)
+{
+ return skb->len - (skb->protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
+}
+
int br_dev_queue_push_xmit(struct sk_buff *skb)
{
/* drop mtu oversized packets except tso */
- if (skb->len > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
+ if (packet_length(skb) > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
kfree_skb(skb);
else {
#ifdef CONFIG_BRIDGE_NETFILTER
^ permalink raw reply
* Re: [PATCH 9/10] [IOAT] Add sysctl to tuning IOAT offloaded IO threshold
From: Olof Johansson @ 2006-04-20 21:16 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev
In-Reply-To: <Pine.LNX.4.44.0604201341530.22544-100000@isotope.jf.intel.com>
Hi,
On Thu, Apr 20, 2006 at 01:50:40PM -0700, Andrew Grover wrote:
>
> Any socket recv of less than this ammount will not be offloaded
[...]
> --- a/net/core/user_dma.c
> +++ b/net/core/user_dma.c
> @@ -33,6 +33,10 @@
>
> #ifdef CONFIG_NET_DMA
>
> +#define NET_DMA_DEFAULT_COPYBREAK 1024
> +
> +int sysctl_tcp_dma_copybreak = NET_DMA_DEFAULT_COPYBREAK;
> +
The breakpoint is highly likely to be at different points on various
architectures and platforms depending on what they look like, where in
the system the DMA engine is, how efficient regular memcpy is, etc.
I would like to see it as a config option instead, so it will at least
be possible to tune per-arch (via default config, etc).
-Olof
^ permalink raw reply
* Re: [PATCH 0/10] [IOAT] I/OAT patches repost
From: Olof Johansson @ 2006-04-20 21:33 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev
In-Reply-To: <Pine.LNX.4.44.0604201329300.22544-100000@isotope.jf.intel.com>
On Thu, Apr 20, 2006 at 01:49:16PM -0700, Andrew Grover wrote:
> Hi I'm reposting these, originally posted by Chris Leech a few weeks ago.
> However, there is an extra part since I broke up one patch that was too
> big for netdev last time into two (patches 2 and 3).
>
> Of course we're always looking for more style improvement comments, but
> more importantly we're posting these to talk about the larger issues
> around I/OAT and this code making it in upstream at some point.
>
> These are also available on the wiki,
> http://linux-net.osdl.org/index.php/I/OAT .
Hi,
Since you didn't provide the current issues in this email, I will copy
and paste them from the wiki page.
I guess the overall question is, how much of this needs to be addressed
in the implementation before merge, and how much should be done when
more drivers (with more features) are merged down the road. It might not
make sense to implement all of it now if the only available public
driver lacks the abilities. But I'm bringing up the points anyway.
Maybe it could make sense to add a software-based driver for reference,
and for others to play around with.
I would also prefer to see the series clearly split between the DMA
framework and first clients (networking) and the I/OAT driver. Right now
"I/OAT" and "DMA" is used interchangeably, especially when describing
the later patches. It might help you in the perception that this is
something unique to the Intel chipsets as well. :-)
(I have also proposed DMA offload discussions as a topic for the Kernel
Summit. I have kept Chris Leech Cc:d on most of the emails in question. It
should be a good place to get input from other subsystems regarding what
functionality they would like to see provided, etc.)
>From the wiki:
> Current issues of concern:
>
> 1. Performance improvement may be on too narrow a set of workloads
Maybe from I/OAT and the current client, but the introduction of the
DMA infrastructure opens up for other uses that are not yet possible in
the API. For example, DMA with functions is a very natural extension,
and something that's very common on various platforms (XOR for RAID use,
checksums, encryption).
The API needs to be expanded to cover this by adding function types and
adding them to the channel allocation interface and logic.
> 2. Limited availability of hardware supporting I/OAT
DMA engines are fairly common, even though I/OAT might not be yet. They
just haven't had a common infrastructure until now.
For people who might want to play with it, a reference software-based
implementation might be useful.
> 3. Data copied by I/OAT is not cached
This is a I/OAT device limitation and not a global statement of the
DMA infrastructure. Other platforms might be able to prime caches
with the DMA traffic. Hint flags should be added on either the channel
allocation calls, or per-operation calls, depending on where it makes
sense driver/client wise.
> 4. Intrusiveness of net stack modifications
> 5. Compatibility with upcoming VJ net channel architecture
Both of these are outside my scope, so I won't comment on them at this
time.
I would like to add, for longer term:
* Userspace interfaces:
Are there any plans yet on how to export some of this to userspace? It
might not make full sense for just memcpy due to overheads, but it makes
sense for more advanced dma/offload engines.
-Olof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox