* Re: [PATCH] Fix panic in ip6_pol_route
From: Krishna Kumar2 @ 2011-04-06 8:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110406.004043.193732725.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 04/06/2011 01:10:43 PM:
> > The fix is to not update ip6_null_entry for a vlan device. Please
> > review.
>
> This is just rediculious.
>
> Configuring a vlan on loopback is stupid.
>
> Having IFF_LOOPBACK be set on a loopback device is even more
> stupid.
>
> So fix one of those two things, otherwise we'll just add a million
> tests over time to this conditional.
We had asked the test team for the reason for this test case:
"I suspect that the use of the loopback, is simply due to some of
our images being very limited and the automated test needed an
interface that it could assume would always exist"
Is it better to disallow configuring vlan on lo?
thanks,
- KK
^ permalink raw reply
* Re: [PATCH 12/34] isdn/diva: Drop __TIME__ usage
From: Michal Marek @ 2011-04-06 8:06 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Armin Schindler, linux-kbuild, linux-kernel, netdev
In-Reply-To: <20627.1302031056@localhost>
On 5.4.2011 21:17, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 05 Apr 2011 17:10:34 +0200, Armin Schindler said:
>> On Tue, 5 Apr 2011, Michal Marek wrote:
>>> The kernel already prints its build timestamp during boot, no need to
>>> repeat it in random drivers and produce different object files each
>>> time.
>>
>> The module can be build separately from the kernel, therefore it can have
>> an own build timestamp.
>
> If the same code is being built as an out-of-tree module, that's a possibly
> good reason for a code version variable, but what does the build timestamp
> actually tell you? If you already know foo_driver.c version 0.814 was buiilt
> against 2.6.41-rc2, in what cases does it matter if the compile was on Tuesday
> or Thursday - especially since an 'ls -l foo_driver.ko' will tell you? If it's
> a matter of "the target .config changed on Wednesday", a build timestamp still
> doesn't help over 'ls -l'.
Exactly. Build timestamps are only a poor substitute for proper version
tracking. If you want to be able to reproduce the build of a binary, you
want it to embed some source revision, not the date when you built it.
For the kernel, you can use KBUILD_BUILD_TIMESTAMP=<source timestamp>,
for out-of-tree modules, you need to come up with something own.
Michal
^ permalink raw reply
* Re: [PATCH] Fix panic in ip6_pol_route
From: David Miller @ 2011-04-06 7:41 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20110406.004043.193732725.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 06 Apr 2011 00:40:43 -0700 (PDT)
> Having IFF_LOOPBACK be set on a loopback device is even more
> stupid.
I mean "VLAN device" here of course.
^ permalink raw reply
* Re: [PATCH] Fix panic in ip6_pol_route
From: David Miller @ 2011-04-06 7:40 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20110406064504.30691.36599.sendpatchset@krkumar2.in.ibm.com>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Wed, 06 Apr 2011 12:15:04 +0530
> The fix is to not update ip6_null_entry for a vlan device. Please
> review.
This is just rediculious.
Configuring a vlan on loopback is stupid.
Having IFF_LOOPBACK be set on a loopback device is even more
stupid.
So fix one of those two things, otherwise we'll just add a million
tests over time to this conditional.
^ permalink raw reply
* Re: shutdown oops in xt_compat_calc_jump
From: Florian Westphal @ 2011-04-06 7:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Florian Westphal, Patrick McHardy, dann frazier, netdev,
netfilter-devel@vger.kernel.org
In-Reply-To: <1302064927.3020.1.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 06 avril 2011 à 01:42 +0200, Florian Westphal a écrit :
>
> > using ninfo->nentries does not always work because ebtables compat
> > can call xt_compat_add_offset() more than once per entry.
> >
>
> With same offset ? Maybe we should tweak xt_compat_add_offset() to
> detect this and add delta to previous delta in this case
No, different offset (it calls it per match/watcher/target instead
of summing up the match/target deltas and using that in a single
add_offset call).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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/RFC] can: mcp251x: Allow pass IRQ flags through platform data.
From: Kurt Van Dijck @ 2011-04-06 7:14 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1302023321-25182-1-git-send-email-eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
On Tue, Apr 05, 2011 at 07:08:41PM +0200, Enric Balletbo i Serra wrote:
> ret = request_threaded_irq(spi->irq, NULL, mcp251x_can_ist,
> - IRQF_TRIGGER_FALLING, DEVICE_NAME, priv);
> + pdata->irq_flags ? pdata->irq_flags : IRQF_TRIGGER_FALLING,
> + DEVICE_NAME, priv);
IMHO, doing like this looks just a tiny bit cleaner
> + pdata->irq_flags ?: IRQF_TRIGGER_FALLING,
> + DEVICE_NAME, priv);
That's really the only remark :-)
Regards,
Kurt
^ permalink raw reply
* Re: [PATCH/RFC] can: mcp251x: Allow pass IRQ flags through platform data.
From: Marc Kleine-Budde @ 2011-04-06 6:57 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1302023321-25182-1-git-send-email-eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 897 bytes --]
On 04/05/2011 07:08 PM, Enric Balletbo i Serra wrote:
> When an interrupt occurs, the INT pin is driven low by the
> MCP251x controller (falling edge) but in some cases the INT
> pin can be connected to the MPU through a transistor or level
> translator which inverts this signal. In this case interrupt
> should be configured in rising edge.
>
> This patch adds support to pass the IRQ flags via
> mcp251x_platform_data.
>
> Signed-off-by: Enric Balletbo i Serra <eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
looks good
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH/RFC] can: mcp251x: Allow pass IRQ flags through platform data.
From: Wolfgang Grandegger @ 2011-04-06 6:47 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1302023321-25182-1-git-send-email-eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
On 04/05/2011 07:08 PM, Enric Balletbo i Serra wrote:
> When an interrupt occurs, the INT pin is driven low by the
> MCP251x controller (falling edge) but in some cases the INT
> pin can be connected to the MPU through a transistor or level
> translator which inverts this signal. In this case interrupt
> should be configured in rising edge.
>
> This patch adds support to pass the IRQ flags via
> mcp251x_platform_data.
>
> Signed-off-by: Enric Balletbo i Serra <eballetbo-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang.
^ permalink raw reply
* [PATCH] Fix panic in ip6_pol_route
From: Krishna Kumar @ 2011-04-06 6:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Krishna Kumar
Vlan testing panic'd with this script:
# vconfig add lo 42
# vconfig rem lo.42
# ifdown lo
# ifup lo
# ping6 fe80::%eth0
BUG: unable to handle kernel NULL pointer dereference at 0000000000000106
IP: [<ffffffffa018efd3>] ip6_pol_route+0x233/0x360 [ipv6]
PGD 1c1a8067 PUD 1cb2a067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/net/lo.42/addr_len
CPU 0
Modules linked in: garp stp llc ip6table_filter ip6_tables iptable_filter
ip_tables ebtable_nat ebtables autofs4 sunrpc ipv6 virtio_net virtio_balloon
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer
snd soundcore snd_page_alloc i2c_piix4 i2c_core sg ext3 jbd mbcache sd_mod
crc_t10dif virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mod
[last unloaded: 8021q]
Modules linked in: garp stp llc ip6table_filter ip6_tables iptable_filter
ip_tables ebtable_nat ebtables autofs4 sunrpc ipv6 virtio_net virtio_balloon
snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer
snd soundcore snd_page_alloc i2c_piix4 i2c_core sg ext3 jbd mbcache sd_mod
crc_t10dif virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mod
[last unloaded: 8021q]
Pid: 1752, comm: ping6 Not tainted 2.6.32-71.18.5.mcp7.x86_64 #1 Bochs
RIP: 0010:[<ffffffffa018efd3>] [<ffffffffa018efd3>] ip6_pol_route+0x233/0x360
[ipv6]
RSP: 0018:ffff88001fad1ae8 EFLAGS: 00010296
RAX: ffff88001fb23800 RBX: ffff88001fb23800 RCX: ffff88001fb23800
RDX: ffffffff81c99600 RSI: 0000000000000002 RDI: ffff88001fb23800
RBP: ffff88001fad1b78 R08: 000000000000000b R09: ffff88001fb23910
R10: 0000000000000000 R11: ffff88001fad1da4 R12: 00000000ffffffff
R13: 0000000000000003 R14: 0000000000000002 R15: ffff88001fad1b44
FS: 00007f89ed64a700(0000) GS:ffff880001e00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000106 CR3: 000000001cb1e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ping6 (pid: 1752, threadinfo ffff88001fad0000, task ffff88001cadeaf0)
Stack:
000000001cadeaf0 ffff88001fa84254 0000000100000003 ffff88001fa84258
<0> ffff88001fad1db4 ffff88001fad1da4 0000000200000002 ffffffff81c99600
<0> ffff88001fa84258 ffff88001fb23800 ffffea0000000041 ffffffff00000000
Call Trace:
[<ffffffffa018f116>] ip6_pol_route_output+0x16/0x20 [ipv6]
[<ffffffffa01b2601>] fib6_rule_action+0xd1/0x1f0 [ipv6]
[<ffffffffa018f100>] ? ip6_pol_route_output+0x0/0x20 [ipv6]
[<ffffffff8142205d>] fib_rules_lookup+0xbd/0x110
[<ffffffffa01b2755>] fib6_rule_lookup+0x35/0xa0 [ipv6]
[<ffffffffa018f100>] ? ip6_pol_route_output+0x0/0x20 [ipv6]
[<ffffffffa018d2c5>] ip6_route_output+0xa5/0xc0 [ipv6]
[<ffffffffa0180773>] ip6_dst_lookup_tail+0x223/0x250 [ipv6]
[<ffffffffa0197b60>] ? ipv6_rcv_saddr_equal+0x0/0x1f0 [ipv6]
[<ffffffffa01808b5>] ip6_dst_lookup+0x15/0x20 [ipv6]
[<ffffffffa01ab493>] ip6_datagram_connect+0x323/0x630 [ipv6]
[<ffffffff814c93cb>] ? _spin_unlock_bh+0x1b/0x20
[<ffffffff813ff697>] ? release_sock+0xb7/0xd0
[<ffffffff8146f5ec>] inet_dgram_connect+0x2c/0x80
[<ffffffff813fd1c7>] sys_connect+0xd7/0xf0
[<ffffffff810d3872>] ? audit_syscall_entry+0x272/0x2a0
[<ffffffff81013172>] system_call_fastpath+0x16/0x1b
Code: 28 48 8b 4d b8 48 8b 55 a8 48 8b 41 18 48 8b 80 08 04 00 00 4c 8b 80 c0
03 00 00 48 8b 82 c0 03 00 00 4c 39 c0 0f 84 35 ff ff ff <41> f6 80 fb 00 00 00
01 0f 85 aa 00 00 00 3e 41 ff 80 c0 00 00
RIP [<ffffffffa018efd3>] ip6_pol_route+0x233/0x360 [ipv6]
RSP <ffff88001fad1ae8>
CR2: 0000000000000106
The fix is to not update ip6_null_entry for a vlan device. Please
review.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
net/ipv6/route.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -ruNp org/net/ipv6/route.c new/net/ipv6/route.c
--- org/net/ipv6/route.c 2011-03-29 19:35:21.000000000 +0530
+++ new/net/ipv6/route.c 2011-03-29 19:36:05.000000000 +0530
@@ -2488,7 +2488,8 @@ static int ip6_route_dev_notify(struct n
struct net_device *dev = (struct net_device *)data;
struct net *net = dev_net(dev);
- if (event == NETDEV_REGISTER && (dev->flags & IFF_LOOPBACK)) {
+ if (event == NETDEV_REGISTER && (dev->flags & IFF_LOOPBACK) &&
+ !(dev->priv_flags & IFF_802_1Q_VLAN)) {
net->ipv6.ip6_null_entry->dst.dev = dev;
net->ipv6.ip6_null_entry->rt6i_idev = in6_dev_get(dev);
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
^ permalink raw reply
* Re: [PATCH] bonding-tlb: better balance when choosing slaves
From: Weiping Pan @ 2011-04-06 5:31 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Andy Gospodarek (supporter:BONDING DRIVER), netdev, linux-kernel
In-Reply-To: <3084.1302065172@death>
On 04/06/2011 12:46 PM, Jay Vosburgh wrote:
> Weiping Pan<panweiping3@gmail.com> wrote:
>
>> On 04/03/2011 02:25 AM, Jay Vosburgh wrote:
>>>> tlb_get_least_loaded_slave() always chooses slave from
>>>> bonding->first_slave, that gives the beginnig slaves more chances to be used.
>>>>
>>>> Let tlb_get_least_loaded_slave() chooses slave from a random positon in the
>>>> slave list, make all slaves transmit packets more balanced.
>>> If outgoing traffic is not being starved (i.e., connections are
>>> being balanced such that they are stacking up on one slave but
>>> under-utilizing another), then I don't understand what benefit this has.
>>>
>>> There is already some degree of randomness, as peers will be
>>> assigned in the order that packets are transmitted to them after each
>>> rebalance. The busiest peers will tend to be on the earlier slaves, and
>>> vice versa, but I'm not sure this is a bad thing.
>>>
>>> Does this have any real gain other than making the rx/tx
>>> statistics for the slaves more equal over time?
>>>
>>> I haven't measured it, but I would expect that for small numbers
>>> of peers, having them tend to stay on the same slaves over time is
>>> probably a good thing.
>> modprobe bonding mode=balance-tlb miimon=100
>> ifconfig bond0 192.168.1.2 netmask 255.255.255.0 up
>> ifenslave bond0 eth0
>> ifenslave bond0 eth1
>> ifenslave bond0 eth2
>> ping 192.168.1.100 -A -s 10240
>>
>> I find that bonding will always use eth0 and eth1, it never uses eth2,
>> because tlb_get_least_loaded_slave() always chooses slave from
>> bonding->first_slave, that gives the beginnig slaves more chances to be
>> used.
>>
>> Do you think this is a problem ?
> Not for this test case, no.
>
> On the other hand, if you run three pings concurrently to three
> different destinations and it still never uses eth2, then that might be
> something to look into.
>
>> Does it has conflicts with the meaning of balance and reblance?
> Not really; with only one active flow, there isn't really any
> advantage to moving it around. The balance and rebalance activity
> becomes more interesting when the traffic volume and number of
> destinations is larger.
>
> -J
ok, i agree with you.
thanks
Weiping Pan
>>>> Signed-off-by: Weiping Pan(潘卫平)<panweiping3@gmail.com>
>>>> ---
>>>> drivers/net/bonding/bond_alb.c | 17 +++++++++++++++--
>>>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>>>> index 9bc5de3..9fa64b0 100644
>>>> --- a/drivers/net/bonding/bond_alb.c
>>>> +++ b/drivers/net/bonding/bond_alb.c
>>>> @@ -36,6 +36,7 @@
>>>> #include<linux/if_bonding.h>
>>>> #include<linux/if_vlan.h>
>>>> #include<linux/in.h>
>>>> +#include<linux/random.h>
>>>> #include<net/ipx.h>
>>>> #include<net/arp.h>
>>>> #include<net/ipv6.h>
>>>> @@ -206,15 +207,27 @@ static long long compute_gap(struct slave *slave)
>>>> /* Caller must hold bond lock for read */
>>>> static struct slave *tlb_get_least_loaded_slave(struct bonding *bond)
>>>> {
>>>> - struct slave *slave, *least_loaded;
>>>> + struct slave *slave, *least_loaded, *start_slave;
>>>> long long max_gap;
>>>> int i;
>>>> + u8 n;
>>>>
>>>> least_loaded = NULL;
>>>> + start_slave = bond->first_slave;
>>>> max_gap = LLONG_MIN;
>>>> +
>>>> + get_random_bytes(&n, 1);
>>>> +
>>>> + if (bond->slave_cnt == 0)
>>>> + return NULL;
>>>> + n = n % bond->slave_cnt;
>>>> +
>>>> + for (i=0; i<n; ++i) {
>>>> + start_slave = start_slave->next;
>>>> + }
>>>>
>>>> /* Find the slave with the largest gap */
>>>> - bond_for_each_slave(bond, slave, i) {
>>>> + bond_for_each_slave_from(bond, slave, i, start_slave) {
>>>> if (SLAVE_IS_OK(slave)) {
>>>> long long gap = compute_gap(slave);
>>>>
>>>> --
>>>> 1.7.4
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH v2 net-next 3/9] tg3: Reintroduce 5717_PLUS
From: Joe Perches @ 2011-04-06 5:30 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev
In-Reply-To: <1302049371-13799-4-git-send-email-mcarlson@broadcom.com>
On Tue, 2011-04-05 at 17:22 -0700, Matt Carlson wrote:
> This patch reintroduces the TG3_FLG3_5717_PLUS to identify 5717 and
> later devices.
[]
> @@ -13427,8 +13422,7 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
[]
> + if (tp->tg3_flags3 & TG3_FLG3_5717_PLUS)
> tp->tg3_flags3 |= TG3_FLG3_LRG_PROD_RING_CAP;
This seems redundant. Maybe consolidate to just
TG3_FLG3_5717_PLUS and remove LRG_PROD_RING_CAP?
I don't know if these attributes really are linked.
Another option may be to use DECLARE_BITMAP
and set_bit/test_bit so there's no real need
to use FLAG/FLG2/FLG3, etc.
^ permalink raw reply
* Re: [PATCH] bonding-tlb: better balance when choosing slaves
From: Jay Vosburgh @ 2011-04-06 4:46 UTC (permalink / raw)
To: Weiping Pan
Cc: Andy Gospodarek (supporter:BONDING DRIVER), netdev, linux-kernel
In-Reply-To: <4D9BD1A9.1040402@gmail.com>
Weiping Pan <panweiping3@gmail.com> wrote:
>On 04/03/2011 02:25 AM, Jay Vosburgh wrote:
>>> tlb_get_least_loaded_slave() always chooses slave from
>>> bonding->first_slave, that gives the beginnig slaves more chances to be used.
>>>
>>> Let tlb_get_least_loaded_slave() chooses slave from a random positon in the
>>> slave list, make all slaves transmit packets more balanced.
>> If outgoing traffic is not being starved (i.e., connections are
>> being balanced such that they are stacking up on one slave but
>> under-utilizing another), then I don't understand what benefit this has.
>>
>> There is already some degree of randomness, as peers will be
>> assigned in the order that packets are transmitted to them after each
>> rebalance. The busiest peers will tend to be on the earlier slaves, and
>> vice versa, but I'm not sure this is a bad thing.
>>
>> Does this have any real gain other than making the rx/tx
>> statistics for the slaves more equal over time?
>>
>> I haven't measured it, but I would expect that for small numbers
>> of peers, having them tend to stay on the same slaves over time is
>> probably a good thing.
>modprobe bonding mode=balance-tlb miimon=100
>ifconfig bond0 192.168.1.2 netmask 255.255.255.0 up
>ifenslave bond0 eth0
>ifenslave bond0 eth1
>ifenslave bond0 eth2
>ping 192.168.1.100 -A -s 10240
>
>I find that bonding will always use eth0 and eth1, it never uses eth2,
>because tlb_get_least_loaded_slave() always chooses slave from
>bonding->first_slave, that gives the beginnig slaves more chances to be
>used.
>
>Do you think this is a problem ?
Not for this test case, no.
On the other hand, if you run three pings concurrently to three
different destinations and it still never uses eth2, then that might be
something to look into.
>Does it has conflicts with the meaning of balance and reblance?
Not really; with only one active flow, there isn't really any
advantage to moving it around. The balance and rebalance activity
becomes more interesting when the traffic volume and number of
destinations is larger.
-J
>>> Signed-off-by: Weiping Pan(潘卫平)<panweiping3@gmail.com>
>>> ---
>>> drivers/net/bonding/bond_alb.c | 17 +++++++++++++++--
>>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>>> index 9bc5de3..9fa64b0 100644
>>> --- a/drivers/net/bonding/bond_alb.c
>>> +++ b/drivers/net/bonding/bond_alb.c
>>> @@ -36,6 +36,7 @@
>>> #include<linux/if_bonding.h>
>>> #include<linux/if_vlan.h>
>>> #include<linux/in.h>
>>> +#include<linux/random.h>
>>> #include<net/ipx.h>
>>> #include<net/arp.h>
>>> #include<net/ipv6.h>
>>> @@ -206,15 +207,27 @@ static long long compute_gap(struct slave *slave)
>>> /* Caller must hold bond lock for read */
>>> static struct slave *tlb_get_least_loaded_slave(struct bonding *bond)
>>> {
>>> - struct slave *slave, *least_loaded;
>>> + struct slave *slave, *least_loaded, *start_slave;
>>> long long max_gap;
>>> int i;
>>> + u8 n;
>>>
>>> least_loaded = NULL;
>>> + start_slave = bond->first_slave;
>>> max_gap = LLONG_MIN;
>>> +
>>> + get_random_bytes(&n, 1);
>>> +
>>> + if (bond->slave_cnt == 0)
>>> + return NULL;
>>> + n = n % bond->slave_cnt;
>>> +
>>> + for (i=0; i<n; ++i) {
>>> + start_slave = start_slave->next;
>>> + }
>>>
>>> /* Find the slave with the largest gap */
>>> - bond_for_each_slave(bond, slave, i) {
>>> + bond_for_each_slave_from(bond, slave, i, start_slave) {
>>> if (SLAVE_IS_OK(slave)) {
>>> long long gap = compute_gap(slave);
>>>
>>> --
>>> 1.7.4
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: shutdown oops in xt_compat_calc_jump
From: Eric Dumazet @ 2011-04-06 4:42 UTC (permalink / raw)
To: Florian Westphal
Cc: Patrick McHardy, dann frazier, netdev,
netfilter-devel@vger.kernel.org
In-Reply-To: <20110405234216.GD32579@Chamillionaire.breakpoint.cc>
Le mercredi 06 avril 2011 à 01:42 +0200, Florian Westphal a écrit :
> using ninfo->nentries does not always work because ebtables compat
> can call xt_compat_add_offset() more than once per entry.
>
With same offset ? Maybe we should tweak xt_compat_add_offset() to
detect this and add delta to previous delta in this case
> That is of course not necessary; the ebt compat code should do better.
> I plan to look at this in the evening.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* [PatchV2 : PL25A1 Support - 1/3] whitespace
From: Simon Wood @ 2011-04-06 4:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Brownell, Sergei Shtylyov, linux-usb, netdev, linux-kernel,
davem, Simon Wood
In-Reply-To: <1301456667-1648-1-git-send-email-simon@mungewell.org>
Clear up a couple of instances of incorrect whitespace
Signed-off-by: Simon Wood <simon@mungewell.org>
---
drivers/net/usb/plusb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 08ad269..30578ea 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -134,13 +134,13 @@ static struct usb_driver plusb_driver = {
static int __init plusb_init(void)
{
- return usb_register(&plusb_driver);
+ return usb_register(&plusb_driver);
}
module_init(plusb_init);
static void __exit plusb_exit(void)
{
- usb_deregister(&plusb_driver);
+ usb_deregister(&plusb_driver);
}
module_exit(plusb_exit);
--
1.7.0.4
^ permalink raw reply related
* [PatchV2 : PL25A1 Support - 3/3] reset_debug
From: Simon Wood @ 2011-04-06 4:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Brownell, Sergei Shtylyov, linux-usb, netdev, linux-kernel,
davem, Simon Wood
In-Reply-To: <1301456667-1648-1-git-send-email-simon@mungewell.org>
Adds some debug in the event that reseting chip fails for some reason
Signed-off-by: Simon Wood <simon@mungewell.org>
---
drivers/net/usb/plusb.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index b9649e0..11ff297 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -94,11 +94,15 @@ pl_set_QuickLink_features(struct usbnet *dev, int val)
static int pl_reset(struct usbnet *dev)
{
+ int status;
+
/* some units seem to need this reset, others reject it utterly.
* FIXME be more like "naplink" or windows drivers.
*/
- (void) pl_set_QuickLink_features(dev,
+ status = pl_set_QuickLink_features(dev,
PL_S_EN|PL_RESET_OUT|PL_RESET_IN|PL_PEER_E);
+ if (status != 0 && netif_msg_probe(dev))
+ netif_dbg(dev, link, dev->net, "pl_reset --> %d\n", status);
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* [PatchV2 : PL25A1 Support - 2/3] add_pl25a1
From: Simon Wood @ 2011-04-06 4:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Brownell, Sergei Shtylyov, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Simon Wood
In-Reply-To: <1301456667-1648-1-git-send-email-simon-wM4F9T/ekXmXDw4h08c5KA@public.gmane.org>
This patch adds the USB ID's for the PL25A1, which is used in the
Belkin 'Windows Easy Transfer' cables.
Signed-off-by: Simon Wood <simon-wM4F9T/ekXmXDw4h08c5KA@public.gmane.org>
---
drivers/net/usb/Kconfig | 2 +-
drivers/net/usb/plusb.c | 22 ++++++++++++++++++++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 6f600cc..85fec06 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -258,7 +258,7 @@ config USB_NET_NET1080
optionally with LEDs that indicate traffic
config USB_NET_PLUSB
- tristate "Prolific PL-2301/2302 based cables"
+ tristate "Prolific PL-2301/2302/25A1 based cables"
# if the handshake/init/reset problems, from original 'plusb',
# are ever resolved ... then remove "experimental"
depends on USB_USBNET && EXPERIMENTAL
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 30578ea..b9649e0 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -45,6 +45,14 @@
* seems to get wedged under load. Prolific docs are weak, and
* don't identify differences between PL2301 and PL2302, much less
* anything to explain the different PL2302 versions observed.
+ *
+ * NOTE: pl2501 has several modes, including pl2301 and pl2302
+ * compatibility. Some docs suggest the difference between 2301
+ * and 2302 is only to make MS-Windows use a different driver...
+ *
+ * pl25a1 glue based on patch from Tony Gibbs. Prolific "docs" on
+ * this chip are as usual incomplete about what control messages
+ * are supported.
*/
/*
@@ -95,7 +103,7 @@ static int pl_reset(struct usbnet *dev)
}
static const struct driver_info prolific_info = {
- .description = "Prolific PL-2301/PL-2302",
+ .description = "Prolific PL-2301/PL-2302/PL-25A1",
.flags = FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset = pl_reset,
@@ -111,6 +119,7 @@ static const struct driver_info prolific_info = {
static const struct usb_device_id products [] = {
+/* full speed cables */
{
USB_DEVICE(0x067b, 0x0000), // PL-2301
.driver_info = (unsigned long) &prolific_info,
@@ -119,6 +128,15 @@ static const struct usb_device_id products [] = {
.driver_info = (unsigned long) &prolific_info,
},
+/* high speed cables */
+{
+ USB_DEVICE(0x067b, 0x25a1), /* PL-25A1, no eeprom */
+ .driver_info = (unsigned long) &prolific_info,
+}, {
+ USB_DEVICE(0x050d, 0x258a), /* Belkin F5U258/F5U279 (PL-25A1) */
+ .driver_info = (unsigned long) &prolific_info,
+},
+
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);
@@ -145,5 +163,5 @@ static void __exit plusb_exit(void)
module_exit(plusb_exit);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
MODULE_LICENSE("GPL");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: mourning the loss of David Brownell
From: Jidong Xiao @ 2011-04-06 3:35 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, Greg KH, Oliver Neukum, Bill Gatliff,
Kernel development list, USB list, linux-omap, spi-devel-general,
netdev
In-Reply-To: <20110406002144.GC6983@xanatos>
On Tue, Apr 5, 2011 at 8:21 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Tue, Apr 05, 2011 at 02:10:53PM -0400, Alan Stern wrote:
>> On Mon, 4 Apr 2011, Greg KH wrote:
>>
>> > As I have seen this tangentally mentioned already a few times
>> > publically, I figured it warranted it's own announcement now.
>> >
>> > Linux has lost a great developer with the passing of David Brownell
>> > recently and he will be greatly missed.
>>
>> David made contributions to a large number of areas in the Linux
>> kernel. Even a quick look through MAINTAINERS will show that he worked
>> on USB controllers (OHCI, EHCI, OMAP and others), USB gadgets, USB
>> networking, and SPI. He was influential in the core USB design (the
>> HCD "glue" layer and the scatter-gather library) and the development of
>> Power Management (system sleep and the USB PM implementation). His
>> designs were elegant and his code was always a pleasure to read.
>>
>> He also was a big help to me personally, assisting in my initial entry
>> to USB core development. And he was the first person I met at the
>> first Linux conference I attended. I too will miss him.
>
> On Tue, Apr 05, 2011 at 11:17:20AM -0700, Bill Gatliff wrote:
>> Guys:
>>
>>
>> David Brownell unknowingly inspired me to get involved in Linux as a
>> profession. I saw him as an individual working successfully on Free
>> and Open Software, and have made an effort to emulate his success for
>> over a decade now.
>>
>> I deeply regret never taking the time to meet and thank him in person.
>
> A reminder that we all are mortal. Since David I can't thank David
> either, I'd like to take a moment to thank Greg, Alan, and Oliver.
> David, Greg, Alan, and Oliver were really great at putting up with my
> newbie questions when I was first working on usbfs2, and I really
> appreciate all the help, support, and feedback they've given me over the
> years. Thank you!
>
Me too. David and the other developers you mentioned here helped me a
lot. So sad, he is so young.
Regards
Jidong
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 01/20] net-core: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Ben Hutchings @ 2011-04-06 1:45 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: David Miller, netdev
In-Reply-To: <BANLkTimjYRiMCXEdHfaDaXAn+A0fgZR6ZQ@mail.gmail.com>
On Tue, 2011-04-05 at 18:35 -0700, Mahesh Bandewar wrote:
> On Tue, Apr 5, 2011 at 6:27 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> > On Tue, 2011-04-05 at 17:44 -0700, Mahesh Bandewar wrote:
> >> Converting current use of (hw_/wanted_/vlan_)features to
> >> legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
> > [...]
> >> @@ -1029,44 +1065,51 @@ struct net_device {
> >> struct list_head napi_list;
> >> struct list_head unreg_list;
> >>
> >> +#define DEV_FEATURE_WORDS 2
> >> +#define DEV_FEATURE_BITS (DEV_FEATURE_WORDS*sizeof(long)*BITS_PER_BYTE)
> >> +#define LEGACY_FEATURE_WORD 0
> >> +
> >> /* currently active device features */
> >> - u32 features;
> >> + unsigned long features;
> >> /* user-changeable features */
> >> - u32 hw_features;
> >> + DECLARE_BITMAP(hw_feature, DEV_FEATURE_BITS);
> > [...]
> >
> > Sorry, you can't get rid of hw_features without converting all the
> > callers at the same time. All code has to remain compilable after each
> > single commit.
> >
> I thought I did! My "make allyesconfig; make all" went through. Did I
> miss something?
After 1 commit, or after all 20?
Ben.
--
Ben Hutchings, Senior Software 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: [PATCH 01/20] net-core: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Mahesh Bandewar @ 2011-04-06 1:35 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1302053271.2935.152.camel@localhost>
On Tue, Apr 5, 2011 at 6:27 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Tue, 2011-04-05 at 17:44 -0700, Mahesh Bandewar wrote:
>> Converting current use of (hw_/wanted_/vlan_)features to
>> legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
> [...]
>> @@ -1029,44 +1065,51 @@ struct net_device {
>> struct list_head napi_list;
>> struct list_head unreg_list;
>>
>> +#define DEV_FEATURE_WORDS 2
>> +#define DEV_FEATURE_BITS (DEV_FEATURE_WORDS*sizeof(long)*BITS_PER_BYTE)
>> +#define LEGACY_FEATURE_WORD 0
>> +
>> /* currently active device features */
>> - u32 features;
>> + unsigned long features;
>> /* user-changeable features */
>> - u32 hw_features;
>> + DECLARE_BITMAP(hw_feature, DEV_FEATURE_BITS);
> [...]
>
> Sorry, you can't get rid of hw_features without converting all the
> callers at the same time. All code has to remain compilable after each
> single commit.
>
I thought I did! My "make allyesconfig; make all" went through. Did I
miss something?
> Ben.
>
> --
> Ben Hutchings, Senior Software 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: [PATCH 01/20] net-core: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Ben Hutchings @ 2011-04-06 1:27 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: David Miller, netdev
In-Reply-To: <1302050665-10460-2-git-send-email-maheshb@google.com>
On Tue, 2011-04-05 at 17:44 -0700, Mahesh Bandewar wrote:
> Converting current use of (hw_/wanted_/vlan_)features to
> legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
[...]
> @@ -1029,44 +1065,51 @@ struct net_device {
> struct list_head napi_list;
> struct list_head unreg_list;
>
> +#define DEV_FEATURE_WORDS 2
> +#define DEV_FEATURE_BITS (DEV_FEATURE_WORDS*sizeof(long)*BITS_PER_BYTE)
> +#define LEGACY_FEATURE_WORD 0
> +
> /* currently active device features */
> - u32 features;
> + unsigned long features;
> /* user-changeable features */
> - u32 hw_features;
> + DECLARE_BITMAP(hw_feature, DEV_FEATURE_BITS);
[...]
Sorry, you can't get rid of hw_features without converting all the
callers at the same time. All code has to remain compilable after each
single commit.
Ben.
--
Ben Hutchings, Senior Software 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: [PATCH v3, RESEND 00/16] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-04-06 0:55 UTC (permalink / raw)
To: Trond Myklebust, J. Bruce Fields, Kirill A. Shutemov, Neil Brown,
Pavel Emelyanov
In-Reply-To: <20110302170622.GA4143@shutemov.name>
On Wed, Mar 02, 2011 at 07:06:22PM +0200, Kirill A. Shutemov wrote:
> Any chanse to get it in .39?
What about .40? ;)
Should I rebase it?
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH 18/20] usb-smsc95xx: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Mahesh Bandewar @ 2011-04-06 0:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Mahesh Bandewar
In-Reply-To: <1302050665-10460-18-git-send-email-maheshb@google.com>
Converting current use of (hw_/wanted_/vlan_)features to
legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/usb/smsc95xx.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 708f208..ffdc654 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -933,7 +933,7 @@ static int smsc95xx_reset(struct usbnet *dev)
}
/* Enable or disable checksum offload engines */
- smsc95xx_set_features(dev->net, dev->net->features);
+ smsc95xx_set_features(dev->net, dev->net->legacy_features);
smsc95xx_set_multicast(dev->net);
@@ -1000,11 +1000,11 @@ static int smsc95xx_bind(struct usbnet *dev, struct usb_interface *intf)
spin_lock_init(&pdata->mac_cr_lock);
if (DEFAULT_TX_CSUM_ENABLE)
- dev->net->features |= NETIF_F_HW_CSUM;
+ dev->net->legacy_features |= NETIF_F_HW_CSUM;
if (DEFAULT_RX_CSUM_ENABLE)
- dev->net->features |= NETIF_F_RXCSUM;
+ dev->net->legacy_features |= NETIF_F_RXCSUM;
- dev->net->hw_features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
+ dev->net->legacy_hw_features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
smsc95xx_init_mac_address(dev);
@@ -1079,7 +1079,7 @@ static int smsc95xx_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
/* last frame in this batch */
if (skb->len == size) {
- if (dev->net->features & NETIF_F_RXCSUM)
+ if (dev->net->legacy_features & NETIF_F_RXCSUM)
smsc95xx_rx_csum_offload(skb);
skb_trim(skb, skb->len - 4); /* remove fcs */
skb->truesize = size + sizeof(struct sk_buff);
@@ -1097,7 +1097,7 @@ static int smsc95xx_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
ax_skb->data = packet;
skb_set_tail_pointer(ax_skb, size);
- if (dev->net->features & NETIF_F_RXCSUM)
+ if (dev->net->legacy_features & NETIF_F_RXCSUM)
smsc95xx_rx_csum_offload(ax_skb);
skb_trim(ax_skb, ax_skb->len - 4); /* remove fcs */
ax_skb->truesize = size + sizeof(struct sk_buff);
--
1.7.3.1
^ permalink raw reply related
* [PATCH 17/20] usb-smsc75xx: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Mahesh Bandewar @ 2011-04-06 0:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Mahesh Bandewar
In-Reply-To: <1302050665-10460-17-git-send-email-maheshb@google.com>
Converting current use of (hw_/wanted_/vlan_)features to
legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/usb/smsc75xx.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 860a20c..9c22f04 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -927,7 +927,7 @@ static int smsc75xx_reset(struct usbnet *dev)
netif_dbg(dev, ifup, dev->net, "RFE_CTL set to 0x%08x", pdata->rfe_ctl);
/* Enable or disable checksum offload engines */
- smsc75xx_set_features(dev->net, dev->net->features);
+ smsc75xx_set_features(dev->net, dev->net->legacy_features);
smsc75xx_set_multicast(dev->net);
@@ -1030,15 +1030,15 @@ static int smsc75xx_bind(struct usbnet *dev, struct usb_interface *intf)
INIT_WORK(&pdata->set_multicast, smsc75xx_deferred_multicast_write);
if (DEFAULT_TX_CSUM_ENABLE) {
- dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+ dev->net->legacy_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
if (DEFAULT_TSO_ENABLE)
- dev->net->features |= NETIF_F_SG |
+ dev->net->legacy_features |= NETIF_F_SG |
NETIF_F_TSO | NETIF_F_TSO6;
}
if (DEFAULT_RX_CSUM_ENABLE)
- dev->net->features |= NETIF_F_RXCSUM;
+ dev->net->legacy_features |= NETIF_F_RXCSUM;
- dev->net->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
+ dev->net->legacy_hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_RXCSUM;
/* Init all registers */
@@ -1065,7 +1065,7 @@ static void smsc75xx_unbind(struct usbnet *dev, struct usb_interface *intf)
static void smsc75xx_rx_csum_offload(struct usbnet *dev, struct sk_buff *skb,
u32 rx_cmd_a, u32 rx_cmd_b)
{
- if (!(dev->net->features & NETIF_F_RXCSUM) ||
+ if (!(dev->net->legacy_features & NETIF_F_RXCSUM) ||
unlikely(rx_cmd_a & RX_CMD_A_LCSM)) {
skb->ip_summed = CHECKSUM_NONE;
} else {
--
1.7.3.1
^ permalink raw reply related
* [PATCH 16/20] sunhme: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Mahesh Bandewar @ 2011-04-06 0:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Mahesh Bandewar
In-Reply-To: <1302050665-10460-16-git-send-email-maheshb@google.com>
Converting current use of (hw_/wanted_/vlan_)features to
legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/sunhme.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c
index 80e907d..9d05f86 100644
--- a/drivers/net/sunhme.c
+++ b/drivers/net/sunhme.c
@@ -2788,8 +2788,8 @@ static int __devinit happy_meal_sbus_probe_one(struct platform_device *op, int i
dev->ethtool_ops = &hme_ethtool_ops;
/* Happy Meal can do it all... */
- dev->hw_features = NETIF_F_SG | NETIF_F_HW_CSUM;
- dev->features |= dev->hw_features | NETIF_F_RXCSUM;
+ dev->legacy_hw_features = NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->legacy_features |= dev->legacy_hw_features | NETIF_F_RXCSUM;
dev->irq = op->archdata.irqs[0];
@@ -3114,8 +3114,8 @@ static int __devinit happy_meal_pci_probe(struct pci_dev *pdev,
dev->dma = 0;
/* Happy Meal can do it all... */
- dev->hw_features = NETIF_F_SG | NETIF_F_HW_CSUM;
- dev->features |= dev->hw_features | NETIF_F_RXCSUM;
+ dev->legacy_hw_features = NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->legacy_features |= dev->legacy_hw_features | NETIF_F_RXCSUM;
#if defined(CONFIG_SBUS) && defined(CONFIG_PCI)
/* Hook up PCI register/descriptor accessors. */
--
1.7.3.1
^ permalink raw reply related
* [PATCH 20/20] xen: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Mahesh Bandewar @ 2011-04-06 0:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Mahesh Bandewar
In-Reply-To: <1302050665-10460-20-git-send-email-maheshb@google.com>
Converting current use of (hw_/wanted_/vlan_)features to
legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/xen-netfront.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index db9a763..2b7e5b1 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -193,7 +193,7 @@ static void xennet_sysfs_delif(struct net_device *netdev);
static int xennet_can_sg(struct net_device *dev)
{
- return dev->features & NETIF_F_SG;
+ return dev->legacy_features & NETIF_F_SG;
}
@@ -1247,9 +1247,9 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
netdev->netdev_ops = &xennet_netdev_ops;
netif_napi_add(netdev, &np->napi, xennet_poll, 64);
- netdev->features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
+ netdev->legacy_features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
NETIF_F_GSO_ROBUST;
- netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
+ netdev->legacy_hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
/*
* Assume that all hw features are available for now. This set
@@ -1257,7 +1257,7 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
* xennet_connect() which is the earliest point where we can
* negotiate with the backend regarding supported features.
*/
- netdev->features |= netdev->hw_features;
+ netdev->legacy_features |= netdev->legacy_hw_features;
SET_ETHTOOL_OPS(netdev, &xennet_ethtool_ops);
SET_NETDEV_DEV(netdev, &dev->dev);
--
1.7.3.1
^ permalink raw reply related
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