* Re: [net-next 05/11] netdev: FCoE: Add new ndo_get_fcoe_hbainfo() call
From: David Miller @ 2012-01-03 20:07 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: Neerav.Parikh, netdev, gospo, sassmann
In-Reply-To: <1325618356-2655-6-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 3 Jan 2012 11:19:10 -0800
> + int (*ndo_fcoe_get_hbainfo)(struct net_device *dev,
> + struct netdev_fcoe_hbainfo *hbainfo);
Please line up the second line's argument correctly, it should be:
> + int (*ndo_fcoe_get_hbainfo)(struct net_device *dev,
> + struct netdev_fcoe_hbainfo *hbainfo);
Thanks.
^ permalink raw reply
* Re: [net-next 07/11] e1000e: cleanup Rx checksum offload code
From: David Miller @ 2012-01-03 20:08 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: bruce.w.allan, netdev, gospo, sassmann
In-Reply-To: <1325618356-2655-8-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 3 Jan 2012 11:19:12 -0800
> - __sum16 sum = (__force __sum16)htons(csum);
> + __sum16 sum = (__force __sum16)htons(le16_to_cpu(csum));
Looks like a NOP. It's essentially "cpu_to_le16(le16_to_cpu(csum)" as
far as I can tell.
^ permalink raw reply
* Re: [net-next 08/11] e1000e: add Receive Packet Steering (RPS) support
From: David Miller @ 2012-01-03 20:09 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: bruce.w.allan, netdev, gospo, sassmann
In-Reply-To: <1325618356-2655-9-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 3 Jan 2012 11:19:13 -0800
> + e_err("Enabling both receive checksum offload and receive hashing is not possible with jumbo frames. Disable jumbos or enable only one of the receive offload features.\n");
Please split this up into multiple lines like this:
e_err("..."
"..."
"...");
Thanks.
^ permalink raw reply
* Re: Why is gre0 auto-created, and can we fix it?
From: David Miller @ 2012-01-03 20:11 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <4F035F2C.1000003@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Tue, 03 Jan 2012 12:03:56 -0800
> On 01/03/2012 11:59 AM, David Miller wrote:
>> From: Ben Greear<greearb@candelatech.com>
>> Date: Tue, 03 Jan 2012 11:49:50 -0800
>>
>>> As far as I can tell, no other interfaces are auto-created
>>> in this manner.
>>
>> ip6tnl0 and sit0 do it too, just grep for alloc_netdev() under
>> net/{ipv4,ipv6}/
>
> So, no changing the behaviour?
Probably too risky. I think the exposure is on the order of ~16
years.
^ permalink raw reply
* Re: [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0
From: Bart De Schuymer @ 2012-01-03 20:15 UTC (permalink / raw)
To: Richard Weinberger
Cc: Stephen Hemminger, davem, bridge, netdev, linux-kernel,
netfilter-devel
In-Reply-To: <4F033E11.5060707@nod.at>
Op 3/01/2012 18:42, Richard Weinberger schreef:
> Am 03.01.2012 17:15, schrieb Stephen Hemminger:
>> On Tue, 3 Jan 2012 14:26:04 +0100
>> Richard Weinberger<richard@nod.at> wrote:
>>
>>> If net.bridge.bridge-nf-call-iptables or net.bridge.bridge-nf-call-ip6tables
>>> are set to zero xt_physdev has no effect because skb->nf_bridge has not been set up.
>>>
>>> Signed-off-by: Richard Weinberger<richard@nod.at>
>> I am not sure if this is a valid configuration. The setting of sysctl is saying
>> "don't do iptables on bridge (since I won't be using it)" and then you are later
>> doing iptables and expecting the settings as if the iptables setup was being
>> done.
> I don't think so.
>
> Also rules like this one are broken:
> iptables -A INPUT -i bridge0 -m physdev --physdev-in eth0 -j ...
>
> No firewalling is done on the bridge, xt_physdev is only using some meta
> information.
>
> At least a big fat warning would be nice that xt_physdev does not work
> if bridge-nf-call-iptables=0.
> It took me some time to figure out why my firewall rule set gone nuts on
> RHEL6...
The documentation is probably not explicit enough, but I would keep the
behavior as it is now. Setting bridge-nf-call-iptables to 0 makes
iptables behave as if bridge-netfilter was not enabled at compilation.
Anyway, your patch is almost certainly flawed since the fact that
skb->nf_bridge can be NULL is used as part of the logic in
br_netfilter.c: it indicates that bridge-nf-call-iptables was 0 when the
packet was first processed by bridge-netfilter and should therefore not
be given to iptables in any other netfilter hook.
cheers,
Bart
--
Bart De Schuymer
www.artinalgorithms.be
^ permalink raw reply
* Re: [PATCH RFC] IPv6: RTM_GETROUTE NLM_F_MATCH handled as stated in RFC 3549
From: David Miller @ 2012-01-03 20:16 UTC (permalink / raw)
To: matti.vaittinen; +Cc: netdev
In-Reply-To: <1325080915.26559.43.camel@hakki>
From: Matti Vaittinen <matti.vaittinen@nsn.com>
Date: Wed, 28 Dec 2011 16:01:55 +0200
> This patch makes ipv6 module to return only routes which match
> attributes / filled fields in RTM_GETROUTE, if NLM_F_MATCH is
> specified and NLM_F_ROOT is not. This patch has not been tested,
> and is meant more to be for visualization of what I thought of doing.
> If the NLM_F_MATCH support is considered to be good idea, then I
> will check this more thoroughly and send another patch.
>
> I assume this would not break *many* existing userspace applications,
> since specifying NLM_F_MATCH (especially with no NLM_F_ROOT) sounds
> pretty stupid - if no entries should be filtered.
>
> I checked iproute2, and it uses NLM_F_DUMP and does filtering entries
> in userspace - thus it is not affected.
>
> I guess this same idea could be brought in RTM_GETADDR and RTM_GETLINK
> too? Maybe also on IPv4 side?
The problem is that you can't avoid writing the user level filters
even if we add this behavior now.
Any tool which wants to work on every single Linux system out there
right now has to accomodate the case where NLM_F_MATCH isn't done by
the kernel. It will take several years before this would be widely
deployed even if it went in right now.
This means applications are not simplified at all, in fact they become
more complex, since they have to accomodate not just one but two
possible cases.
Specifying this behavior in RFC 3549 is pretty pointless, given the
existing situation.
So the value proposition of adding this change doesn't add up to me.
I'm therefore not inclined to apply a patch like this, sorry. And even
if I was, I'd ask that ipv4 get it first or at the same time.
^ permalink raw reply
* RE: [net-next 08/11] e1000e: add Receive Packet Steering (RPS) support
From: Allan, Bruce W @ 2012-01-03 20:16 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20120103.150936.572765552893657192.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Tuesday, January 03, 2012 12:10 PM
>To: Kirsher, Jeffrey T
>Cc: Allan, Bruce W; netdev@vger.kernel.org; gospo@redhat.com;
>sassmann@redhat.com
>Subject: Re: [net-next 08/11] e1000e: add Receive Packet Steering (RPS) support
>
>From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>Date: Tue, 3 Jan 2012 11:19:13 -0800
>
>> + e_err("Enabling both receive checksum offload and receive hashing is
>not possible with jumbo frames. Disable jumbos or enable only one of the
>receive offload features.\n");
>
>Please split this up into multiple lines like this:
>
> e_err("..."
> "..."
> "...");
>
>Thanks.
I was under the impression from recently accepted patches that the preferred
method for log/error message strings was to keep them as a single string
(rather than broken across multiple lines) for easy searching. Is that not
the case here?
>From ./Documentation/CodingStyle..."never break user-visible strings such as
printk messages, because that breaks the ability to grep for them."
Do you still want this change?
Thanks,
Bruce.
^ permalink raw reply
* RE: [net-next 07/11] e1000e: cleanup Rx checksum offload code
From: Allan, Bruce W @ 2012-01-03 20:17 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20120103.150842.1516759599032629705.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Tuesday, January 03, 2012 12:09 PM
>To: Kirsher, Jeffrey T
>Cc: Allan, Bruce W; netdev@vger.kernel.org; gospo@redhat.com;
>sassmann@redhat.com
>Subject: Re: [net-next 07/11] e1000e: cleanup Rx checksum offload code
>
>From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>Date: Tue, 3 Jan 2012 11:19:12 -0800
>
>> - __sum16 sum = (__force __sum16)htons(csum);
>> + __sum16 sum = (__force __sum16)htons(le16_to_cpu(csum));
>
>Looks like a NOP. It's essentially "cpu_to_le16(le16_to_cpu(csum)" as
>far as I can tell.
OK, I'll look into fixing this.
Thanks,
Bruce.
^ permalink raw reply
* Re: [net-next 08/11] e1000e: add Receive Packet Steering (RPS) support
From: David Miller @ 2012-01-03 20:27 UTC (permalink / raw)
To: bruce.w.allan; +Cc: jeffrey.t.kirsher, netdev, gospo, sassmann
In-Reply-To: <804857E1F29AAC47BF68C404FC60A1840292A5@ORSMSX102.amr.corp.intel.com>
From: "Allan, Bruce W" <bruce.w.allan@intel.com>
Date: Tue, 3 Jan 2012 20:16:44 +0000
> I was under the impression from recently accepted patches that the preferred
> method for log/error message strings was to keep them as a single string
> (rather than broken across multiple lines) for easy searching. Is that not
> the case here?
>
>>From ./Documentation/CodingStyle..."never break user-visible strings such as
> printk messages, because that breaks the ability to grep for them."
>
> Do you still want this change?
Fair enough, I rescind my request and this patch is fine as-is.
^ permalink raw reply
* RE: [net-next 08/11] e1000e: add Receive Packet Steering (RPS) support
From: Allan, Bruce W @ 2012-01-03 20:28 UTC (permalink / raw)
To: David Miller
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <20120103.152739.1456113375065412910.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Tuesday, January 03, 2012 12:28 PM
>To: Allan, Bruce W
>Cc: Kirsher, Jeffrey T; netdev@vger.kernel.org; gospo@redhat.com;
>sassmann@redhat.com
>Subject: Re: [net-next 08/11] e1000e: add Receive Packet Steering (RPS) support
>
>From: "Allan, Bruce W" <bruce.w.allan@intel.com>
>Date: Tue, 3 Jan 2012 20:16:44 +0000
>
>> I was under the impression from recently accepted patches that the preferred
>> method for log/error message strings was to keep them as a single string
>> (rather than broken across multiple lines) for easy searching. Is that not
>> the case here?
>>
>>>From ./Documentation/CodingStyle..."never break user-visible strings such as
>> printk messages, because that breaks the ability to grep for them."
>>
>> Do you still want this change?
>
>Fair enough, I rescind my request and this patch is fine as-is.
Okay, thanks Dave.
Bruce.
^ permalink raw reply
* Re: [PATCH] netfilter: Fix br_nf_pre_routing() in conjunction with bridge-nf-call-ip(6)tables=0
From: Richard Weinberger @ 2012-01-03 20:29 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Stephen Hemminger, davem, bridge, netdev, linux-kernel,
netfilter-devel
In-Reply-To: <4F0361D7.3000602@pandora.be>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
Am 03.01.2012 21:15, schrieb Bart De Schuymer:
> The documentation is probably not explicit enough, but I would keep the
> behavior as it is now. Setting bridge-nf-call-iptables to 0 makes
> iptables behave as if bridge-netfilter was not enabled at compilation.
> Anyway, your patch is almost certainly flawed since the fact that
> skb->nf_bridge can be NULL is used as part of the logic in
> br_netfilter.c: it indicates that bridge-nf-call-iptables was 0 when the
> packet was first processed by bridge-netfilter and should therefore not
> be given to iptables in any other netfilter hook.
Thanks for the explanation!
Wouldn't it make sense to check for bridge-nf-call-iptables in xt_physdev?
So that the user gets warned that his iptables rule will never match...
Thanks,
//richard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: APIC seems not working under high network load
From: Eric Dumazet @ 2012-01-03 20:30 UTC (permalink / raw)
To: Jia Rao; +Cc: linux-kernel, netdev
In-Reply-To: <CAA8E7hFwvhATa+LAsW4csnUh1gL-tFZVQMO7LN0iQBa6NFj3KQ@mail.gmail.com>
Le mardi 03 janvier 2012 à 14:28 -0500, Jia Rao a écrit :
> Hi all,
>
> I had scalability issues when running memcached-like workloads in a
> Intel 8-core system. It turned out that under high network load only
> one core handled the interrupts from NIC. In the output of mpstat, one
> of the core was overloaded with 100% %soft time. I tried to echo
> different core ids to /proc/irq/irq#/smp_affinity, it did not take
> effect until I stopped the incoming network traffic. It seems that
> APIC is not distributing interrupts to different cores.
>
> The below are the details of the testing system:
> OS: Linux 3.1.4 X86_64
> CPU: Intel L5450, quad-core
> NIC: Intel e1000e
If network load is high enough, cpu handling network IRQ stay in softirq
mode (NAPI) and never re-arms interrupt, so no other cpu can handle the
load.
This is why its better to change /proc/irq/irq#/smp_affinity _before_
load starts.
With your kernel, one way to help this cpu exit from softirq is using
RPS (Receive Packet Steering), since packets will be spreaded on several
cpus. Then, later hardware IRQ might be spreaded on other cpus as well.
for n in `seq 0 7`
do
echo ff >/sys/class/net/eth0/queues/rx-$n/rps_cpus
done
[ If your eth0 has 8 queues ]
^ permalink raw reply
* Re: [PATCH net-next v2] net_sched: qdisc_alloc_handle() can be too slow
From: Eric Dumazet @ 2012-01-03 20:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, dave.taht
In-Reply-To: <20120103.130353.716810185692904362.davem@davemloft.net>
Le mardi 03 janvier 2012 à 13:03 -0500, David Miller a écrit :
> Applied, thanks Eric. I always cringed when I looked at this function :)
>
Yep :(
I'll add an IDR (and not a btree as I stated earlier) to get O(1)
allocations and qdisc_lookup(), it should help to optimize
qdisc_tree_decrease_qlen() [ Slow as hell for complex qdisc setups ]
^ permalink raw reply
* Re: [PATCH, v2] Xen: consolidate and simplify struct xenbus_driver instantiation
From: Konrad Rzeszutek Wilk @ 2012-01-03 20:36 UTC (permalink / raw)
To: Ian Campbell
Cc: Ben Hutchings, Jan Beulich, Konrad Rzeszutek Wilk,
davem@davemloft.net, dmitry.torokhov@gmail.com,
FlorianSchandinat@gmx.de, Jeremy Fitzhardinge, Jens Axboe,
xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <1324586301.13113.3.camel@dagon.hellion.org.uk>
On Thu, Dec 22, 2011 at 08:38:21PM +0000, Ian Campbell wrote:
> On Thu, 2011-12-22 at 14:44 +0000, Ben Hutchings wrote:
> > On Thu, 2011-12-22 at 11:57 +0000, Ian Campbell wrote:
> > > On Thu, 2011-12-22 at 11:51 +0000, Jan Beulich wrote:
> > > > >>> On 22.12.11 at 10:57, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > > On Thu, 2011-12-22 at 09:08 +0000, Jan Beulich wrote:
> > > > >> The 'name', 'owner', and 'mod_name' members are redundant with the
> > > > >> identically named fields in the 'driver' sub-structure. Rather than
> > > > >> switching each instance to specify these fields explicitly, introduce
> > > > >> a macro to simplify this.
> > > > >>
> > > > >> Eliminate further redundancy by allowing the drvname argument to
> > > > >> DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
> > > > >> the ID table will be used for .driver.name).
> > > > >
> > > > > Any reason not to always use DRV_NAME here (which is generally a bit
> > > > > more specific e.g. "xen-foofront" rather than "foo") and rely on the id
> > > > > table for the shorter names used in xenstore?
> > > >
> > > > That would imply that DRV_NAME is always defined, but I don't
> > > > see this being the case.
> > >
> > > My mistake, I thought it was a Kbuild thing.
> >
> > You're maybe thinking of KBUILD_MODNAME.
>
> Yes, I think I was.
Ian, are you OK with this patch? I think Jan needs to repost once more with the
"pciback" -> DRV_NAME change and then it is OK?
I've tested it with all backends, except the pciback one, and I see no regressions
with 'xl' or 'xm' toolstack.
^ permalink raw reply
* Re: APIC seems not working under high network load
From: Jia Rao @ 2012-01-03 20:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1325622628.2611.8.camel@edumazet-laptop>
> With your kernel, one way to help this cpu exit from softirq is using
> RPS (Receive Packet Steering), since packets will be spreaded on several
> cpus. Then, later hardware IRQ might be spreaded on other cpus as well.
>
> for n in `seq 0 7`
> do
> echo ff >/sys/class/net/eth0/queues/rx-$n/rps_cpus
> done
It seems that my NIC only have one queue: rx-0. Is there a work around
for this ?
As for the softirq, is it possible migrating the softirq to other
cores through CPU load balancing ?
Thanks !
^ permalink raw reply
* Re: pull request: wireless 2011-12-15
From: Greg KH @ 2012-01-03 20:52 UTC (permalink / raw)
To: Rafał Miłecki
Cc: John W. Linville, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <CACna6rxO2dC=Y3nv-d-w89MqyM0j0aumk=r5Yh_KEg=MwOcvEQ@mail.gmail.com>
On Mon, Dec 26, 2011 at 12:36:59AM +0100, Rafał Miłecki wrote:
> W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki
> <zajec5@gmail.com> napisał:
> > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville
> > <linville@tuxdriver.com> napisał:
> >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
> >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>:
> >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
> >>> >
> >>> > Dave,
> >>> >
> >>> > Here are a few more fixes intended for the 3.2 release. They are
> >>> > all small and narrowly focused.
> >>>
> >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
> >>> clean my patch is fix. Could you take a look at
> >>> [PATCH] bcma: support for suspend and resume
> >>> please?
> >>>
> >>> It's not one-liner, but fixes lock ups, which I believe - we really
> >>> want to avoid.
> >>
> >> It's late in the release cycle, and Dave specifically asked me to slow down.
> >>
> >> Are these suspend/resume lockups a regression? Or have they always
> >> been there? Do they happen to everyone?
> >
> > The bug is present since first days of bcma. That's why I even decided
> > to add stable to CC.
> >
> > Personally I've tested that only on 1 machine (I don't have more
> > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2
> > users have to remove b43 & bcma before suspending [0], they complain
> > about that since ever.
> >
> > Arend: I know you're also complaining for suspend in bcma. Can you
> > comment on this?
> >
> > [0] http://ubuntuforums.org/showthread.php?t=1695746
>
> User nephyrin on #bcm-users has confirmed this patch fixes
> suspend&resume for him. Without this patch he got deadlock without
> seeing any kernel panic logs - quite an ugly case.
>
> I still think this patch may be worth taking as fix and backporting too.
What patch specifically? What is the git commit id of it in Linus's
tree? Without that information, telling stable@ about it is
pointless...
greg k-h
^ permalink raw reply
* RE: [net-next 05/11] netdev: FCoE: Add new ndo_get_fcoe_hbainfo() call
From: Parikh, Neerav @ 2012-01-03 20:53 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20120103.150742.289215241240567940.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, January 03, 2012 12:08 PM
> To: Kirsher, Jeffrey T
> Cc: Parikh, Neerav; netdev@vger.kernel.org; gospo@redhat.com;
> sassmann@redhat.com
> Subject: Re: [net-next 05/11] netdev: FCoE: Add new
> ndo_get_fcoe_hbainfo() call
>
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 3 Jan 2012 11:19:10 -0800
>
> > + int (*ndo_fcoe_get_hbainfo)(struct net_device *dev,
> > + struct netdev_fcoe_hbainfo *hbainfo);
>
> Please line up the second line's argument correctly, it should be:
>
I was just trying to make checkpatch.pl happy as the line went beyond
80 character limit.
> > + int (*ndo_fcoe_get_hbainfo)(struct net_device *dev,
> > + struct netdev_fcoe_hbainfo
> *hbainfo);
>
> Thanks.
^ permalink raw reply
* Re: [net-next 07/11] e1000e: cleanup Rx checksum offload code
From: Ben Hutchings @ 2012-01-03 21:00 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, bruce.w.allan, netdev, gospo, sassmann
In-Reply-To: <20120103.150842.1516759599032629705.davem@davemloft.net>
On Tue, 2012-01-03 at 15:08 -0500, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 3 Jan 2012 11:19:12 -0800
>
> > - __sum16 sum = (__force __sum16)htons(csum);
> > + __sum16 sum = (__force __sum16)htons(le16_to_cpu(csum));
>
> Looks like a NOP. It's essentially "cpu_to_le16(le16_to_cpu(csum)" as
> far as I can tell.
Looks like a swab() to me...
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next 08/11] e1000e: add Receive Packet Steering (RPS) support
From: Ben Hutchings @ 2012-01-03 21:05 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann
In-Reply-To: <1325618356-2655-9-git-send-email-jeffrey.t.kirsher@intel.com>
On Tue, 2012-01-03 at 11:19 -0800, Jeff Kirsher wrote:
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Enable RPS by default. Disallow jumbo frames when both receive checksum
> and receive hashing are enabled because the hardware cannot do both IP
> payload checksum (enabled when receive checksum is enabled when using
> packet split which is used for jumbo frames) and provide RSS hash at the
> same time.
[...]
This doesn't seem to have much to do with RPS. RPS can use a hardware
hash but doesn't require it.
You should also implement the ethtool command to query flow hashing
behaviour (ETHTOOL_GRXFH command, get_rxnfc operation).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* pull request: wireless-next 2011-01-03
From: John W. Linville @ 2012-01-03 21:09 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 26920 bytes --]
commit 57adc1fcbae2c13104ce291b40f23e40a414fa87
Dave,
I had planned to send a pull request before Christmas, but apparently
I forgot. So, I reckon this batch of updates got a little extra
testing in linux-next over the past week or so. :-)
This one is kinda big, with pulls from the ath6kl, bluetooth, iwlwifi,
and wl12xx trees. The brcm80211 team showed a lot of activity,
and both the mwifies and the b43 guys made good showings as well.
A couple of NFC updates and a handful of other bits round things out.
Please let me know if there are problems!
John
---
The following changes since commit faa85aa24286a9e14ae7cc797352350c3ac39986:
skge: fix warning when CONFIG_PM is defined but not CONFIG_PM_SLEEP (2012-01-03 13:53:16 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
Aarthi Thiruvengadam (2):
ath6kl: Fix target minimum length requirement for WMI_SEND_PROBE_RESPONSE_CMDID
ath6kl: support for P2P mgmt operations on station interface
Alan Cox (1):
rt2800: Add support for the Fujitsu Stylistic Q550
Amitkumar Karwar (4):
mwifiex: cleanup work in scan.c
mwifiex: remove redundant band config code
mwifiex: use IEEE80211_HT_PARAM_CHA_SEC_* macros
mwifiex: fix issues in band configuration code
Andrei Emeltchenko (7):
Bluetooth: Add HCI Read Data Block Size function
Bluetooth: Simplify num_comp_pkts_evt function
Bluetooth: Split ctrl init to BREDR and AMP parts
Bluetooth: Initialize default flow control mode
Bluetooth: Check for flow control mode
Bluetooth: Clean up magic pointers
Bluetooth: Remove magic numbers from le scan cmd
Andres Salomon (1):
libertas: clean up scan thread handling
Arik Nemtsov (1):
ath6kl: indicate probe-resp offload support
Bing Zhao (1):
Bluetooth: btusb: fix bInterval for high/super speed isochronous endpoints
Brian Gix (2):
Bluetooth: Add MITM mechanism to LE-SMP
Bluetooth: Add SMP to User Passkey and Confirm
Dai Shuibing (3):
ath6kl: Add support for configuring SMS4 keys
ath6kl: Allow SMS4 to be configured in AP mode
ath6kl: Indicate WAPI IE from (Re)Association Request frame
Dan Carpenter (4):
ath6kl: unlock if ath6kl_cfg80211_connect() fails
ath6kl: use a larger buffer for debug output
NFC: double unlock in nfc_llcp_recv_connect()
NFC: use kfree_skb() for sk_buffs
Don Fry (4):
iwlwifi: move iwl_cfg from iwl_priv to iwl_shared
iwlwifi: Add official names for new devices
iwlwifi: create iwl_mac80211 unregister routine
iwlwifi: remove most of the iwl_priv references from iwl-ucode.c
Eliad Peller (7):
wl12xx: implement change_interface
wl12xx: remove redundant code from wl1271_op_conf_tx
wl12xx: make WL1271_FLAG_IDLE flag per-vif
wl12xx: flush packets before stopping dev role
wl12xx: fix checking of started dev role
wl12xx: stop device role on remove_interface
wl12xx: check the actual vif operstate in wl1271_dev_notify
Emmanuel Grumbach (17):
iwlwifi: fix endianity issue in debug prints
iwlwifi: don't count the tfds in HW queue any more
iwlwifi: we can wake SW queues even when draining HW queues
iwlwifi: don't rely on the wr / rd pointers in DELBA flow
iwlwifi: tid_data logic move to upper layer - tx AGG stop
iwlwifi: tid_data logic move to upper layer - tx AGG alloc
iwlwifi: tid_data logic move to upper layer - tx AGG setup
iwlwifi: tid_data logic move to upper layer - check_empty
iwlwifi: tid_data logic move to upper layer - txqid
iwlwifi: tid_data logic move to upper layer - seq_number
iwlwifi: transport layer shouldn't access the AGG SM
iwlwifi: tid_data moves to iwl_priv
iwlwifi: reset the tid_data when a station is removed
iwlwifi: add debug in Tx path in AGG flow
iwlwifi: kill iwl_{start,stop}_tx_ba_trans_ready
iwlwifi: don't accept Tx packets when draining HW queues
iwlwifi: add missing documentation for iwl_shared
Eyal Shapira (2):
wl12xx: fix sched scan of DFS channels
wl12xx: mark no sched scan only after FW event
Felix Fietkau (2):
ath9k_hw: make bluetooth coexistence support optional at compile time
ath9k: fix tx locking issues
Franky Lin (30):
brcm80211: fmac: unify common layer driver data structure
brcm80211: fmac: remove oneline proto block functions
brcm80211: fmac: register a dummy irq handler for SDIO function 2
brcm80211: fmac: change function add_if parameter
brcm80211: fmac: change function bus_start parameter
brcm80211: fmac: change function brcmf_detach parameter
brcm80211: fmac: change function txflowcontrol parameter
brcm80211: fmac: change function txcomplete parameter
brcm80211: fmac: change function brcmf_c_prec_enq parameter
brcm80211: fmac: change function rx_frame parameter
brcm80211: fmac: change function proto_hdrpull parameter
brcm80211: fmac: move sdio used statistics to struct brcmf_sdio
brcm80211: fmac: move maxctl to struct brcmf_bus
brcm80211: fmac: move driver up status to struct brcmf_bus
brcm80211: fmac: remove duplicate statistics from driver data structure
brcm80211: fmac: move dongle statistics to struct brcmf_bus
brcm80211: fmac: move packet realloc stats to struct brcmf_bus
brcm80211: fmac: move tx flow ctrl flag to bus layer
brcm80211: fmac: stop referencing brcmf_pub in bus layer
brcm80211: fmac: stop referencing brcmf_sdio in common layer
brcm80211: fmac: move sdio related macros to sdio_host.h
brcm80211: fmac: abstract bus_stop interface function pointer
brcm80211: fmac: move common layer bus interface context to dhd_bus.h
brcm80211: fmac: abstract bus_init interface function pointer
brcm80211: fmac: abstract bus_txdata interface function pointer
brcm80211: fmac: abstract ctrl frames interface function pointers
brcm80211: fmac: move debug level macros to dhd_dbg.h
brcm80211: fmac: move idle macros to dhd_sdio.c
brcm80211: fmac: exclude unnecessary header files
brcm80211: fmac: add Kconfig option for SDIO bus support
Gustavo F. Padovan (39):
Bluetooth: remove struct hci_chan_hash
Bluetooth: remove lock from struct conn_hash
Bluetooth: Initialize LE connection count
Bluetooth: Use chan instead of l2cap_pi macro
Bluetooth: Use list_for_each_entry in hci_conn_hash_flush()
Bluetooth: make hci_conn_enter_sniff_mode static
Bluetooth: Replace spin_lock by mutex in hci_dev
Bluetooth: Use delayed_work for connection timeout
Bluetooth: Use delayed work for advertisiment cache timeout
Bluetooth: hci_conn_auto_accept() doesn't need locking
Bluetooth: Move L2CAP timers to workqueue
Bluetooth: Don't use spin_lock socket lock anymore
Bluetooth: Remove sk_backlog usage from L2CAP
Bluetooth: move hci_task_lock to mutex
Bluetooth: convert chan_lock to mutex
Bluetooth: Use RCU to manipulate chan_list
Bluetooth: convert conn hash to RCU
Bluetooth: Don't disable tasklets to call hdev->notify()
Bluetooth: Move command task to workqueue
Bluetooth: convert tx_task to workqueue
Bluetooth: convert info timer to delayed_work
Bluetooth: invert locking order in connect path
Bluetooth: Change l2cap chan_list to use RCU
Bluetooth: move power_off to system workqueue
Bluetooth: Use new alloc_workqueue()
Bluetooth: Remove work_add and work_del from hci_sysfs
Bluetooth: Use system workqueue to schedule power_on
Bluetooth: Add ProFUSION's copyright
Merge git://git.kernel.org/.../padovan/bluetooth
Bluetooth: Move l2cap_{set,clear}_timer to l2cap.h
Bluetooth: convert security timer to delayed_work
Bluetooth: Rename info_work to info_timer
Bluetooth: fix bt_accept_dequeue() to work in process context
Bluetooth: Remove l2cap priority from inside RFCOMM.
Bluetooth: add debug output to l2cap_ack_timeout()
Bluetooth: Remove lock from inquiry_cache
Bluetooth: remove *_bh usage from hci_dev_list and hci_cb_list
Bluetooth: Don't disable interrupt when locking the queue
Bluetooth: Fix a compile warning in RFCOMM
Helmut Schaa (1):
mac80211: Keep skb->piority for relayed frames in AP mode
Hemant Gupta (1):
Bluetooth: Incorrect address while storing LTK.
Hsu, Kenny (1):
iwlwifi: add IO function for continuous write of target memory
Jesse Sung (1):
Bluetooth: Add support for BCM20702A0 [0a5c:21e3]
Joe Perches (1):
ath: Convert ath_dbg(bar, ATH_DBG_<FOO>, to ath_dbg(bar, FOO
Johan Hedberg (10):
Bluetooth: Update mgmt_read_info and related mgmt messages
Bluetooth: Move mgmt_set_fast_connectable to the right location
Bluetooth: Remove mgmt_set_service_cache
Bluetooth: Move EIR and CoD update functions to a better position
Bluetooth: Add timer for automatically disabling the service cache
Bluetooth: Update ordering and opcodes of mgmt messages
Bluetooth: Use correct struct for user_confirm_neg_reply
Bluetooth: Add missing confirm_name field to mgmt_ev_device_found
Bluetooth: Fix mgmt_(block,unblock)_device opcodes
Bluetooth: Add missing mgmt_confirm_name command definition
Johannes Berg (6):
iwlwifi: remove unused AMPDU factor/density configuration
iwlagn: remove iwlagn_build_addsta_hcmd
mac80211: handle SMPS action frames
iwlagn: add IRQ tracing
iwlagn: finer-grained HT disable
iwlagn: fix (remove) use of PAGE_SIZE
John W. Linville (7):
b43: mark some vars __maybe_unused in b43_nphy_pmu_spur_avoid
Merge branch 'wireless-next' of git://git.kernel.org/.../iwlwifi/iwlwifi
Merge branch 'for-linville' of git://github.com/kvalo/ath6kl
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-next
Merge branch 'for-linville' of git://git.kernel.org/.../luca/wl12xx
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Jouni Malinen (1):
ath6kl: Use delayed key configuration for WAPI in AP mode
Kalle Valo (29):
ath6kl: move bmi calls to hif driver
ath6kl: change bmi sizes being configurable by HIF
ath6kl: move diag commands to hif driver
ath6kl: update ar6004 definitions
ath6kl: firmware boot fixes for ar6004
ath6kl: add hif_type
ath6kl: add USB support
ath6kl: disable HTC for USB devices
ath6kl: enable USB support
ath6kl: remove hw version related parameter defines
ath6kl: move hw version related to parameters to struct
ath6kl: add board address to struct ath6kl_hw
ath6kl: add firmware IE for board data address
ath6kl: add name field to struct ath6kl_hw
ath6kl: use hardware version names consistently
ath6kl: add ar6004 firmwares to sdio module
ath6kl: add firmware filename info to struct ath6kl_hw
ath6kl: make maximum number of vifs runtime configurable
ath6kl: add firmware IE for maximum number of vifs
Merge remote branch 'wireless-next/master' into ath6kl-next
ath6kl: remove unused sc_params from struct ath6kl
ath6kl: cleanup ath6kl_priv()
ath6kl: remove a workaround from ath6kl_cfg80211_stop()
ath6kl: call ath6kl_cfg80211_stop() from ath6kl_close()
ath6kl: implement ath6kl_cfg80211_stop_all()
ath6kl: fix value of WOW_FILTER_SSID
ath6kl: fix reading of FW IE capabilities
ath6kl: implement scheduled scan
Merge remote branch 'wireless-next/master' into ath6kl-next
Larry Finger (1):
rtlwifi: Fix locking problem introduces with commit 6539306b
Luciano Coelho (1):
wl12xx: add missing copyright notice
Luis R. Rodriguez (4):
ath6kl: fix ath6kl's set tx power
ath9k: classify DFS debug header further
ath9k: fix roadkill due to Joe's patch on ath_dbg() changes
atheros: force endian checks on atheros wireless drivers
Marcel Holtmann (1):
Bluetooth: Process recv path in a workqueue instead of a tasklet
Marek Lindner (1):
mac80211: ibss should not purge clients it is not responsible for
Mat Martineau (1):
Bluetooth: Incoming ACL packets do not force active mode
Naveen Gangadharan (1):
ath6kl: AR6004 SDIO support
Nikolay Martynov (1):
mac80211: split addba retries in time
Paul Stewart (1):
cfg80211: Return beacon loss count in station
Rafał Miłecki (8):
b43: N-PHY: reorder functions: put basic ones at beginning
b43: N-PHY: reorder functions: collect radio ones
b43: N-PHY: reorder functions: collect samples ones
b43: N-PHY: reorder functions: collect RSSI selects
b43: N-PHY: split gain control workarounds
b43: N-PHY: reorder functions: move RSSI calibration
b43: N-PHY: reorder functions: move rest of workarounds
b43: N-PHY: reorder functions: random cleanups
Raja Mani (3):
ath6kl: Fix cfg80211 warning while starting IBSS mode
ath6kl: Clear WPS ctrl flag if zero length IE is received from cfg80211
ath6kl: Use mutex to protect dma buffer in sync read write
Ryan Hsu (1):
ath6kl: Support different uart_tx pin and refclk configuration
Samuel Ortiz (1):
NFC: Fix LLCP related build failure
Ulisses Furquim (4):
Bluetooth: Remove global mutex hci_task_lock
Bluetooth: Always compile SCO and L2CAP in Bluetooth Core
Bluetooth: Make HCI call directly into SCO and L2CAP event functions
Bluetooth: Fix deadlocks with sock lock and L2CAP timers locks
Vasanthakumar Thiagarajan (9):
ath6kl: Fix accessing wrong skb->data in ath6kl_tx_complete()
ath6kl: Fix packet drop when ath6kl_cookie runs out
ath6kl: Fix bug in setting default key index for tx in AP mode
ath6kl: Fix bug in setting dot11_auth_mode in AP mode
ath6kl: Fix AP mode operation after interface down/up
ath6kl: Remove modparam multi_norm_if_support
ath6kl: Find ar->max_norm_iface in firmware IE parsing
ath6kl: Enable multiple vif support
ath6kl: Increase the maximum number of connections in AP mode
Venkataraman, Meenakshi (1):
iwlwifi: Execute runtime calibration always
Wey-Yi Guy (3):
iwlwifi: deliver hw version in both string and u32 format
iwlwifi: set hw_version in wiphy
iwlwifi: use bus_get_hw_id for IWL_TM_CMD_APP2DEV_GET_DEVICE_ID
Yogesh Ashok Powar (2):
mac80211: Fixing sparse warning at sta_info.c
mwl8k: Call ieee80211_stop_tx_ba_cb_irqsafe for already deleted BA stream
francesco.gringoli@ing.unibs.it (1):
b43: avoid packet losses in the dma worker code.
drivers/bluetooth/btusb.c | 10 +-
drivers/net/wireless/ath/Makefile | 1 +
drivers/net/wireless/ath/ath.h | 7 +-
drivers/net/wireless/ath/ath6kl/Kconfig | 25 +-
drivers/net/wireless/ath/ath6kl/Makefile | 37 +-
drivers/net/wireless/ath/ath6kl/bmi.c | 245 +-
drivers/net/wireless/ath/ath6kl/bmi.h | 6 -
drivers/net/wireless/ath/ath6kl/cfg80211.c | 382 ++-
drivers/net/wireless/ath/ath6kl/cfg80211.h | 6 +-
drivers/net/wireless/ath/ath6kl/common.h | 1 +
drivers/net/wireless/ath/ath6kl/core.h | 109 +-
drivers/net/wireless/ath/ath6kl/debug.c | 4 +-
drivers/net/wireless/ath/ath6kl/debug.h | 1 +
drivers/net/wireless/ath/ath6kl/hif-ops.h | 30 +
drivers/net/wireless/ath/ath6kl/hif.c | 5 +
drivers/net/wireless/ath/ath6kl/hif.h | 5 +
drivers/net/wireless/ath/ath6kl/htc.c | 10 +-
drivers/net/wireless/ath/ath6kl/init.c | 380 ++-
drivers/net/wireless/ath/ath6kl/main.c | 125 +-
drivers/net/wireless/ath/ath6kl/sdio.c | 329 ++-
drivers/net/wireless/ath/ath6kl/target.h | 16 +-
drivers/net/wireless/ath/ath6kl/txrx.c | 20 +-
drivers/net/wireless/ath/ath6kl/usb.c | 431 ++
drivers/net/wireless/ath/ath6kl/wmi.c | 152 +-
drivers/net/wireless/ath/ath6kl/wmi.h | 143 +-
drivers/net/wireless/ath/ath9k/Kconfig | 8 +
drivers/net/wireless/ath/ath9k/ani.c | 29 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 42 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 134 +-
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 120 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 76 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 14 +-
drivers/net/wireless/ath/ath9k/ar9003_mci.c | 275 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 17 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 44 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/beacon.c | 39 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 28 +-
drivers/net/wireless/ath/ath9k/calib.c | 20 +-
drivers/net/wireless/ath/ath9k/dfs.c | 8 +-
drivers/net/wireless/ath/ath9k/dfs_debug.h | 6 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 3 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 23 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 17 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 28 +-
drivers/net/wireless/ath/ath9k/gpio.c | 19 +-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 51 +-
drivers/net/wireless/ath/ath9k/htc_drv_gpio.c | 18 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 25 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 88 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 13 +-
drivers/net/wireless/ath/ath9k/hw.c | 89 +-
drivers/net/wireless/ath/ath9k/hw.h | 14 +
drivers/net/wireless/ath/ath9k/init.c | 13 +-
drivers/net/wireless/ath/ath9k/mac.c | 36 +-
drivers/net/wireless/ath/ath9k/main.c | 109 +-
drivers/net/wireless/ath/ath9k/mci.c | 135 +-
drivers/net/wireless/ath/ath9k/pci.c | 2 +-
drivers/net/wireless/ath/ath9k/rc.c | 7 +-
drivers/net/wireless/ath/ath9k/recv.c | 17 +-
drivers/net/wireless/ath/ath9k/wmi.c | 8 +-
drivers/net/wireless/ath/ath9k/xmit.c | 118 +-
drivers/net/wireless/ath/key.c | 8 +-
drivers/net/wireless/b43/b43.h | 9 +-
drivers/net/wireless/b43/dma.c | 15 +-
drivers/net/wireless/b43/main.c | 55 +-
drivers/net/wireless/b43/phy_n.c | 4253 ++++++++++----------
drivers/net/wireless/brcm80211/Kconfig | 18 +-
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 22 +-
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 8 +-
.../net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 135 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h | 93 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c | 42 +-
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 20 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.h | 15 +
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 423 +--
.../net/wireless/brcm80211/brcmfmac/dhd_proto.h | 7 -
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 325 +-
.../net/wireless/brcm80211/brcmfmac/sdio_chip.c | 1 -
.../net/wireless/brcm80211/brcmfmac/sdio_host.h | 10 +
drivers/net/wireless/iwlwifi/iwl-1000.c | 14 +-
drivers/net/wireless/iwlwifi/iwl-2000.c | 28 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 24 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 22 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 13 +-
drivers/net/wireless/iwlwifi/iwl-agn-rx.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-agn-tt.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 336 ++-
drivers/net/wireless/iwlwifi/iwl-agn.c | 82 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 9 +-
drivers/net/wireless/iwlwifi/iwl-bus.h | 16 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 59 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 79 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 34 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 75 +-
drivers/net/wireless/iwlwifi/iwl-devtrace.h | 29 +
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 58 +-
drivers/net/wireless/iwlwifi/iwl-io.c | 19 +-
drivers/net/wireless/iwlwifi/iwl-io.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-led.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-led.h | 14 -
drivers/net/wireless/iwlwifi/iwl-mac80211.c | 88 +-
drivers/net/wireless/iwlwifi/iwl-pci.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-shared.h | 180 +-
drivers/net/wireless/iwlwifi/iwl-testmode.c | 35 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h | 13 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 107 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 146 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 151 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 33 +-
drivers/net/wireless/iwlwifi/iwl-ucode.c | 105 +-
drivers/net/wireless/iwlwifi/iwl-wifi.h | 74 +
drivers/net/wireless/libertas/cfg.c | 10 +-
drivers/net/wireless/mwifiex/cfg80211.c | 122 +-
drivers/net/wireless/mwifiex/fw.h | 2 -
drivers/net/wireless/mwifiex/init.c | 2 +-
drivers/net/wireless/mwifiex/ioctl.h | 11 -
drivers/net/wireless/mwifiex/join.c | 14 +-
drivers/net/wireless/mwifiex/main.h | 5 +-
drivers/net/wireless/mwifiex/scan.c | 8 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
drivers/net/wireless/mwifiex/sta_ioctl.c | 61 -
drivers/net/wireless/mwl8k.c | 14 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +
drivers/net/wireless/rtlwifi/base.c | 1 +
drivers/net/wireless/rtlwifi/ps.c | 5 +-
drivers/net/wireless/rtlwifi/wifi.h | 1 +
drivers/net/wireless/wl12xx/cmd.c | 3 +
drivers/net/wireless/wl12xx/event.c | 2 +-
drivers/net/wireless/wl12xx/main.c | 104 +-
drivers/net/wireless/wl12xx/ps.c | 10 +-
drivers/net/wireless/wl12xx/scan.c | 18 +-
drivers/net/wireless/wl12xx/wl12xx.h | 2 +-
drivers/net/wireless/wl12xx/wl12xx_platform_data.c | 21 +
include/linux/nl80211.h | 2 +
include/net/bluetooth/bluetooth.h | 22 -
include/net/bluetooth/hci.h | 23 +-
include/net/bluetooth/hci_core.h | 280 +-
include/net/bluetooth/l2cap.h | 46 +-
include/net/bluetooth/mgmt.h | 191 +-
include/net/bluetooth/smp.h | 6 +
include/net/cfg80211.h | 7 +-
include/net/mac80211.h | 5 +-
net/bluetooth/Kconfig | 37 +-
net/bluetooth/Makefile | 5 +-
net/bluetooth/af_bluetooth.c | 11 +-
net/bluetooth/bnep/Kconfig | 2 +-
net/bluetooth/cmtp/Kconfig | 2 +-
net/bluetooth/hci_conn.c | 139 +-
net/bluetooth/hci_core.c | 325 +-
net/bluetooth/hci_event.c | 127 +-
net/bluetooth/hci_sock.c | 21 +-
net/bluetooth/hci_sysfs.c | 91 +-
net/bluetooth/hidp/Kconfig | 2 +-
net/bluetooth/hidp/core.c | 4 +-
net/bluetooth/l2cap_core.c | 434 +--
net/bluetooth/l2cap_sock.c | 62 +-
net/bluetooth/mgmt.c | 706 ++--
net/bluetooth/rfcomm/Kconfig | 2 +-
net/bluetooth/rfcomm/core.c | 41 +-
net/bluetooth/sco.c | 42 +-
net/bluetooth/smp.c | 235 +-
net/mac80211/agg-tx.c | 19 +
net/mac80211/cfg.c | 4 +-
net/mac80211/mlme.c | 8 +
net/mac80211/rx.c | 65 +-
net/mac80211/sta_info.c | 12 +-
net/mac80211/sta_info.h | 8 +-
net/nfc/llcp/llcp.c | 6 +-
net/nfc/nfc.h | 4 +-
net/wireless/nl80211.c | 3 +
179 files changed, 8240 insertions(+), 6795 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath6kl/usb.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-wifi.h
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [net-next 07/11] e1000e: cleanup Rx checksum offload code
From: David Miller @ 2012-01-03 21:15 UTC (permalink / raw)
To: bhutchings; +Cc: jeffrey.t.kirsher, bruce.w.allan, netdev, gospo, sassmann
In-Reply-To: <1325624413.2832.9.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 3 Jan 2012 21:00:12 +0000
> On Tue, 2012-01-03 at 15:08 -0500, David Miller wrote:
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Tue, 3 Jan 2012 11:19:12 -0800
>>
>> > - __sum16 sum = (__force __sum16)htons(csum);
>> > + __sum16 sum = (__force __sum16)htons(le16_to_cpu(csum));
>>
>> Looks like a NOP. It's essentially "cpu_to_le16(le16_to_cpu(csum)" as
>> far as I can tell.
>
> Looks like a swab() to me...
I don't see how it can be. It's effectively doing a 16-bit swap and
then a 16-bit swap again, which is a NOP.
It's the same as "(__force __sum16) csum" and I bet if the code above
works, then this expression I'm suggesting will work too.
^ permalink raw reply
* Re: [net-next 07/11] e1000e: cleanup Rx checksum offload code
From: Ben Hutchings @ 2012-01-03 21:24 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, bruce.w.allan, netdev, gospo, sassmann
In-Reply-To: <20120103.161553.395980097965998086.davem@davemloft.net>
On Tue, 2012-01-03 at 16:15 -0500, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Tue, 3 Jan 2012 21:00:12 +0000
>
> > On Tue, 2012-01-03 at 15:08 -0500, David Miller wrote:
> >> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >> Date: Tue, 3 Jan 2012 11:19:12 -0800
> >>
> >> > - __sum16 sum = (__force __sum16)htons(csum);
> >> > + __sum16 sum = (__force __sum16)htons(le16_to_cpu(csum));
> >>
> >> Looks like a NOP. It's essentially "cpu_to_le16(le16_to_cpu(csum)" as
> >> far as I can tell.
> >
> > Looks like a swab() to me...
>
> I don't see how it can be. It's effectively doing a 16-bit swap and
> then a 16-bit swap again, which is a NOP.
>
> It's the same as "(__force __sum16) csum" and I bet if the code above
> works, then this expression I'm suggesting will work too.
In this part of the universe, network order is big-endian.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: iproute2: proper detection of libxtables position and flags
From: Stephen Hemminger @ 2012-01-03 21:47 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Networking Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1112312317220.24158@frira.zrqbmnf.qr>
On Sat, 31 Dec 2011 23:17:56 +0100 (CET)
Jan Engelhardt <jengelh@medozas.de> wrote:
> From: Jan Engelhardt <jengelh@medozas.de>
> Date: 2011-09-24 23:37:34.405739159 +0200
> Upstream: not sent yet
>
> Any tests involving iptables _MUST_ utilize pkg-config to find the
> proper locations of the installation.
>
Will this work for all distros? Is this backwards compatiable?
^ permalink raw reply
* [PATCHv2 net-next 0/8] RX NFC support for hash-based filters
From: Ben Hutchings @ 2012-01-03 21:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
1. Fix gianfar's validation of filter rule locations. In the previous
version of this series, this was a requirement for part 2, but that's
no longer the case.
2. Extend ethtool RX NFC rules API to support hash-based filter hardware
in which rule locations should be selected by the driver or firmware.
3. Change the sfc driver to implement this API instead of RX n-tuple.
4. Remove support for RX n-tuple, now that there are no in-tree
implementations.
Ben.
Ben Hutchings (8):
gianfar: Reject out-of-range RX NFC locations
ethtool: Allow drivers to select RX NFC rule locations
sfc: Change filter ID generation to satisfy priority semantics of RX
NFC
sfc: Use consistent types for filter IDs, indices and search depths
sfc: Add support for retrieving and removing filters by ID
sfc: Implement ethtool RX NFC rules API instead of n-tuple API
sfc: Remove now-unused filter function
ethtool: Remove ethtool_ops::set_rx_ntuple operation
drivers/net/ethernet/freescale/gianfar_ethtool.c | 5 +-
drivers/net/ethernet/sfc/efx.h | 16 +-
drivers/net/ethernet/sfc/ethtool.c | 188 +++++++++++---
drivers/net/ethernet/sfc/filter.c | 310 +++++++++++++++++++---
drivers/net/ethernet/sfc/filter.h | 12 +
include/linux/ethtool.h | 30 ++-
net/core/ethtool.c | 66 +----
net/socket.c | 2 +-
8 files changed, 484 insertions(+), 145 deletions(-)
--
1.7.4.4
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: iproute2: avoid use of implicit declarations
From: Stephen Hemminger @ 2012-01-03 21:57 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Networking Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1112312321370.6978@frira.zrqbmnf.qr>
On Sat, 31 Dec 2011 23:22:05 +0100 (CET)
Jan Engelhardt <jengelh@medozas.de> wrote:
> From: Jan Engelhardt <jengelh@medozas.de>
> Date: 2011-12-31 23:16:27.428349795 +0100
>
> gcc -DLIBDIR=\"/usr/lib64\" -D_GNU_SOURCE -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wstrict-prototypes -fPIC -DXT_LIB_DIR=\"/usr/lib64/xtables\" -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib64\" -fPIC -c -o ipx_pton.o ipx_pton.c
> In file included from ../include/utils.h:8:0,
> from ipx_ntop.c:5:
> ../include/libnetlink.h: In function 'rta_getattr_u64':
> ../include/libnetlink.h:84:2: warning: implicit declaration of function 'memcpy'
> ../include/libnetlink.h:84:2: warning: incompatible implicit declaration of built-in function 'memcpy'
>
> diff --git a/include/libnetlink.h b/include/libnetlink.h
> index b237579..b0656ce 100644
> --- a/include/libnetlink.h
> +++ b/include/libnetlink.h
> @@ -1,6 +1,7 @@
> #ifndef __LIBNETLINK_H__
> #define __LIBNETLINK_H__ 1
>
> +#include <string.h>
> #include <asm/types.h>
> #include <linux/netlink.h>
> #include <linux/rtnetlink.h>
Applied.
^ 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