* Re: [PATCH net-next 2/4] e1000: advertise transmit time stamping
From: Jeff Kirsher @ 2012-07-23 8:18 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Willem de Bruijn, e1000-devel
In-Reply-To: <33885adb6b0e97e6b21fd1903fb6ede3ed7b50ab.1342976654.git.richardcochran@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]
On Sun, 2012-07-22 at 19:15 +0200, Richard Cochran wrote:
> This driver now offers software transmit time stamping, so it should
> advertise that fact via ethtool. Compile tested only.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Cc: e1000-devel@lists.sourceforge.net
> ---
> drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/4] e1000e: advertise transmit time stamping
From: Jeff Kirsher @ 2012-07-23 8:19 UTC (permalink / raw)
To: Richard Cochran; +Cc: Willem, netdev, Bruijn, David Miller, e1000-devel
In-Reply-To: <e0e31f0229b5bfda1684122498b4d6fb3195cf26.1342976654.git.richardcochran@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 567 bytes --]
On Sun, 2012-07-22 at 19:15 +0200, Richard Cochran wrote:
> This driver now offers software transmit time stamping, so it should
> advertise that fact via ethtool. Compile tested only.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Cc: e1000-devel@lists.sourceforge.net
> ---
> drivers/net/ethernet/intel/e1000e/ethtool.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 395 bytes --]
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: flush cache according to 'preferred life time'
From: Gao feng @ 2012-07-23 8:24 UTC (permalink / raw)
To: BALAKUMARAN KANNAN; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A71D24947E78D43BC584A7CD4391A41017DE4C1@SIXPRD0410MB359.apcprd04.prod.outlook.com>
于 2012年07月23日 16:12, BALAKUMARAN KANNAN 写道:
>
> ________________________________________
> From: netdev-owner@vger.kernel.org [netdev-owner@vger.kernel.org] on behalf of Gao feng [gaofeng@cn.fujitsu.com]
> Sent: Monday, July 23, 2012 1:35 PM
> To: BALAKUMARAN KANNAN
> Cc: netdev@vger.kernel.org
> Subject: Re: flush cache according to 'preferred life time'
>
> 于 2012年07月23日 15:36, BALAKUMARAN KANNAN 写道:
>> Hello all,
>> I am running test casees for IPv6 conformation on linux-3.0.26 kernel. Here I am facing a problem in routing advertisement. Once test case sets the 'preferred life time' to 20 seconds for a particular destination. And continuously sending ICMP REQUEST. It is expected that the ICMP_REPLY should stop in 20 seconds. But as because the default gc_interval is 30seconds, even after the timer expiry of the route, it is staying in the router cache. So even after 20 seconds, the nut(node under test) sends ICMP_REPLY. So if I changes gc_interval to 1, the test is getting passed.
>>
>> But if I changes gc_interval to 1 seconds another test case in pmtu section fails. It expects that the nut should hold pmtu(path mtu) information for different value. So if I flushes the cache, the pmtu value is turning back to default.
>>
>> So I made the kernel to alter its gc_interval value according to the 'preferred life time' of the path. Here is my path. Kindly tell me whether my idea is correct. Am I missing something?
>>
>
> Is this commit 1716a96101c49186bb0b8491922fd3e69030235f what you need?
>
>> --------------------------------------------------------------------------------------
>> --- ../linux-3.0.y-BRANCH_SS-RT.git.fresh/net/ipv6/ndisc.c.bak 2012-07-23 12:50:46.000000000 +0530
>> +++ ../linux-3.0.y-BRANCH_SS-RT.git.fresh/net/ipv6/ndisc.c 2012-07-23 12:54:17.000000000 +0530
>> @@ -1160,6 +1160,9 @@
>>
>> __u8 * opt = (__u8 *)(ra_msg + 1);
>>
>> + struct net *net = dev_net(skb->dev);
>> + fib6_run_gc(1, net);
>> +
>> optlen = (skb->tail - skb->transport_header) - sizeof(struct ra_msg);
>>
>> if (!(ipv6_addr_type(&ipv6_hdr(skb)->saddr) & IPV6_ADDR_LINKLOCAL)) {
>> @@ -1200,6 +1203,22 @@
>> return;
>> }
>>
>> + if (*opt == 3) {
>> + printk("<8> IN OPT 3\n");
>> + struct net *net = dev_net(skb->dev);
>> + fib6_run_gc(1, net);
>> + int pref_life_time = ntohl(*((int *) (((char *) (opt)) + 8)));
>> + if ((pref_life_time != 0) && (pref_life_time < 50)) {
>> + printk("<8> gc_interval CHANGED\n");
>> + //init_net.ipv6.sysctl.flush_delay = 1;
>> + init_net.ipv6.sysctl.ip6_rt_gc_interval = 1 * HZ;
>> + }
>> + else {
>> + init_net.ipv6.sysctl.ip6_rt_gc_interval = 30 * HZ;
>> + }
>> +
>> + }
>> +
>> if (!accept_ra(in6_dev))
>> goto skip_linkparms;
>> --------------------------------------------------------------------------------------
>>
>> Note: This is not well structured. I just created it for temparory solution. Just clarify me whether this idea is right.
>>
>> And Please let me know why pmtu value is not stored in routing table but only in cache.
>
> I think the pmtu should be belong to destination.the different destinations may have
> different pmtu,even they use same route entry.
>
> So what you are comming to say, there will not be any entry in routing table for each destination but only in routing cache. So the pmtu value is updated in the cache not in the routing table. thank you. Also I have one more doubt. Is there a way to delete an entry (particular entry) from cache once the corresponding entry in the routing table is expired. As in my case, the routing table entry is expired in 20 seconds. but the cache entry is available till next cache flush. But I want to delete the entry from cache once the entry in routing table is expired. I believe you understand.
>
Yes,I think so too.
> Thank you Geo feng-san for Interest.
I don't know if this commit is what you are finding.
1716a96101c49186bb0b8491922fd3e69030235f
You can test again with this commit.
Thanks
^ permalink raw reply
* RE: flush cache according to 'preferred life time'
From: BALAKUMARAN KANNAN @ 2012-07-23 8:36 UTC (permalink / raw)
To: Gao feng; +Cc: netdev@vger.kernel.org
In-Reply-To: <500D0A24.6060200@cn.fujitsu.com>
Than you Gao-san. Your patch is helpful. I will try that. Also I am facing another problem. Tahi test case section nd test case 145 is failing if gc_interval is 30. The test case is as follows
* The tester node (tn) sends RA with curhoplimit 64
* tn sends a ICMP_REQUEST and checks the ICMP_REPLY from nut is having hoplimit 64. (it is fine in my case)
* Then the tn sends a RA with curhoplimit 0. (It should be ignored)
* Then again tn sends ICMP_REQUEST and checks the ICMP_REPLY from nut whether the hoplimit remains 64 (but it changes to 255 if cache is present. But once I changed the gc_interval to 1, this testcase passes)
Can you please explain what is the reason.
Thank you
--Regards,
K.Balakumaran
^ permalink raw reply
* Re: [PATCH 11/16] ipv4: Cache input routes in fib_info nexthops.
From: Julian Anastasov @ 2012-07-23 9:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120720.142622.1447419081262029885.davem@davemloft.net>
Hello,
On Fri, 20 Jul 2012, David Miller wrote:
>
> Caching input routes is slightly simpler than output routes, since we
> don't need to be concerned with nexthop exceptions. (locally
> destined, and routed packets, never trigger PMTU events or redirects
> that will be processed by us).
>
> However, we have to elide caching for the DIRECTSRC and non-zero itag
> cases.
I see only one user for RTCF_DIRECTSRC:
icmp_address_reply, may be we can do some magic there and
avoid using this flag. By this way we can cache in
nh_rth_input not depending on it.
The problem with rt_iif is worse. May be we
can cache only the first iif, other packets will see
different iif in nh_rth_input and will get non-cached
result. For boxes with 2 or more interfaces only one
can use the cache. One setup can have large traffic
from LAN, other can be server for remote clients.
For forwarding such ambiguity should be lower
and also rt_iif is mostly used for local targets.
> local_input:
> + do_cache = false;
> + if (res.fi) {
> + if (!(flags & RTCF_DIRECTSRC) && !itag) {
> + rth = FIB_RES_NH(res).nh_rth_input;
rt_iif here should be same!!!
> + if (rt_cache_valid(rth)) {
> + dst_use(&rth->dst, jiffies);
> + goto set_and_out;
> + }
> + do_cache = true;
> + }
> + }
> +
> rth = rt_dst_alloc(net->loopback_dev,
> - IN_DEV_CONF_GET(in_dev, NOPOLICY), false, false);
> + IN_DEV_CONF_GET(in_dev, NOPOLICY), false, do_cache);
> if (!rth)
> goto e_nobufs;
>
> @@ -1622,6 +1651,9 @@ local_input:
> rth->dst.error= -err;
> rth->rt_flags &= ~RTCF_LOCAL;
> }
> + if (do_cache)
> + rt_cache_route(&FIB_RES_NH(res), rth);
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [net-next RFC V5 4/5] virtio_net: multiqueue support
From: Sasha Levin @ 2012-07-23 9:28 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, habanero, mashirle, kvm, Michael S. Tsirkin, netdev,
linux-kernel, virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <500CE72B.2040101@redhat.com>
On 07/23/2012 07:54 AM, Jason Wang wrote:
> On 07/21/2012 08:02 PM, Sasha Levin wrote:
>> On 07/20/2012 03:40 PM, Michael S. Tsirkin wrote:
>>>> - err = init_vqs(vi);
>>>>> + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
>>>>> + vi->has_cvq = true;
>>>>> +
>>> How about we disable multiqueue if there's no cvq?
>>> Will make logic a bit simpler, won't it?
>> multiqueues don't really depend on cvq. Does this added complexity really justifies adding an artificial limit?
>>
>
> Yes, it does not depends on cvq. Cvq were just used to negotiate the number of queues a guest wishes to use which is really useful (at least for now). Since multiqueue can not out-perform for single queue in every kinds of workloads or benchmark, so we want to let guest driver use single queue by default even when multiqueue were enabled by management software and let use to enalbe it through ethtool. So user could not feel regression when it switch to use a multiqueue capable driver and backend.
Why would you limit it to a single vq if the user has specified a different number of vqs (>1) in the virtio-net device config?
^ permalink raw reply
* RE: [PATCH] Crash in tun
From: David Laight @ 2012-07-23 9:43 UTC (permalink / raw)
To: Al Viro, David Miller
Cc: mikulas, eric.dumazet, maxk, vtun, netdev, Nicholas A. Bellinger,
linux-sctp
In-Reply-To: <20120721075518.GY31729@ZenIV.linux.org.uk>
> BTW, speaking of struct file treatment related to sockets -
> there's this piece of code in iscsi:
> /*
> * The SCTP stack needs struct socket->file.
> */
> if ((np->np_network_transport == ISCSI_SCTP_TCP) ||
> (np->np_network_transport == ISCSI_SCTP_UDP)) {
> if (!new_sock->file) {
> new_sock->file = kzalloc(
> sizeof(struct file),
> GFP_KERNEL);
>
> For one thing, as far as I can see it'not true - sctp does *not*
> depend on socket->file being non-NULL; it does, in one place,
> check socket->file->f_flags for O_NONBLOCK, but there it treats
> NULL socket->file as "flag no set".
The SCTP code certainly has unconditionally looked at file->f_flags,
we had to allocate a 'struct file' for our in-kernel socket code.
We set sock->file = NULL before the sock_release() call so
hopefully don't suffer the 'side effects'.
David
^ permalink raw reply
* Re: flush cache according to 'preferred life time'
From: Gao feng @ 2012-07-23 9:44 UTC (permalink / raw)
To: BALAKUMARAN KANNAN; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A71D24947E78D43BC584A7CD4391A41017DE4FB@SIXPRD0410MB359.apcprd04.prod.outlook.com>
于 2012年07月23日 16:36, BALAKUMARAN KANNAN 写道:
> Than you Gao-san. Your patch is helpful. I will try that. Also I am facing another problem. Tahi test case section nd test case 145 is failing if gc_interval is 30. The test case is as follows
> * The tester node (tn) sends RA with curhoplimit 64
> * tn sends a ICMP_REQUEST and checks the ICMP_REPLY from nut is having hoplimit 64. (it is fine in my case)
> * Then the tn sends a RA with curhoplimit 0. (It should be ignored)
> * Then again tn sends ICMP_REQUEST and checks the ICMP_REPLY from nut whether the hoplimit remains 64 (but it changes to 255 if cache is present. But once I changed the gc_interval to 1, this testcase passes)
> Can you please explain what is the reason.
>
Hi
Can you test with the last kernel?
Maybe this bug has been fixed too.
Thanks
^ permalink raw reply
* Re: [PATCH] USB: plusb: Add support for PL-2501
From: Sergei Shtylyov @ 2012-07-23 10:25 UTC (permalink / raw)
To: kyak
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.02.1207222138410.1183@bas>
Hello.
On 22-07-2012 21:42, kyak wrote:
> From: Mikhail Peselnik <peselnik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> This patch adds support for PL-2501 by adding the appropriate USB
> ID's. This chip is used in several USB 'Easy Trasfer' Cables.
> Signed-off-by: Mikhail Peselnik <peselnik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Mikhail Peselnik <peselnik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Now with proper sign-offs and right people in cc.
> plusb driver (drivers/net/usb/plusb.c) doesn't recognize PL2501 chip.
> Since PL2501 uses the same code as PL2301/PL2302 (PL2501 works in
> compatibility mode with PL2301/PL2302), the fix is trivial and
> attached as a patch.
> Just to note: the patch is not mine, it can be found here and there on
> Internet.
> I've tested the patch and it works great.
> Thank you.
> --- linux-3.5/drivers/net/usb/plusb.c.orig 2012-07-22
> 21:06:41.905802795 +0400
> +++ linux-3.5/drivers/net/usb/plusb.c 2012-07-22 21:07:00.345552404 +0400
[...]
> @@ -158,5 +161,5 @@ static struct usb_driver plusb_driver =
> module_usb_driver(plusb_driver);
>
> MODULE_AUTHOR("David Brownell");
> -MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
> +MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1/2501 USB Host to Host
> Link Driver");
Your patch is line wrapped. Seeems easy to fix though...
WBR, Sergei
--
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
* Re: [patch net-next] rtnl: do not include num_rx_queues into msg when CONFIG_RPS is not set
From: Jiri Pirko @ 2012-07-23 11:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sfr
In-Reply-To: <20120722.122746.1524911782331447848.davem@davemloft.net>
Sun, Jul 22, 2012 at 09:27:46PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Sun, 22 Jul 2012 09:26:42 +0200
>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>Jiri, I've been patiently waiting for you to ACK Mark A. Greear's
>patch fixing this bug, did you not see it at all?
Oh I missed that. That email somehow skipped my inbox and went only to
ml folder...
>
>http://patchwork.ozlabs.org/patch/172393/
>
>I'm just going to apply it since you're not watching for fixes
>for code you've changed.
^ permalink raw reply
* Re: [PATCH] net, cgroup: Fix boot failure due to iteration of uninitialized list
From: Neil Horman @ 2012-07-23 11:40 UTC (permalink / raw)
To: Gao feng
Cc: Srivatsa S. Bhat, eric.dumazet, davem, linux-kernel, netdev,
mark.d.rustad, john.r.fastabend, lizefan
In-Reply-To: <500CA599.6030907@cn.fujitsu.com>
On Mon, Jul 23, 2012 at 09:15:05AM +0800, Gao feng wrote:
> 于 2012年07月20日 00:27, Srivatsa S. Bhat 写道:
> > After commit ef209f15 (net: cgroup: fix access the unallocated memory in
> > netprio cgroup), boot fails with the following NULL pointer dereference:
> >
> > Initializing cgroup subsys devices
> > Initializing cgroup subsys freezer
> > Initializing cgroup subsys net_cls
> > Initializing cgroup subsys blkio
> > Initializing cgroup subsys perf_event
> > Initializing cgroup subsys net_prio
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000698
> > IP: [<ffffffff8145e8d6>] cgrp_create+0xf6/0x190
> > PGD 0
> > Oops: 0000 [#1] SMP
> > CPU 0
> > Modules linked in:
> >
> > Pid: 0, comm: swapper/0 Not tainted 3.5.0-rc7-mandeep #1 IBM IBM System x -[7870C4Q]-/68Y8033
> > RIP: 0010:[<ffffffff8145e8d6>] [<ffffffff8145e8d6>] cgrp_create+0xf6/0x190
> > RSP: 0000:ffffffff81a01ea8 EFLAGS: 00010213
> > RAX: 0000000000000000 RBX: ffffffffffffff10 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffffffff81aa70a0
> > RBP: ffffffff81a01ed8 R08: 0000000000000000 R09: 0000000000000000
> > R10: ffff8808ff8641c0 R11: 6e697a696c616974 R12: 0000000000000001
> > R13: ffff8808ff8641c0 R14: 0000000000000000 R15: 0000000000093970
> > FS: 0000000000000000(0000) GS:ffff8808ffc00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 0000000000000698 CR3: 0000000001a0b000 CR4: 00000000000006b0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420)
> > Stack:
> > ffffffff81a01eb8 ffffffff818060ff ffffffff81d75ec8 ffffffff81aa8960
> > ffffffff81aa8960 ffffffff81b4c2c0 ffffffff81a01ef8 ffffffff81b1cb78
> > 0000000000000018 0000000000000048 ffffffff81a01f18 ffffffff81b1ce13
> > Call Trace:
> > [<ffffffff81b1cb78>] cgroup_init_subsys+0x83/0x169
> > [<ffffffff81b1ce13>] cgroup_init+0x36/0x119
> > [<ffffffff81affef7>] start_kernel+0x3ba/0x3ef
> > [<ffffffff81aff95b>] ? kernel_init+0x27b/0x27b
> > [<ffffffff81aff356>] x86_64_start_reservations+0x131/0x136
> > [<ffffffff81aff45e>] x86_64_start_kernel+0x103/0x112
> > Code: 01 48 3d f8 e1 ec 81 48 8d 98 10 ff ff ff 75 1b eb 73 0f 1f 00 48 8b 83 f0 00 00 00 48 3d f8 e1 ec 81 48 8d 98 10 ff ff ff 74 5a <48> 8b 83 88 07 00 00 48 85 c0 74 de 44 3b 60 10 76 d8 44 89 e6
> > RIP [<ffffffff8145e8d6>] cgrp_create+0xf6/0x190
> > RSP <ffffffff81a01ea8>
> > CR2: 0000000000000698
> > ---[ end trace a7919e7f17c0a725 ]---
> > Kernel panic - not syncing: Attempted to kill the idle task!
> >
> > The code corresponds to:
> >
> > update_netdev_tables():
> > for_each_netdev(&init_net, dev) {
> > map = rtnl_dereference(dev->priomap); <---- HERE
> >
> >
> > The list head is initialized in netdev_init(), which is called much
> > later than cgrp_create(). So the problem is that we are calling
> > update_netdev_tables() way too early (in cgrp_create()), which will
> > end up traversing the not-yet-circular linked list. So at some point,
> > the dev pointer will become NULL and hence dev->priomap becomes an
> > invalid access.
> >
> > To fix this, just remove the update_netdev_tables() function entirely,
> > since it appears that write_update_netdev_table() will handle things
> > just fine.
>
> The reason I add update_netdev_tables in cgrp_create is to avoid additional
> bound checkings when we accessing the dev->priomap.priomap.
>
> Eric,can we revert this commit 91c68ce2b26319248a32d7baa1226f819d283758 now?
> I think it's safe enough to access priomap without bound check.
>
> Thanks
>
I think its probably safe, yes, but lets leave it there for just a bit. Its not
hurting anything, and I'd like to look into getting Srivatsa' patch in first.
Neil
^ permalink raw reply
* [PATCH] USB: plusb: Add support for PL-2501
From: kyak @ 2012-07-23 11:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Sergei Shtylyov, linux-usb, netdev, Greg Kroah-Hartman
From: Mikhail Peselnik <peselnik@gmail.com>
This patch adds support for PL-2501 by adding the appropriate USB
ID's. This chip is used in several USB 'Easy Trasfer' Cables.
Signed-off-by: Mikhail Peselnik <peselnik@gmail.com>
Tested-by: Mikhail Peselnik <peselnik@gmail.com>
---
Now with proper sign-offs and right people in cc and unwrapped lines.
plusb driver (drivers/net/usb/plusb.c) doesn't recognize PL2501 chip.
Since PL2501 uses the same code as PL2301/PL2302 (PL2501 works in
compatibility mode with PL2301/PL2302), the fix is trivial and
attached as a patch.
Just to note: the patch is not mine, it can be found here and there on
Internet.
I've tested the patch and it works great.
Thank you.
--- linux-3.5/drivers/net/usb/plusb.c.orig 2012-07-22 21:06:41.905802795 +0400
+++ linux-3.5/drivers/net/usb/plusb.c 2012-07-22 21:07:00.345552404 +0400
@@ -107,7 +107,7 @@ static int pl_reset(struct usbnet *dev)
}
static const struct driver_info prolific_info = {
- .description = "Prolific PL-2301/PL-2302/PL-25A1",
+ .description = "Prolific PL-2301/PL-2302/PL-25A1/PL-2501",
.flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset = pl_reset,
@@ -139,6 +139,9 @@ static const struct usb_device_id produc
}, {
USB_DEVICE(0x050d, 0x258a), /* Belkin F5U258/F5U279 (PL-25A1) */
.driver_info = (unsigned long) &prolific_info,
+}, {
+ USB_DEVICE(0x067b, 0x2501), /* PL-2501 */
+ .driver_info = (unsigned long) &prolific_info,
},
{ }, // END
@@ -158,5 +161,5 @@ static struct usb_driver plusb_driver =
module_usb_driver(plusb_driver);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1/2501 USB Host to Host Link Driver");
MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Neil Horman @ 2012-07-23 12:14 UTC (permalink / raw)
To: xufeng zhang
Cc: xufengzhang.main, vyasevich, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <500CB74A.4040300@windriver.com>
On Mon, Jul 23, 2012 at 10:30:34AM +0800, xufeng zhang wrote:
> On 07/23/2012 08:49 AM, Neil Horman wrote:
> >
> >Not sure I understand how you came into this error. If we get an invalid
> >stream, we issue an SCTP_REPORT_TSN side effect, followed by an SCTP_CMD_REPLY
> >which sends the error chunk. The reply goes through
> >sctp_outq_tail->sctp_outq_chunk->sctp_outq_transmit_chunk->sctp_outq_append_chunk.
> >That last function checks to see if a sack is already part of the packet, and if
> >there isn't one, appends one, using the updated tsn map.
> Yes, you are right, but consider the invalid stream identifier's
> DATA chunk is the first
> DATA chunk in the association which will need SACK immediately.
> Here is what I thought of the scenario:
> sctp_sf_eat_data_6_2()
> -->sctp_eat_data()
> -->sctp_make_op_error()
> -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(err))
> -->sctp_outq_tail() /* First enqueue ERROR chunk */
> -->sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, SCTP_FORCE())
> -->sctp_gen_sack()
> -->sctp_make_sack()
> -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> SCTP_CHUNK(sack))
> -->sctp_outq_tail() /* Then enqueue SACK chunk */
>
> So SACK chunk is enqueued after ERROR chunk.
Ah, I see. Since the ERROR and SACK chunks are both control chunks, and since
we explicitly add the SACK to the control queue instead of going through the
bundle path in sctp_packet_append_chunk the ordering gets wrong.
Ok, so the problem makes sense. I think the soultion could be alot easier
though. IIRC SACK chunks always live at the head of a packet, so why not just
special case it in sctp_outq_tail? I.e. instead of doing a list_add_tail, in
the else clause of sctp_outq_tail check the chunk_hdr->type to see if its
SCTP_CID_SACK. If it is, use list_add_head rather than list_add_tail. I think
that will fix up both the COOKIE_ECHO and ESTABLISHED cases, won't it? And then
you won't have keep track of extra state in the packet configuration.
Regards
Neil
^ permalink raw reply
* Re: [PATCH net-next V1 6/9] net/eipoib: Add sysfs support
From: Or Gerlitz @ 2012-07-23 12:55 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, ali, sean.hefty, shlomop, Erez Shitrit
In-Reply-To: <1342609202-32427-7-git-send-email-ogerlitz@mellanox.com>
On 7/18/2012 1:59 PM, Or Gerlitz wrote:
> The management interface for the driver uses sysfs entries. Via these sysfs entries the driver gets details on new VIF's to manage. The driver can enslave new VIF (IPoIB cloned interface) or detaches from it. Here are few sysfs commands that are used in order to manage the driver, according to few scenarios:
>
> 1. create new clone of IPoIB interface:
> $ echo .Y > /sys/class/net/ibX/create_child
> create new clone ibX.Y with the same pkey as ibX, for example:
> $ echo .1 > /sys/class/net/ib0/create_child
> will create new interface ib0.1
>
> 2. notify parent interface on new VIF to enslave:
> $ echo +ibX.Y > /sys/class/net/ethZ/eth/slaves
> where ethZ is the driver interface, for example:
> $ echo +ib0.1 > /sys/class/net/eth4/eth/slaves
> will enslave ib0.1 to eth4
>
> 3. notify parent interface interface on VIF details (mac and vlan)
> $ echo +ibX.Y <MAC address> > /sys/class/net/ethZ/eth/vifs
> for example:
> $ echo +ib0.1 00:02:c9:43:3b:f1 > /sys/class/net/eth4/eth/vifs
Hi Dave,
Following the comment you made on patch 1/9 we are modifying operations
#1 - create/delete clone of IPoIB device -- changed to use rtnl_link_ops
#2 - enslave/un-enslave a IPoIB device clone to eIPoIB device -- changed
to support ndo_add_slave/ndo_delete_slave on eIPoIB
re #3, which is to create association which we call a VIF within the
eIPoIB driver between an IPoIB slave to mac and vlan, we used sysfs as
you can see above, and I wanted to ask re the correct way to do that.
One option which we consider, is to add new ndo operation ndo_add_vif to
be supported by eIPoIB and call it from new netlink channel
ifla_vif_mac_vlan, makes sense?
Or.
>
>
> 4. notify parent to release VIF:
>
> $ echo -ibX.Y > /sys/class/net/ethZ/eth/slaves
>
> where ethZ is the driver interface, for example:
>
> $ echo -ib0.1 > /sys/class/net/eth4/eth/slaves
>
> will release ib0.1 from eth4
>
> 5. see the list of ipoib interfaces enslaved under eipoib interface,
>
> $ cat /sys/class/net/ethX/eth/vifs
>
> for example:
>
> $ cat /sys/class/net/eth4/eth/vifs
>
> SLAVE=ib0.1 MAC=9a:c2:1f:d7:3b:63 VLAN=N/A
> SLAVE=ib0.2 MAC=52:54:00:60:55:88 VLAN=N/A
> SLAVE=ib0.3 MAC=52:54:00:60:55:89 VLAN=N/A
>
> Signed-off-by: Erez Shitrit <erezsh@mellanox.co.il>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> drivers/net/eipoib/eth_ipoib_sysfs.c | 640 ++++++++++++++++++++++++++++++++++
> 1 files changed, 640 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/eipoib/eth_ipoib_sysfs.c
>
> diff --git a/drivers/net/eipoib/eth_ipoib_sysfs.c b/drivers/net/eipoib/eth_ipoib_sysfs.c
> new file mode 100644
> index 0000000..c3fc121
> --- /dev/null
> +++ b/drivers/net/eipoib/eth_ipoib_sysfs.c
> @@ -0,0 +1,640 @@
> +/*
> + * Copyright (c) 2012 Mellanox Technologies. All rights reserved
> + *
> + * This software is available to you under a choice of one of two
> + * licenses. You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * openfabric.org BSD license below:
> + *
> + * Redistribution and use in source and binary forms, with or
> + * without modification, are permitted provided that the following
> + * conditions are met:
> + *
> + * - Redistributions of source code must retain the above
> + * copyright notice, this list of conditions and the following
> + * disclaimer.
> + *
> + * - Redistributions in binary form must reproduce the above
> + * copyright notice, this list of conditions and the following
> + * disclaimer in the documentation and/or other materials
> + * provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/sched.h>
> +#include <linux/fs.h>
> +#include <linux/types.h>
> +#include <linux/string.h>
> +#include <linux/netdevice.h>
> +#include <linux/inetdevice.h>
> +#include <linux/in.h>
> +#include <linux/sysfs.h>
> +#include <linux/ctype.h>
> +#include <linux/inet.h>
> +#include <linux/rtnetlink.h>
> +#include <linux/etherdevice.h>
> +#include <net/net_namespace.h>
> +
> +#include "eth_ipoib.h"
> +
> +#define to_dev(obj) container_of(obj, struct device, kobj)
> +#define to_parent(cd) ((struct parent *)(netdev_priv(to_net_dev(cd))))
> +#define MOD_NA_STRING "N/A"
> +
> +#define _sprintf(p, buf, format, arg...) \
> +((PAGE_SIZE - (int)(p - buf)) <= 0 ? 0 : \
> + scnprintf(p, PAGE_SIZE - (int)(p - buf), format, ## arg))\
> +
> +#define _end_of_line(_p, _buf) \
> +do { if (_p - _buf) /* eat the leftover space */ \
> + buf[_p - _buf - 1] = '\n'; \
> +} while (0)
> +
> +/* helper functions */
> +static int get_emac(u8 *mac, char *s)
> +{
> + if (sscanf(s, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx",
> + mac + 0, mac + 1, mac + 2, mac + 3, mac + 4,
> + mac + 5) != 6)
> + return -1;
> +
> + return 0;
> +}
> +
> +static int get_imac(u8 *mac, char *s)
> +{
> + if (sscanf(s, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx:%hhx:%hhx:"
> + "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx:%hhx:%hhx:"
> + "%hhx:%hhx:%hhx:%hhx",
> + mac + 0, mac + 1, mac + 2, mac + 3, mac + 4,
> + mac + 5, mac + 6, mac + 7, mac + 8, mac + 9,
> + mac + 10, mac + 11, mac + 12, mac + 13,
> + mac + 14, mac + 15, mac + 16, mac + 17,
> + mac + 18, mac + 19) != 20)
> + return -1;
> +
> + return 0;
> +}
> +
> +/* show/store functions per module (CLASS_ATTR) */
> +static ssize_t show_parents(struct class *cls, struct class_attribute *attr,
> + char *buf)
> +{
> + char *p = buf;
> + struct parent *parent;
> +
> + rtnl_lock(); /* because of parent_dev_list */
> +
> + list_for_each_entry(parent, &parent_dev_list, parent_list) {
> + p += _sprintf(p, buf, "%s over IB port: %s\n",
> + parent->dev->name,
> + parent->ipoib_main_interface);
> + }
> + _end_of_line(p, buf);
> +
> + rtnl_unlock();
> + return (ssize_t)(p - buf);
> +}
> +
> +/* show/store functions per parent (DEVICE_ATTR) */
> +static ssize_t parent_show_neighs(struct device *d,
> + struct device_attribute *attr, char *buf)
> +{
> + struct slave *slave;
> + struct neigh *neigh;
> + struct parent *parent = to_parent(d);
> + char *p = buf;
> +
> + read_lock_bh(&parent->lock);
> + parent_for_each_slave(parent, slave) {
> + list_for_each_entry(neigh, &slave->neigh_list, list) {
> + p += _sprintf(p, buf, "SLAVE=%-10s EMAC=%pM IMAC=%pM:%pM:%pM:%.2x:%.2x\n",
> + slave->dev->name,
> + neigh->emac,
> + neigh->imac, neigh->imac + 6, neigh->imac + 12,
> + neigh->imac[18], neigh->imac[19]);
> + }
> + }
> +
> + read_unlock_bh(&parent->lock);
> +
> + _end_of_line(p, buf);
> +
> + return (ssize_t)(p - buf);
> +}
> +
> +struct neigh *parent_get_neigh_cmd(char op,
> + char *ifname, u8 *remac, u8 *rimac)
> +{
> + struct neigh *neigh_cmd;
> +
> + neigh_cmd = kzalloc(sizeof *neigh_cmd, GFP_ATOMIC);
> + if (!neigh_cmd) {
> + pr_err("%s cannot allocate neigh struct\n", ifname);
> + goto out;
> + }
> +
> + /*
> + * populate emac field so it can be used easily
> + * in neigh_cmd_find_by_mac()
> + */
> + memcpy(neigh_cmd->emac, remac, ETH_ALEN);
> + memcpy(neigh_cmd->imac, rimac, INFINIBAND_ALEN);
> +
> + /* prepare the command as a string */
> + sprintf(neigh_cmd->cmd, "%c%s %pM %pM:%pM:%pM:%.2x:%.2x",
> + op, ifname, remac, rimac, rimac + 6, rimac + 12, rimac[18], rimac[19]);
> +out:
> + return neigh_cmd;
> +}
> +
> +/* write_lock_bh(&parent->lock) must be held */
> +ssize_t __parent_store_neighs(struct device *d,
> + struct device_attribute *attr,
> + const char *buffer, size_t count)
> +{
> + char command[IFNAMSIZ + 1] = { 0, };
> + char emac_str[ETH_ALEN * 3] = { 0, };
> + u8 emac[ETH_ALEN];
> + char imac_str[INFINIBAND_ALEN * 3] = { 0, };
> + u8 imac[INFINIBAND_ALEN];
> + char *ifname;
> + int found = 0, ret = count;
> + struct slave *slave = NULL, *slave_tmp;
> + struct neigh *neigh;
> + struct parent *parent = to_parent(d);
> +
> + sscanf(buffer, "%s %s %s", command, emac_str, imac_str);
> +
> + /* check ifname */
> + ifname = command + 1;
> + if ((strlen(command) <= 1) || !dev_valid_name(ifname) ||
> + (command[0] != '+' && command[0] != '-'))
> + goto err_no_cmd;
> +
> + /* check if ifname exist */
> + parent_for_each_slave(parent, slave_tmp) {
> + if (!strcmp(slave_tmp->dev->name, ifname)) {
> + found = 1;
> + slave = slave_tmp;
> + }
> + }
> +
> + if (!found) {
> + pr_err("%s could not find slave\n", ifname);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + if (get_emac(emac, emac_str)) {
> + pr_err("%s bad emac %s\n", ifname, emac_str);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + if (get_imac(imac, imac_str)) {
> + pr_err("%s bad imac %s\n", ifname, imac_str);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* process command */
> + if (command[0] == '+') {
> + found = 0;
> + list_for_each_entry(neigh, &slave->neigh_list, list) {
> + if (!memcmp(neigh->emac, emac, ETH_ALEN))
> + found = 1;
> + }
> +
> + if (found) {
> + pr_err("%s: cannot update neigh, slave already has "
> + "this neigh mac %pM\n",
> + slave->dev->name, emac);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + neigh = kzalloc(sizeof *neigh, GFP_ATOMIC);
> + if (!neigh) {
> + pr_err("%s cannot allocate neigh struct\n",
> + slave->dev->name);
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + /* ready to go */
> + pr_info("%s: slave %s neigh mac is set to %pM\n",
> + ifname, parent->dev->name, emac);
> + memcpy(neigh->emac, emac, ETH_ALEN);
> + memcpy(neigh->imac, imac, INFINIBAND_ALEN);
> +
> + list_add_tail(&neigh->list, &slave->neigh_list);
> +
> + goto out;
> + }
> +
> + if (command[0] == '-') {
> + found = 0;
> + list_for_each_entry(neigh, &slave->neigh_list, list) {
> + if (!memcmp(neigh->emac, emac, ETH_ALEN))
> + found = 1;
> + }
> +
> + if (!found) {
> + pr_err("%s cannot delete neigh mac %pM\n",
> + ifname, emac);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + list_del(&neigh->list);
> + kfree(neigh);
> +
> + goto out;
> + }
> +
> +err_no_cmd:
> + pr_err("%s USAGE: (-|+)ifname emac imac\n", DRV_NAME);
> + ret = -EPERM;
> +
> +out:
> + return ret;
> +}
> +
> +static ssize_t parent_store_neighs(struct device *d,
> + struct device_attribute *attr,
> + const char *buffer, size_t count)
> +{
> + struct parent *parent = to_parent(d);
> + ssize_t rc;
> +
> + write_lock_bh(&parent->lock);
> + rc = __parent_store_neighs(d, attr, buffer, count);
> + write_unlock_bh(&parent->lock);
> +
> + return rc;
> +}
> +
> +static DEVICE_ATTR(neighs, S_IRUGO | S_IWUSR, parent_show_neighs,
> + parent_store_neighs);
> +
> +static ssize_t parent_show_vifs(struct device *d,
> + struct device_attribute *attr, char *buf)
> +{
> + struct slave *slave;
> + struct parent *parent = to_parent(d);
> + char *p = buf;
> +
> + read_lock_bh(&parent->lock);
> + parent_for_each_slave(parent, slave) {
> + if (is_zero_ether_addr(slave->emac)) {
> + p += _sprintf(p, buf, "SLAVE=%-10s MAC=%-17s "
> + "VLAN=%s\n", slave->dev->name,
> + MOD_NA_STRING, MOD_NA_STRING);
> + } else if (slave->vlan == VLAN_N_VID) {
> + p += _sprintf(p, buf, "SLAVE=%-10s MAC=%pM VLAN=%s\n",
> + slave->dev->name,
> + slave->emac,
> + MOD_NA_STRING);
> + } else {
> + p += _sprintf(p, buf, "SLAVE=%-10s MAC=%pM VLAN=%d\n",
> + slave->dev->name,
> + slave->emac,
> + slave->vlan);
> + }
> + }
> + read_unlock_bh(&parent->lock);
> +
> + _end_of_line(p, buf);
> +
> + return (ssize_t)(p - buf);
> +}
> +
> +static ssize_t parent_store_vifs(struct device *d,
> + struct device_attribute *attr,
> + const char *buffer, size_t count)
> +{
> + char command[IFNAMSIZ + 1] = { 0, };
> + char mac_str[ETH_ALEN * 3] = { 0, };
> + char *ifname;
> + u8 mac[ETH_ALEN];
> + int found = 0, ret = count;
> + struct slave *slave = NULL, *slave_tmp;
> + struct parent *parent = to_parent(d);
> +
> + sscanf(buffer, "%s %s", command, mac_str);
> +
> + write_lock_bh(&parent->lock);
> +
> + /* check ifname */
> + ifname = command + 1;
> + if ((strlen(command) <= 1) || !dev_valid_name(ifname) ||
> + (command[0] != '+' && command[0] != '-'))
> + goto err_no_cmd;
> +
> + /* check if ifname exist */
> + parent_for_each_slave(parent, slave_tmp) {
> + if (!strcmp(slave_tmp->dev->name, ifname)) {
> + found = 1;
> + slave = slave_tmp;
> + }
> + }
> +
> + if (!found) {
> + pr_err("%s could not find slave\n", ifname);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* process command */
> + if (command[0] == '+') {
> + if (get_emac(mac, mac_str) || !is_valid_ether_addr(mac)) {
> + pr_err("%s invalid mac input\n", ifname);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + if (!is_zero_ether_addr(slave->emac)) {
> + pr_err("%s slave %s mac already set to %pM\n",
> + ifname, slave->dev->name, slave->emac);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* check another slave has this mac/vlan */
> + found = 0;
> + parent_for_each_slave(parent, slave_tmp) {
> + if (!memcmp(slave_tmp->emac, mac, ETH_ALEN) &&
> + slave_tmp->vlan == slave->vlan) {
> + pr_err("cannot update %s, slave %s already has"
> + " vlan 0x%x mac %pM\n",
> + parent->dev->name, slave->dev->name,
> + slave_tmp->vlan,
> + mac);
> + ret = -EINVAL;
> + goto out;
> + }
> + }
> +
> + /* ready to go */
> + pr_info("slave %s mac is set to %pM\n",
> + ifname, mac);
> +
> + memcpy(slave->emac, mac, ETH_ALEN);
> + goto out;
> + }
> +
> + if (command[0] == '-') {
> + if (is_zero_ether_addr(slave->emac)) {
> + pr_err("%s slave mac already unset %pM\n",
> + ifname, slave->emac);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + pr_info("slave %s mac is unset (was %pM)\n",
> + ifname, slave->emac);
> +
> + goto out;
> + }
> +
> +err_no_cmd:
> + pr_err("%s USAGE: (-|+)ifname [mac]\n", DRV_NAME);
> + ret = -EPERM;
> +
> +out:
> + write_unlock_bh(&parent->lock);
> +
> + return ret;
> +}
> +
> +static DEVICE_ATTR(vifs, S_IRUGO | S_IWUSR, parent_show_vifs,
> + parent_store_vifs);
> +
> +static ssize_t parent_show_slaves(struct device *d,
> + struct device_attribute *attr, char *buf)
> +{
> + struct slave *slave;
> + struct parent *parent = to_parent(d);
> + char *p = buf;
> +
> + read_lock_bh(&parent->lock);
> + parent_for_each_slave(parent, slave)
> + p += _sprintf(p, buf, "%s\n", slave->dev->name);
> + read_unlock_bh(&parent->lock);
> +
> + _end_of_line(p, buf);
> +
> + return (ssize_t)(p - buf);
> +}
> +
> +static ssize_t parent_store_slaves(struct device *d,
> + struct device_attribute *attr,
> + const char *buffer, size_t count)
> +{
> + char command[IFNAMSIZ + 1] = { 0, };
> + char *ifname;
> + int res, ret = count;
> + struct slave *slave;
> + struct net_device *dev = NULL;
> + struct parent *parent = to_parent(d);
> +
> + /* Quick sanity check -- is the parent interface up? */
> + if (!(parent->dev->flags & IFF_UP)) {
> + pr_warn("%s: doing slave updates when "
> + "interface is down.\n", dev->name);
> + }
> +
> + if (!rtnl_trylock()) /* because __dev_get_by_name */
> + return restart_syscall();
> +
> + sscanf(buffer, "%16s", command);
> +
> + ifname = command + 1;
> + if ((strlen(command) <= 1) || !dev_valid_name(ifname))
> + goto err_no_cmd;
> +
> + if (command[0] == '+') {
> + /* Got a slave name in ifname. Is it already in the list? */
> + dev = __dev_get_by_name(&init_net, ifname);
> + if (!dev) {
> + pr_warn("%s: Interface %s does not exist!\n",
> + parent->dev->name, ifname);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + read_lock_bh(&parent->lock);
> + parent_for_each_slave(parent, slave) {
> + if (slave->dev == dev) {
> + pr_err("%s ERR- Interface %s is already enslaved!\n",
> + parent->dev->name, dev->name);
> + ret = -EPERM;
> + }
> + }
> + read_unlock_bh(&parent->lock);
> +
> + if (ret < 0)
> + goto out;
> +
> + pr_info("%s: adding slave %s\n",
> + parent->dev->name, ifname);
> +
> + res = parent_enslave(parent->dev, dev);
> + if (res)
> + ret = res;
> +
> + goto out;
> + }
> +
> + if (command[0] == '-') {
> + dev = NULL;
> + parent_for_each_slave(parent, slave)
> + if (strnicmp(slave->dev->name, ifname, IFNAMSIZ) == 0) {
> + dev = slave->dev;
> + break;
> + }
> +
> + if (dev) {
> + pr_info("%s: removing slave %s\n",
> + parent->dev->name, dev->name);
> + res = parent_release_slave(parent->dev, dev);
> + if (res) {
> + ret = res;
> + goto out;
> + }
> + } else {
> + pr_warn("%s: unable to remove non-existent "
> + "slave for parent %s.\n",
> + ifname, parent->dev->name);
> + ret = -ENODEV;
> + }
> + goto out;
> + }
> +
> +err_no_cmd:
> + pr_err("%s USAGE: (-|+)ifname\n", DRV_NAME);
> + ret = -EPERM;
> +
> +out:
> + rtnl_unlock();
> + return ret;
> +}
> +
> +static DEVICE_ATTR(slaves, S_IRUGO | S_IWUSR, parent_show_slaves,
> + parent_store_slaves);
> +
> +/* sysfs create/destroy functions */
> +static struct attribute *per_parent_attrs[] = {
> + &dev_attr_slaves.attr, /* DEVICE_ATTR(slaves..) */
> + &dev_attr_vifs.attr,
> + &dev_attr_neighs.attr,
> + NULL,
> +};
> +
> +/* name spcase support */
> +static const void *eipoib_namespace(struct class *cls,
> + const struct class_attribute *attr)
> +{
> + const struct eipoib_net *eipoib_n =
> + container_of(attr,
> + struct eipoib_net, class_attr_eipoib_interfaces);
> + return eipoib_n->net;
> +}
> +
> +static struct attribute_group parent_group = {
> + /* per parent sysfs files under: /sys/class/net/<IF>/eth/.. */
> + .name = "eth",
> + .attrs = per_parent_attrs
> +};
> +
> +int create_slave_symlinks(struct net_device *master,
> + struct net_device *slave)
> +{
> + char linkname[IFNAMSIZ+7];
> + int ret = 0;
> +
> + ret = sysfs_create_link(&(slave->dev.kobj), &(master->dev.kobj),
> + "eth_parent");
> + if (ret)
> + return ret;
> +
> + sprintf(linkname, "slave_%s", slave->name);
> + ret = sysfs_create_link(&(master->dev.kobj), &(slave->dev.kobj),
> + linkname);
> + return ret;
> +
> +}
> +
> +void destroy_slave_symlinks(struct net_device *master,
> + struct net_device *slave)
> +{
> + char linkname[IFNAMSIZ+7];
> +
> + sysfs_remove_link(&(slave->dev.kobj), "eth_parent");
> + sprintf(linkname, "slave_%s", slave->name);
> + sysfs_remove_link(&(master->dev.kobj), linkname);
> +}
> +
> +static struct class_attribute class_attr_eth_ipoib_interfaces = {
> + .attr = {
> + .name = "eth_ipoib_interfaces",
> + .mode = S_IWUSR | S_IRUGO,
> + },
> + .show = show_parents,
> + .namespace = eipoib_namespace,
> +};
> +
> +/* per module sysfs file under: /sys/class/net/eth_ipoib_interfaces */
> +int mod_create_sysfs(struct eipoib_net *eipoib_n)
> +{
> + int rc;
> + /* defined in CLASS_ATTR(eth_ipoib_interfaces..) */
> + eipoib_n->class_attr_eipoib_interfaces =
> + class_attr_eth_ipoib_interfaces;
> +
> + sysfs_attr_init(&eipoib_n->class_attr_eipoib_interfaces.attr);
> +
> + rc = netdev_class_create_file(&eipoib_n->class_attr_eipoib_interfaces);
> + if (rc)
> + pr_err("%s failed to create sysfs (rc %d)\n",
> + eipoib_n->class_attr_eipoib_interfaces.attr.name, rc);
> +
> + return rc;
> +}
> +
> +void mod_destroy_sysfs(struct eipoib_net *eipoib_n)
> +{
> + netdev_class_remove_file(&eipoib_n->class_attr_eipoib_interfaces);
> +}
> +
> +int parent_create_sysfs_entry(struct parent *parent)
> +{
> + struct net_device *dev = parent->dev;
> + int rc;
> +
> + rc = sysfs_create_group(&(dev->dev.kobj), &parent_group);
> + if (rc)
> + pr_info("failed to create sysfs group\n");
> +
> + return rc;
> +}
> +
> +void parent_destroy_sysfs_entry(struct parent *parent)
> +{
> + struct net_device *dev = parent->dev;
> +
> + sysfs_remove_group(&(dev->dev.kobj), &parent_group);
> +}
^ permalink raw reply
* Re: [PATCH] mlx4: Add support for EEH error recovery
From: Kleber Sacilotto de Souza @ 2012-07-23 13:18 UTC (permalink / raw)
To: David Miller; +Cc: ogerlitz, netdev, jackm, yevgenyp, cascardo, brking, shlomop
In-Reply-To: <20120722.171553.2139258607165498367.davem@davemloft.net>
On 07/22/2012 09:15 PM, David Miller wrote:
> From: Or Gerlitz <ogerlitz@mellanox.com>
> Date: Sun, 22 Jul 2012 13:26:32 +0300
>
>> is there anything in the code you added which maybe implicitly
>> assumes PPC arch?
>
> He implemented support for a standard PCI API in the kernel, he
> happened to test it on a particular platform, and I think that's
> the long and short of it.
>
Exactly. The callbacks implemented are from standard PCI error recovery
(Documentation/PCI/pci-error-recovery.txt) and the changes doesn't
assume any platform in specific. The code was tested only on powerpc
systems since I don't have any mlx4 card on other platforms, however,
these changes shouldn't make the error recover any worse than the
current state.
--
Kleber Sacilotto de Souza
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH net-next 4/4] forcedeth: advertise transmit time stamping
From: Willem de Bruijn @ 2012-07-23 13:27 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller
In-Reply-To: <d95c3b5bf30e3a7d056ad7f9fb774bbf572dc217.1342976654.git.richardcochran@gmail.com>
On Sun, Jul 22, 2012 at 1:15 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> This driver now offers software transmit time stamping, so it should
> advertise that fact via ethtool. Compile tested only.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Acked-by: Willem de Bruijn <willemb@google.com>
> Cc: Willem de Bruijn <willemb@google.com>
> ---
> drivers/net/ethernet/nvidia/forcedeth.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
> index 67edc2e..f45def0 100644
> --- a/drivers/net/ethernet/nvidia/forcedeth.c
> +++ b/drivers/net/ethernet/nvidia/forcedeth.c
> @@ -5182,6 +5182,7 @@ static const struct ethtool_ops ops = {
> .get_ethtool_stats = nv_get_ethtool_stats,
> .get_sset_count = nv_get_sset_count,
> .self_test = nv_self_test,
> + .get_ts_info = ethtool_op_get_ts_info,
> };
>
> /* The mgmt unit and driver use a semaphore to access the phy during init */
> --
> 1.7.2.5
>
^ permalink raw reply
* Re: [PATCH] mlx4: Add support for EEH error recovery
From: Or Gerlitz @ 2012-07-23 13:45 UTC (permalink / raw)
To: Kleber Sacilotto de Souza
Cc: David Miller, netdev, jackm, yevgenyp, cascardo, brking, shlomop
In-Reply-To: <500D4F31.9020408@linux.vnet.ibm.com>
On 7/23/2012 4:18 PM, Kleber Sacilotto de Souza wrote:
> Exactly. The callbacks implemented are from standard PCI error recovery
> (Documentation/PCI/pci-error-recovery.txt) and the changes doesn't
> assume any platform in specific. The code was tested only on powerpc
> systems [...]
So how did you test that? using the kernel provided error injection
support and user space tool (which?) or in another way? we've trying
quickly here to inject errors using /sbin/ear-inject from
ras-utils-6.1-1.el6.x86_64 on a kernel built with
CONFIG_PCIEAER=y
CONFIG_PCIEAER_INJECT=m
and it failed to inject errors, SB details.
Or.
> since I don't have any mlx4 card on other platforms, however,
> these changes shouldn't make the error recover any worse than the
> current state.
> # lspci | grep 08.00.1
> 08:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network
> Connection (rev 02)
> # cat /tmp/intel.aer
> AER
> BUS 8 DEV 0 FN 1
> COR_STATUS BAD_TLP
> HEADER_LOG 0 1 2 3
> # /sbin/aer-inject < /tmp/intel.aer
> Error: Failed to write, Invalid argument
> # strace -F -f /sbin/aer-inject < /tmp/intel.aer
> [...]
> open("/dev/aer_inject", O_WRONLY) = 3
> write(3, "\10\0\1\0\0\0\0\0@\0\0\0\0\0\0\0\1\0\0\0\2\0\0\0\3\0\0\0",
> 28) = -1 EINVAL (Invalid argument)
> write(2, "Error: ", 7Error: ) = 7
> write(2, "Failed to write", 15Failed to write) = 15
> write(2, ", Invalid argument\n", 19, Invalid argument
> ) = 19
> exit_group(-1) = ?
^ permalink raw reply
* Re: New commands to configure IOV features
From: Don Dutile @ 2012-07-23 14:03 UTC (permalink / raw)
To: Chris Friesen
Cc: Ben Hutchings, David Miller, yuvalmin, gregory.v.rose, netdev,
linux-pci
In-Reply-To: <5009ECDF.4090305@genband.com>
On 07/20/2012 07:42 PM, Chris Friesen wrote:
> On 07/20/2012 02:01 PM, Ben Hutchings wrote:
>> On Fri, 2012-07-20 at 13:29 -0600, Chris Friesen wrote:
>
>>> Once the device exists, then domain-specific APIs would be used to
>>> configure it the same way that they would configure a physical device.
>>
>> To an extent, but not entirely.
>>
>> Currently, the assigned MAC address and (optional) VLAN tag for each
>> networking VF are configured via the PF net device (though this is done
>> though the rtnetlink API rather than ethtool).
>
> I actually have a use-case where the guest needs to be able to modify the MAC addresses of network devices that are actually VFs.
>
> The guest is bonding the network devices together, so the bonding driver in the guest expects to be able to set all the slaves to the same MAC address.
>
> As I read the ixgbe driver, this should be possible as long as the host hasn't explicitly set the MAC address of the VF. Is that correct?
>
> Chris
Interesting tug of war: hypervisors will want to set the macaddrs for security reasons,
some guests may want to set macaddr for (valid?) config reasons.
^ permalink raw reply
* [PATCH] ipv4: Remove redundant assignment
From: Lin Ming @ 2012-07-23 14:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
It is redundant to set no_addr and accept_local to 0 and then set them
with other values just after that.
Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
---
net/ipv4/fib_frontend.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index f277cf0..8732cc7 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -258,7 +258,6 @@ static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
fl4.flowi4_tos = tos;
fl4.flowi4_scope = RT_SCOPE_UNIVERSE;
- no_addr = accept_local = 0;
no_addr = idev->ifa_list == NULL;
accept_local = IN_DEV_ACCEPT_LOCAL(idev);
^ permalink raw reply related
* Re: [PATCH v5] sctp: Implement quick failover draft from tsvwg
From: Flavio Leitner @ 2012-07-23 14:28 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, netdev, vyasevich, sri, linux-sctp, joe
In-Reply-To: <20120720.123109.718847527715087868.davem@davemloft.net>
On Fri, 20 Jul 2012 12:31:09 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
[...]
> Just quote the commit message or similar.
Sure thing. I was going to clean up when I accidentally sent that email.
The previous ones were fine though :)
Sorry about that.
fbl
^ permalink raw reply
* Re: [3.5 regression / bridge] constantly toggeling between disabled and forwarding
From: Stephen Hemminger @ 2012-07-23 15:02 UTC (permalink / raw)
To: Michael Leun; +Cc: netdev, bridge, linux-kernel
In-Reply-To: <20120723091504.2d035d28@xenia.leun.net>
On Mon, 23 Jul 2012 09:15:04 +0200
Michael Leun <lkml20120218@newton.leun.net> wrote:
> Hi,
>
> when I use my usb ethernet adapter
>
> # > lsusb
> [...]
> Bus 002 Device 009: ID 9710:7830 MosChip Semiconductor MCS7830 10/100 Mbps Ethernet adapter
> [...]
>
> as port of an bridge
>
> > # brctl addbr br0
> > # brctl addif br0 eth0
> > # brctl addif br0 ue5
> > # ifconfig ue5 up
> > # ifconfig br0 up
>
> (Also does happen when eth0 is not part of the bridge, but the logs I
> had available were from that situation...)
>
> I constantly get messages showing the interface toggeling between
> disabled and forwarding state:
>
> Jul 23 07:40:50 elektra kernel: [ 1539.497337] br0: port 2(ue5) entered disabled state
> Jul 23 07:40:50 elektra kernel: [ 1539.554992] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:50 elektra kernel: [ 1539.555005] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:51 elektra kernel: [ 1540.496242] br0: port 2(ue5) entered disabled state
> Jul 23 07:40:51 elektra kernel: [ 1540.552534] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:51 elektra kernel: [ 1540.552548] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:52 elektra kernel: [ 1541.550413] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:53 elektra kernel: [ 1542.529672] br0: port 2(ue5) entered disabled state
> Jul 23 07:40:53 elektra kernel: [ 1542.587162] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:53 elektra kernel: [ 1542.587175] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:54 elektra kernel: [ 1543.585309] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:00 elektra kernel: [ 1549.360600] br0: port 2(ue5) entered disabled state
> Jul 23 07:41:00 elektra kernel: [ 1549.442998] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:00 elektra kernel: [ 1549.443011] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:01 elektra kernel: [ 1550.357686] br0: port 2(ue5) entered disabled state
> Jul 23 07:41:01 elektra kernel: [ 1550.408208] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:01 elektra kernel: [ 1550.408222] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:02 elektra kernel: [ 1551.407656] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:03 elektra kernel: [ 1552.401578] br0: port 2(ue5) entered disabled state
> Jul 23 07:41:03 elektra kernel: [ 1552.474773] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:03 elektra kernel: [ 1552.474786] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:04 elektra kernel: [ 1553.472487] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:05 elektra kernel: [ 1554.356138] br0: port 2(ue5) entered disabled state
> [...]
>
> This does (in the same situation, nothing else than the kernel changed)
> not happen with 3.4.5.
>
> Does anybody have an idea what the issue might be or do I need to bisect?
Probably not a bridge issue, but rather an issue with link status reporting
on the device. The bridge changes state when the attached ethernet
device raises/lowers carrier.
An independent way to observe link changes is to use a tool like:
ip monitor
which will show carrier up/down events.
^ permalink raw reply
* Re: New commands to configure IOV features
From: Chris Friesen @ 2012-07-23 15:09 UTC (permalink / raw)
To: Don Dutile
Cc: Ben Hutchings, David Miller, yuvalmin, gregory.v.rose, netdev,
linux-pci
In-Reply-To: <500D59BF.9040006@redhat.com>
On 07/23/2012 08:03 AM, Don Dutile wrote:
> On 07/20/2012 07:42 PM, Chris Friesen wrote:
>>
>> I actually have a use-case where the guest needs to be able to modify
>> the MAC addresses of network devices that are actually VFs.
>>
>> The guest is bonding the network devices together, so the bonding
>> driver in the guest expects to be able to set all the slaves to the
>> same MAC address.
>>
>> As I read the ixgbe driver, this should be possible as long as the
>> host hasn't explicitly set the MAC address of the VF. Is that correct?
>>
>> Chris
>
> Interesting tug of war: hypervisors will want to set the macaddrs for
> security reasons,
> some guests may want to set macaddr for
> (valid?) config reasons.
>
In our case we have control over both guest an host anyways, so it's
less of a security issue. In the general case though I could see it
being an interesting problem.
Back to the original discussion though--has anyone got any ideas about
the best way to trigger runtime creation of VFs? I don't know what the
binary APIs looks like, but via sysfs I could see something like
echo number_of_new_vfs_to_create >
/sys/bus/pci/devices/<address>/create_vfs
Something else that occurred to me--is there buy-in from driver
maintainers? I know the Intel ethernet drivers (what I'm most familiar
with) would need to be substantially modified to support on-the-fly
addition of new vfs. Currently they assume that the number of vfs is
known at module init time.
Chris
^ permalink raw reply
* Re: [PATCH] ppp: add 64 bit stats
From: Kevin Groeneveld @ 2012-07-23 15:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1343020585.2626.10054.camel@edumazet-glaptop>
Hi Eric,
On Mon, Jul 23, 2012 at 1:16 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Hmm. This patches adds races, but also adds a good amount of memory on
> these servers with thousand of ppp devices, and 64 cpus.
I am curious if you can elaborate on what is racy about the patch, I
am still trying to learn. I assumed (possibly incorrectly) that
because I was using percpu variables that the stats updates didn't
need any extra synchronization as any concurrent updates would be on
different cpus.
> I really doubt ppp is performance sensitive, it so doesnt need percpu
> counter.
>
> If you really want 64bits stats on ppp, use proper synchronization
> around u64 counters (but shared ones)
I will work on an updated patch without the percpu variables. I
didn't really think about servers with many cpus and many ppp sessions
when I created the patch, I was mainly thinking about my Linksys
router and other simple clients. Many of the other network drivers
use percpu variables for their stats so I just followed along.
Would proper synchronization in this case just be wrapping the updates
in a spin_lock/spin_unlock?
Kevin
^ permalink raw reply
* Re: [PATCH] ppp: add 64 bit stats
From: Eric Dumazet @ 2012-07-23 15:59 UTC (permalink / raw)
To: Kevin Groeneveld; +Cc: netdev
In-Reply-To: <CABF+-6WHqzXhvv9etdAqsamZirbWxWJEsnU-CQ1H8tvynCTOZA@mail.gmail.com>
On Mon, 2012-07-23 at 11:25 -0400, Kevin Groeneveld wrote:
> I am curious if you can elaborate on what is racy about the patch, I
> am still trying to learn. I assumed (possibly incorrectly) that
> because I was using percpu variables that the stats updates didn't
> need any extra synchronization as any concurrent updates would be on
> different cpus.
>
ppp paths (xmit versus receive) are reentrant.
Therefore several cpus might do the
u64_stats_update_begin(&stats->syncp) at the same moment : one increment
could be lost forever, making all readers looping forever in
u64_stats_fetch_begin_bh()
include/linux/u64_stats_sync.h
* 3) Write side must ensure mutual exclusion or one seqcount update could
* be lost, thus blocking readers forever.
* If this synchronization point is not a mutex, but a spinlock or
* spinlock_bh() or disable_bh() :
> > I really doubt ppp is performance sensitive, it so doesnt need percpu
> > counter.
> >
> > If you really want 64bits stats on ppp, use proper synchronization
> > around u64 counters (but shared ones)
>
> I will work on an updated patch without the percpu variables. I
> didn't really think about servers with many cpus and many ppp sessions
> when I created the patch, I was mainly thinking about my Linksys
> router and other simple clients. Many of the other network drivers
> use percpu variables for their stats so I just followed along.
Because there is one loopback device only, not thousands ;)
>
> Would proper synchronization in this case just be wrapping the updates
> in a spin_lock/spin_unlock?
Would be fine (if the proper BH safe variant is used), or you could also
use atomic64_t.
^ permalink raw reply
* RE: [E1000-devel] [PATCH net-next 3/4] e1000e: advertise transmit time stamping
From: Allan, Bruce W @ 2012-07-23 16:07 UTC (permalink / raw)
To: Richard Cochran, netdev@vger.kernel.org
Cc: e1000-devel@lists.sourceforge.net, Willem de Bruijn, David Miller
In-Reply-To: <e0e31f0229b5bfda1684122498b4d6fb3195cf26.1342976654.git.richardcochran@gmail.com>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Sunday, July 22, 2012 10:16 AM
> To: netdev@vger.kernel.org
> Cc: e1000-devel@lists.sourceforge.net; Willem de Bruijn; David Miller
> Subject: [E1000-devel] [PATCH net-next 3/4] e1000e: advertise transmit
> time stamping
>
> This driver now offers software transmit time stamping, so it should
> advertise that fact via ethtool. Compile tested only.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Cc: e1000-devel@lists.sourceforge.net
> ---
> drivers/net/ethernet/intel/e1000e/ethtool.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c
> b/drivers/net/ethernet/intel/e1000e/ethtool.c
> index 105d554..0349e24 100644
> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
> @@ -2061,6 +2061,7 @@ static const struct ethtool_ops e1000_ethtool_ops
> = {
> .get_coalesce = e1000_get_coalesce,
> .set_coalesce = e1000_set_coalesce,
> .get_rxnfc = e1000_get_rxnfc,
> + .get_ts_info = ethtool_op_get_ts_info,
> };
>
> void e1000e_set_ethtool_ops(struct net_device *netdev)
Thanks Richard. I have a similar patch amongst the PTP 1588 work I'm currently doing
for e1000e, but this one is good for now.
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
^ 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