* Re: [PATCH net-next] liquidio: remove unnecessary code
From: David Miller @ 2017-01-12 20:25 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20170112010902.GA9597@felix.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 11 Jan 2017 17:09:02 -0800
> Remove code that's no longer needed. It used to serve a purpose, which was
> to fix a link-related bug. For a while now, the NIC firmware has had a
> more elegant fix for that bug.
>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
> Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Applied.
^ permalink raw reply
* [PATCH net v2] ipv6: sr: fix several BUGs when preemption is enabled
From: David Lebrun @ 2017-01-12 20:26 UTC (permalink / raw)
To: netdev; +Cc: Vivien Didelot, David Lebrun
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
seg6_hmac_init() is called during the initialization of the ipv6 module.
This causes a subsequent call to smp_processor_id() with preemption
enabled, resulting in the following trace.
[ 20.451460] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
[ 20.452556] caller is debug_smp_processor_id+0x17/0x19
[ 20.453304] CPU: 0 PID: 1 Comm: systemd Not tainted 4.9.0-rc5-00973-g46738b1 #1
[ 20.454406] ffffc9000062fc18 ffffffff813607b2 0000000000000000 ffffffff81a7f782
[ 20.455528] ffffc9000062fc48 ffffffff813778dc 0000000000000000 00000000001dcf98
[ 20.456539] ffffffffa003bd08 ffffffff81af93e0 ffffc9000062fc58 ffffffff81377905
[ 20.456539] Call Trace:
[ 20.456539] [<ffffffff813607b2>] dump_stack+0x63/0x7f
[ 20.456539] [<ffffffff813778dc>] check_preemption_disabled+0xd1/0xe3
[ 20.456539] [<ffffffff81377905>] debug_smp_processor_id+0x17/0x19
[ 20.460260] [<ffffffffa0061f3b>] seg6_hmac_init+0xfa/0x192 [ipv6]
[ 20.460260] [<ffffffffa0061ccc>] seg6_init+0x39/0x6f [ipv6]
[ 20.460260] [<ffffffffa006121a>] inet6_init+0x21a/0x321 [ipv6]
[ 20.460260] [<ffffffffa0061000>] ? 0xffffffffa0061000
[ 20.460260] [<ffffffff81000457>] do_one_initcall+0x8b/0x115
[ 20.460260] [<ffffffff811328a3>] do_init_module+0x53/0x1c4
[ 20.460260] [<ffffffff8110650a>] load_module+0x1153/0x14ec
[ 20.460260] [<ffffffff81106a7b>] SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106a7b>] ? SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106abc>] SyS_finit_module+0x9/0xb
[ 20.460260] [<ffffffff810014d1>] do_syscall_64+0x62/0x75
[ 20.460260] [<ffffffff816834f0>] entry_SYSCALL64_slow_path+0x25/0x25
Moreover, dst_cache_* functions also call smp_processor_id(), generating
a similar trace.
This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
and disable preemption when using dst_cache_* functions.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6_hmac.c | 2 +-
net/ipv6/seg6_iptunnel.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index ef1c8a4..03a0648 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -400,7 +400,7 @@ static int seg6_hmac_init_algo(void)
*p_tfm = tfm;
}
- p_tfm = this_cpu_ptr(algo->tfms);
+ p_tfm = raw_cpu_ptr(algo->tfms);
tfm = *p_tfm;
shsize = sizeof(*shash) + crypto_shash_descsize(tfm);
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index bbfca22..1d60cb1 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -265,7 +265,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
slwt = seg6_lwt_lwtunnel(orig_dst->lwtstate);
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst = dst_cache_get(&slwt->cache);
+ preempt_enable();
#endif
if (unlikely(!dst)) {
@@ -286,7 +288,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
}
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst_cache_set_ip6(&slwt->cache, dst, &fl6.saddr);
+ preempt_enable();
#endif
}
--
2.7.3
^ permalink raw reply related
* Re: [PATCH net v2] ipv6: sr: fix several BUGs when preemption is enabled
From: David Lebrun @ 2017-01-12 20:28 UTC (permalink / raw)
To: netdev; +Cc: Vivien Didelot
In-Reply-To: <1484252809-29192-1-git-send-email-david.lebrun@uclouvain.be>
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
On 01/12/2017 09:26 PM, David Lebrun wrote:
> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
No idea where does that come from, resending patch. Sorry about that Vivien.
David
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* Re: To netlink or not to netlink, that is the question
From: David Miller @ 2017-01-12 20:27 UTC (permalink / raw)
To: Jason; +Cc: dcbw, stephen, netdev
In-Reply-To: <CAHmME9oYtxL=sBpOquOjcqtQnYY=AFHC+OqMdeQD6X8HNoY4zw@mail.gmail.com>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Thu, 12 Jan 2017 21:07:43 +0100
> David - you concur with Stephen that ioctl is really not okay and I
> should absolutely do netlink?
Yes.
^ permalink raw reply
* Re: [Patch] Fixing order of trinary operator when assigning the ifindex in XFRM Decode Session
From: David Ahern @ 2017-01-12 20:28 UTC (permalink / raw)
To: Chacon, Carlos A, netdev@vger.kernel.org; +Cc: steffen.klassert@secunet.com
In-Reply-To: <BY1PR0701MB12228231F8BCD74FC473284A9A790@BY1PR0701MB1222.namprd07.prod.outlook.com>
Hi Carlos:
patches sent to netdev should be plain text only. Using git send-email would be best.
Also, the Subject line should start with the area affected (e.g., net: xfrm:) and really should be a bit shorter. e.g., something like this:
[PATCH] net: xfrm: fix flow oif in decode_session
On 1/12/17 1:01 PM, Chacon, Carlos A wrote:
>
> Author: Carlos Chacon <carlos.chacon@gatech.edu>
> Date: Thu Jan 12 11:42:32 2017 -0800
>
> Fixing order of trinary operator when assigning the ifindex in XFRM Decode Session
>
> For xfrm4_policy.c:_decode_session4 and xfrm6_policy.c:_decode_session6 the line
> fl4->flowi4_oif = reverse ? skb->skb_iif : oif;
> fl6->flowi6_oif = reverse ? skb->skb_iif : oif;
> is assigning the incorrect oif to the flow_oif. It should read:
> reverse ? oif : skb->skb_iif;
> The "reverse" variable is defined in net/xfrm/xfrm_policy.c:__xfrm_policy_check
> when it checks if the dir is above the XFRM_POLICY_MASK if this returns false
> it reverses the ifindex, but it should only reverse if it returns true.
The above explanation suggests the reverse flag in __xfrm_policy_check should be fixed. Can you check that and maybe __xfrm_policy_check2 as well?
^ permalink raw reply
* [PATCH net v3] ipv6: sr: fix several BUGs when preemption is enabled
From: David Lebrun @ 2017-01-12 20:30 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
seg6_hmac_init() is called during the initialization of the ipv6 module.
This causes a subsequent call to smp_processor_id() with preemption
enabled, resulting in the following trace.
[ 20.451460] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
[ 20.452556] caller is debug_smp_processor_id+0x17/0x19
[ 20.453304] CPU: 0 PID: 1 Comm: systemd Not tainted 4.9.0-rc5-00973-g46738b1 #1
[ 20.454406] ffffc9000062fc18 ffffffff813607b2 0000000000000000 ffffffff81a7f782
[ 20.455528] ffffc9000062fc48 ffffffff813778dc 0000000000000000 00000000001dcf98
[ 20.456539] ffffffffa003bd08 ffffffff81af93e0 ffffc9000062fc58 ffffffff81377905
[ 20.456539] Call Trace:
[ 20.456539] [<ffffffff813607b2>] dump_stack+0x63/0x7f
[ 20.456539] [<ffffffff813778dc>] check_preemption_disabled+0xd1/0xe3
[ 20.456539] [<ffffffff81377905>] debug_smp_processor_id+0x17/0x19
[ 20.460260] [<ffffffffa0061f3b>] seg6_hmac_init+0xfa/0x192 [ipv6]
[ 20.460260] [<ffffffffa0061ccc>] seg6_init+0x39/0x6f [ipv6]
[ 20.460260] [<ffffffffa006121a>] inet6_init+0x21a/0x321 [ipv6]
[ 20.460260] [<ffffffffa0061000>] ? 0xffffffffa0061000
[ 20.460260] [<ffffffff81000457>] do_one_initcall+0x8b/0x115
[ 20.460260] [<ffffffff811328a3>] do_init_module+0x53/0x1c4
[ 20.460260] [<ffffffff8110650a>] load_module+0x1153/0x14ec
[ 20.460260] [<ffffffff81106a7b>] SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106a7b>] ? SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106abc>] SyS_finit_module+0x9/0xb
[ 20.460260] [<ffffffff810014d1>] do_syscall_64+0x62/0x75
[ 20.460260] [<ffffffff816834f0>] entry_SYSCALL64_slow_path+0x25/0x25
Moreover, dst_cache_* functions also call smp_processor_id(), generating
a similar trace.
This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
and disable preemption when using dst_cache_* functions.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6_hmac.c | 2 +-
net/ipv6/seg6_iptunnel.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index ef1c8a4..03a0648 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -400,7 +400,7 @@ static int seg6_hmac_init_algo(void)
*p_tfm = tfm;
}
- p_tfm = this_cpu_ptr(algo->tfms);
+ p_tfm = raw_cpu_ptr(algo->tfms);
tfm = *p_tfm;
shsize = sizeof(*shash) + crypto_shash_descsize(tfm);
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index bbfca22..1d60cb1 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -265,7 +265,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
slwt = seg6_lwt_lwtunnel(orig_dst->lwtstate);
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst = dst_cache_get(&slwt->cache);
+ preempt_enable();
#endif
if (unlikely(!dst)) {
@@ -286,7 +288,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
}
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst_cache_set_ip6(&slwt->cache, dst, &fl6.saddr);
+ preempt_enable();
#endif
}
--
2.7.3
^ permalink raw reply related
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: Shannon Nelson @ 2017-01-12 20:30 UTC (permalink / raw)
To: Eric Dumazet, Rob Gardner; +Cc: netdev, davem, sparclinux, linux-kernel
In-Reply-To: <1484252733.13165.1.camel@edumazet-glaptop3.roam.corp.google.com>
On 1/12/2017 12:25 PM, Eric Dumazet wrote:
> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>
>>
>> I suspect that someplace, somebody is casting val to an int * or
>> something like that.
>
> Then that would be the bug. Can we root cause this please ?
>
>
Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
struct in6_addr *buf = (struct in6_addr *) tmp.val;
sln
^ permalink raw reply
* Re: [iproute PATCH] tc: m_xt: Fix segfault with iptables-1.6.0
From: Stephen Hemminger @ 2017-01-12 19:34 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20170112142249.13041-1-phil@nwl.cc>
On Thu, 12 Jan 2017 15:22:49 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Said iptables version introduced struct xtables_globals field
> 'compat_rev', a function pointer. Initializing it is mandatory as
> libxtables calls it without existence check.
>
> Without this, tc segfaults when using the xt action like so:
>
> | tc filter add dev d0 parent ffff: u32 match u32 0 0 \
> | action xt -j MARK --set-mark 20
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> tc/m_xt.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tc/m_xt.c b/tc/m_xt.c
> index dbb54981462ee..57ed40d7aa3a8 100644
> --- a/tc/m_xt.c
> +++ b/tc/m_xt.c
> @@ -77,6 +77,9 @@ static struct xtables_globals tcipt_globals = {
> .orig_opts = original_opts,
> .opts = original_opts,
> .exit_err = NULL,
> +#if (XTABLES_VERSION_CODE >= 11)
> + .compat_rev = xtables_compatible_revision,
> +#endif
> };
>
> /*
Ah the xtables API is not really an application friendly API by
any stretch of the imagination
Parenthesis not really necessary there.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: David Miller @ 2017-01-12 20:39 UTC (permalink / raw)
To: eric.dumazet
Cc: rob.gardner, shannon.nelson, netdev, sparclinux, linux-kernel
In-Reply-To: <1484252733.13165.1.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Jan 2017 12:25:33 -0800
> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>
>>
>> I suspect that someplace, somebody is casting val to an int * or
>> something like that.
>
> Then that would be the bug. Can we root cause this please ?
The three accesses to foc->val are via function calls, at least when I
try to build it, one via memcmp(), one via memcpy() (for the structure
assignment at the end of the function) and one via a call into the
crypto layer when we do tcp_fastopen_cookie_gen).
So if the PC is inside of tcp_try_fastopen() it has to be something
else, or something specific to your gcc and build.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: David Miller @ 2017-01-12 20:41 UTC (permalink / raw)
To: shannon.nelson
Cc: eric.dumazet, rob.gardner, netdev, sparclinux, linux-kernel
In-Reply-To: <1c39bf41-4ebf-643a-c6a0-caf98a17a89c@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu, 12 Jan 2017 12:30:38 -0800
> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>>
>>>
>>> I suspect that someplace, somebody is casting val to an int * or
>>> something like that.
>>
>> Then that would be the bug. Can we root cause this please ?
>>
>>
>
> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
>
> struct in6_addr *buf = (struct in6_addr *) tmp.val;
Oh yeah, that's it. I didn't notice that at all.
^ permalink raw reply
* Re: [PATCH] [net] net/mlx5e: fix another -Wmaybe-uninitialized warning
From: Or Gerlitz @ 2017-01-12 20:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Or Gerlitz, Saeed Mahameed, Hadar Hen Zion, David S . Miller,
Linux Netdev List, Linux Kernel
In-Reply-To: <2981112.7jTLlX72ae@wuerfel>
On Thu, Jan 12, 2017 at 6:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, January 12, 2017 5:21:49 PM CET Or Gerlitz wrote:
>> When I build here without CONFIG_INET in my system, the build goes fine
>> with this approach. However, we're pretty sure that in the past we got
>> 0-day report from the kbuild test robot where he was unhappy that we
>> make the ip_route_output_key call without being wrapped with that #if
>> IS_ENABLED(CONFIG_INET) -- so, we don't want to go there again... thoughts?
> I went back and forth between the two versions, either leaving the #if
> in place, or using the if(IS_ENABLED()) check to be really sure that
> we can't get compile error here.
> I did check that ip_route_output_key() is always declared, but now
> I see that net/route.h might not always be included from en_tc.c
> if CONFIG_INET is disabled (I don't see how it gets included, but
> it obviously is when CONFIG_INET is turned on).
> Adding an explicit include of that file should probably avoid the
> case you ran into earlier, but for I agree it's safer to not rely
> on that here for a bugfix, and just leave the #ifdef. Do you want to
> modify it yourself, or should I spin a new version with that?
I can do that next week, thanks
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: Shannon Nelson @ 2017-01-12 20:56 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, rob.gardner, netdev, sparclinux, linux-kernel
In-Reply-To: <20170112.154143.1940764507974590907.davem@davemloft.net>
On 1/12/2017 12:41 PM, David Miller wrote:
> From: Shannon Nelson <shannon.nelson@oracle.com>
> Date: Thu, 12 Jan 2017 12:30:38 -0800
>
>> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
>>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>>>
>>>>
>>>> I suspect that someplace, somebody is casting val to an int * or
>>>> something like that.
>>>
>>> Then that would be the bug. Can we root cause this please ?
>>>
>>>
>>
>> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
>>
>> struct in6_addr *buf = (struct in6_addr *) tmp.val;
>
> Oh yeah, that's it. I didn't notice that at all.
>
It looked to me like swapping the data fields would be the easiest and
least impactive way to fix this. I didn't want to mess with the logic.
I'm certainly open to other suggestions.
sln
^ permalink raw reply
* Re: [PATCH net-next] secure_seq: fix sparse errors
From: David Miller @ 2017-01-12 20:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, Jason
In-Reply-To: <1484187037.15816.21.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 11 Jan 2017 18:10:37 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Fixes following warnings :
>
> net/core/secure_seq.c:125:28: warning: incorrect type in argument 1
> (different base types)
> net/core/secure_seq.c:125:28: expected unsigned int const [unsigned]
> [usertype] a
> net/core/secure_seq.c:125:28: got restricted __be32 [usertype] saddr
> net/core/secure_seq.c:125:35: warning: incorrect type in argument 2
> (different base types)
> net/core/secure_seq.c:125:35: expected unsigned int const [unsigned]
> [usertype] b
> net/core/secure_seq.c:125:35: got restricted __be32 [usertype] daddr
> net/core/secure_seq.c:125:43: warning: cast from restricted __be16
> net/core/secure_seq.c:125:61: warning: restricted __be16 degrades to
> integer
>
>
> Fixes: 7cd23e5300c1 ("secure_seq: use SipHash in place of MD5")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] liquidio VF: reduce load time of module
From: David Miller @ 2017-01-12 20:53 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20170112014027.GA9704@felix.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 11 Jan 2017 17:40:27 -0800
> From: Prasad Kanneganti <prasad.kanneganti@cavium.com>
>
> Reduce the load time of the VF driver by decreasing the wait time between
> iterations of the loop that polls for a mailbox response from the PF. Also
> change the wait time units from jiffies to milliseconds.
>
> Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
> Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
> Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net] net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim
From: Florian Fainelli @ 2017-01-12 20:09 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
The __bcm_sysport_tx_reclaim() function is used to reclaim transmit
resources in different places within the driver. Most of them should
not affect the state of the transit flow control.
Introduce bcm_sysport_tx_clean() which cleans the ring, but does not
re-enable flow control towards the networking stack, and make
bcm_sysport_tx_reclaim() do the actual transmit queue flow control.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 7e8cf213fd81..744ed6ddaf37 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -710,11 +710,8 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
unsigned int c_index, last_c_index, last_tx_cn, num_tx_cbs;
unsigned int pkts_compl = 0, bytes_compl = 0;
struct bcm_sysport_cb *cb;
- struct netdev_queue *txq;
u32 hw_ind;
- txq = netdev_get_tx_queue(ndev, ring->index);
-
/* Compute how many descriptors have been processed since last call */
hw_ind = tdma_readl(priv, TDMA_DESC_RING_PROD_CONS_INDEX(ring->index));
c_index = (hw_ind >> RING_CONS_INDEX_SHIFT) & RING_CONS_INDEX_MASK;
@@ -745,9 +742,6 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
ring->c_index = c_index;
- if (netif_tx_queue_stopped(txq) && pkts_compl)
- netif_tx_wake_queue(txq);
-
netif_dbg(priv, tx_done, ndev,
"ring=%d c_index=%d pkts_compl=%d, bytes_compl=%d\n",
ring->index, ring->c_index, pkts_compl, bytes_compl);
@@ -759,16 +753,33 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
static unsigned int bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
struct bcm_sysport_tx_ring *ring)
{
+ struct netdev_queue *txq;
unsigned int released;
unsigned long flags;
+ txq = netdev_get_tx_queue(priv->netdev, ring->index);
+
spin_lock_irqsave(&ring->lock, flags);
released = __bcm_sysport_tx_reclaim(priv, ring);
+ if (released)
+ netif_tx_wake_queue(txq);
+
spin_unlock_irqrestore(&ring->lock, flags);
return released;
}
+/* Locked version of the per-ring TX reclaim, but does not wake the queue */
+static void bcm_sysport_tx_clean(struct bcm_sysport_priv *priv,
+ struct bcm_sysport_tx_ring *ring)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&ring->lock, flags);
+ __bcm_sysport_tx_reclaim(priv, ring);
+ spin_unlock_irqrestore(&ring->lock, flags);
+}
+
static int bcm_sysport_tx_poll(struct napi_struct *napi, int budget)
{
struct bcm_sysport_tx_ring *ring =
@@ -1252,7 +1263,7 @@ static void bcm_sysport_fini_tx_ring(struct bcm_sysport_priv *priv,
napi_disable(&ring->napi);
netif_napi_del(&ring->napi);
- bcm_sysport_tx_reclaim(priv, ring);
+ bcm_sysport_tx_clean(priv, ring);
kfree(ring->cbs);
ring->cbs = NULL;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 2/6 net-next] inet: drop ->bind_conflict
From: Josef Bacik @ 2017-01-12 21:04 UTC (permalink / raw)
To: David Miller; +Cc: hannes, kraigatgoog, eric.dumazet, tom, netdev, kernel-team
In-Reply-To: <20170112.145640.2151487482259137455.davem@davemloft.net>
On Thu, Jan 12, 2017 at 2:56 PM, David Miller <davem@davemloft.net>
wrote:
> From: Josef Bacik <jbacik@fb.com>
> Date: Wed, 11 Jan 2017 15:22:40 -0500
>
>> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
>> index 56d756e..dc07734 100644
>> --- a/net/ipv4/tcp_ipv4.c
>> +++ b/net/ipv4/tcp_ipv4.c
>> @@ -63,6 +63,7 @@
>> #include <linux/times.h>
>> #include <linux/slab.h>
>>
>> +#include <net/addrconf.h>
>> #include <net/net_namespace.h>
>> #include <net/icmp.h>
>> #include <net/inet_hashtables.h>
>
> I don't see what this has to do with this change.
Ugh sorry, that's a left over from when I had the protocol specific
callback for the saddr_equal stuff, I'll fix that up. Thanks,
Josef
^ permalink raw reply
* Re: [iproute PATCH] tc: m_xt: Fix segfault with iptables-1.6.0
From: Phil Sutter @ 2017-01-12 21:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170112113449.581e2219@xeon-e3>
On Thu, Jan 12, 2017 at 11:34:49AM -0800, Stephen Hemminger wrote:
> On Thu, 12 Jan 2017 15:22:49 +0100
> Phil Sutter <phil@nwl.cc> wrote:
>
> > Said iptables version introduced struct xtables_globals field
> > 'compat_rev', a function pointer. Initializing it is mandatory as
> > libxtables calls it without existence check.
> >
> > Without this, tc segfaults when using the xt action like so:
> >
> > | tc filter add dev d0 parent ffff: u32 match u32 0 0 \
> > | action xt -j MARK --set-mark 20
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> > tc/m_xt.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/tc/m_xt.c b/tc/m_xt.c
> > index dbb54981462ee..57ed40d7aa3a8 100644
> > --- a/tc/m_xt.c
> > +++ b/tc/m_xt.c
> > @@ -77,6 +77,9 @@ static struct xtables_globals tcipt_globals = {
> > .orig_opts = original_opts,
> > .opts = original_opts,
> > .exit_err = NULL,
> > +#if (XTABLES_VERSION_CODE >= 11)
> > + .compat_rev = xtables_compatible_revision,
> > +#endif
> > };
> >
> > /*
>
> Ah the xtables API is not really an application friendly API by
> any stretch of the imagination
Yeah, this could have really been handled by the lib, especially since
it provides the callback to assign to it. But whatever, looking at the
git log shows it's not happening for the first time so at least it's
consistent. :)
> Parenthesis not really necessary there.
Oh, indeed! I just stuck to how the other XTABLES_VERSION_CODE checks
are made. Are you going to apply this patch either way? I'll then
follow-up dropping the parentheses at all places at once.
Thanks, Phil
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: David Miller @ 2017-01-12 21:18 UTC (permalink / raw)
To: shannon.nelson
Cc: eric.dumazet, rob.gardner, netdev, sparclinux, linux-kernel
In-Reply-To: <131ec7b7-5b74-2545-8bf7-92812443a876@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu, 12 Jan 2017 12:56:08 -0800
>
>
> On 1/12/2017 12:41 PM, David Miller wrote:
>> From: Shannon Nelson <shannon.nelson@oracle.com>
>> Date: Thu, 12 Jan 2017 12:30:38 -0800
>>
>>> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
>>>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>>>>
>>>>>
>>>>> I suspect that someplace, somebody is casting val to an int * or
>>>>> something like that.
>>>>
>>>> Then that would be the bug. Can we root cause this please ?
>>>>
>>>>
>>>
>>> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
>>>
>>> struct in6_addr *buf = (struct in6_addr *) tmp.val;
>>
>> Oh yeah, that's it. I didn't notice that at all.
>>
>
> It looked to me like swapping the data fields would be the easiest and
> least impactive way to fix this. I didn't want to mess with the
> logic. I'm certainly open to other suggestions.
Given the nature of the problem, your fix is probably fine.
Eric, any objections?
^ permalink raw reply
* Re: [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: David Miller @ 2017-01-12 21:21 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, jason, andrew, sebastian.hesselbarth, gregory.clement,
linux, vivien.didelot, linux-arm-kernel, linux-kernel, gregkh
In-Reply-To: <20170112034121.27697-6-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 11 Jan 2017 19:41:16 -0800
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/base/core.c | 19 +++++++++++++++++++
> include/linux/device.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 020ea7f05520..3dd6047c10d8 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2065,6 +2065,25 @@ struct device *device_find_child(struct device *parent, void *data,
> }
> EXPORT_SYMBOL_GPL(device_find_child);
>
> +static int dev_is_class(struct device *dev, void *class)
I know you are just moving code, but this class argumnet is a string
and thus should be "char *" or even "const char *".
^ permalink raw reply
* Re: kill off pci_enable_msi_{exact,range}
From: Bjorn Helgaas @ 2017-01-12 21:29 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-pci, Mauro Carvalho Chehab, netdev, linux-media,
Tom Lendacky
In-Reply-To: <1483994260-19797-1-git-send-email-hch@lst.de>
On Mon, Jan 09, 2017 at 09:37:37PM +0100, Christoph Hellwig wrote:
> I had hope that we could kill these old interfaces of for 4.10-rc,
> but as of today Linus tree still has two users:
>
> (1) the cobalt media driver, for which I sent a patch long time ago,
> it got missed in the merge window.
> (2) the new xgbe driver was merged in 4.10-rc but used the old interfaces
> anyway
>
> This series resend the patch for (1) and adds a new one for (2), as well
> as having the final removal patch behind it. Maybe we should just queue
> up all three together in the PCI tree for 4.11?
Applied all three (with Tom's ack on the amd-xgbe patch) to pci/msi for
v4.11, thanks!
^ permalink raw reply
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-12 21:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: rmk+kernel@arm.linux.org.uk, Karicheri, Muralidharan,
netdev@vger.kernel.org
In-Reply-To: <20170112010658.GA25391@lunn.ch>
> > I double checked that ours is actually a 88E1514. According
> > to Marvell's brief description, it seems that it does support
> > fiber.
> >
> > Reading page 18 reg 30 returns 6.
>
> O.K, that is consistent. Looking at the Marvell SDK:
>
> phy/Include/madApiDefs.h:#define MAD_SUB_88E1510 4 /* 88E1510 */
> phy/Include/madApiDefs.h:#define MAD_SUB_88E1518 5 /* 88E1518 */
> phy/Include/madApiDefs.h:#define MAD_SUB_88E1512 6 /*
> 88E1512/88E1514 */
>
> I took another look at the patch adding Fibre support. The
> suspend/resume functions are wrong.
>
> /* Suspend the fiber mode first */
> if (!(phydev->supported & SUPPORTED_FIBRE)) {
>
> The ! should not be there. Does removing them both fix your problem?
>
Hi Andrew,
Thanks for taking the time to look into those patches. Yes we notice
the error in the suspend/resume functions also.
But our problem is caused by the read_status function:
if ((phydev->supported & SUPPORTED_FIBRE)) {
err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
if (err < 0)
goto error;
err = marvell_read_status_page(phydev, MII_M1111_FIBER);
if (err < 0)
goto error;
/* If the fiber link is up, it is the selected and used link.
* In this case, we need to stay in the fiber page.
* Please to be careful about that, avoid to restore Copper page
* in other functions which could break the behaviour
* for some fiber phy like 88E1512.
* */
if (phydev->link)
return 0;
which keeps the fiber page if phydev->link is true (for some
reason this is the case even though we are not using fiber)
However, this causes a problem in kernel reboot because neither
the suspend/resume is called to restore the copper page and
u-boot marvell phy driver does not support 1510 fiber, which
will then result in writing to the wrong phy regs and causes
a sgmii auto-nego time out.
In addition to fixing the ! in suspend/resume, my suggestion
would be to change also the read_status function to
always restore the copper page after doing the fiber stuffs:
if ((phydev->supported & SUPPORTED_FIBRE)) {
err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
if (err < 0)
goto error;
err = marvell_read_status_page(phydev, MII_M1111_FIBER);
if (err < 0)
goto error;
err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
if (err < 0)
goto error;
/* If the fiber link is up, it is the selected and used link.
* In this case, we need to stay in the fiber page.
* Please to be careful about that, avoid to restore Copper page
* in other functions which could break the behaviour
* for some fiber phy like 88E1512.
* */
if (phydev->link)
return 0;
This makes sure that it is always the copper page brought up
and whenever it needs to do some fiber stuffs, the fiber page
needs to be brought out explicitly, which is already the case
currently.
Another issue is that, as of now, FIBER is enabled regardless
of the specific 88e151x. But I believe there is 88e151x chip(s)
that does not support fiber. Should fiber be enabled only for
those that do support fiber?
WingMan
^ permalink raw reply
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Florian Fainelli @ 2017-01-12 19:42 UTC (permalink / raw)
To: Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <a2d2e457-47e5-bb73-a059-0cb907a29ae0@synopsys.com>
On 01/12/2017 01:43 AM, Joao Pinto wrote:
>
> First of all, I am suggesting an alternative way of organizing the code, and
> that's it, I have no second intentions about anything :).
>
> Please don't see this as a take-over or erase Stmicro from credits, please... it
> makes no sense. You can leave STMicro license and all the credits fine by me and
> I insist on it. But lets name it for something that makes sense... lets call it
> dwc (designware controllers), I am totally open to suggestions.
I don't understand how you reached this conclusion based on what I
wrote, but I have no concerns about take over or anything, and keep in
mind that maintainership is by nature a volatile thing. One day, a group
of people can be in charge of some piece of code, and in the future, it
could be another group of people, let's be agile.
>
> I don't understand the hostility of some comments, honestly.
It was not my intention to be hostile and I am sorry if this was how you
perceived it.
As an occasional contributor to netdev and the stmmac driver what I
welcome more than anything is more eyeballs and dedicated people
maintaining the driver, because it's always a good sign that there is
interesting in making the driver rock solid and feature full. As a
non-Linux kernel developer (OpenWrt/LEDE) what I care about is being
able to quickly backport fixes without going through too many hoops
(including driver rename, relocation etc.).
>
> The easiest way is to keep things like they are today, and believe me I have a
> lot of things to do, like adding the support of multi-queues / multi-channels to
> stmmac, so I not suggesting this because it is fun.
I believe this is what David is also asking for here.
>
> I am suggesting this because it is what I am used to seeing in other subsystems.
> USB has dwc2 and dwc3 folders that clearly identifies that they are Designware
> (synopsys) extensions to the USB 2.0 and 3.0. The author of dwc3 was Texas
> Instruments, and they did not name it ti/usb. For example I use an AXS101
> Development board that does not have a stmicro SoC but has a Designware Ethernet
> IP in it, so uses stmicro/stmmac. For me it is confusing.
The examples you are giving unfortunately unveil the same pattern: a
customer of the DWC/SNPS IP was first in the upstreaming business, and
because of that they were able to dictate how the initial submission
would look like, this was noticed, and you are now as a company
remedying that, and this is great!
There are ways to improve the situation to avoid the confusion:
- provide clear Kconfig help texts that indicate that the driver is not
just for STMicro but for SNPS IPs in general
- provide a Documentation/networking/ entry that explains the history,
why the driver remains with/has this name, and eventually technical
information about it
>
> Lets not name it synopsys, for me it is totally fine, but naming it
> stmicro/stmmac is not the right way because it seems like it is a driver just
> for stmicro products, which is not, is for products that use Designware Ethernet
> IPs.
>
> I am volunteering to do this work, let's discuss this.
I would focus on what has value: adding features, support for newer
versions of the IP and fixing bugs, not moving the code around which is
just fixing a cosmetic and historical problem, but not a functional
problem. By moving the code you are making the job of David and other
kernel maintainers dealing with -stable backports nearly impossible,
ultimately arming your relationship with the community over something
that is not considered an essential change.
Let me give you another example, when Broadcom sold its bnx2x LoB to
Qlogic, the driver was not renamed, nor moved, and now that Qlogic has
been acquired by Cavium, it still remains under the same directory. Yes,
it is presenting a singularity and is technically not correct, because
the IP now belongs to Cavium, but it is what it is for historical reasons.
--
Florian
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: Eric Dumazet @ 2017-01-12 21:36 UTC (permalink / raw)
To: David Miller
Cc: shannon.nelson, rob.gardner, netdev, sparclinux, linux-kernel
In-Reply-To: <20170112.161852.1469407145449781531.davem@davemloft.net>
On Thu, 2017-01-12 at 16:18 -0500, David Miller wrote:
> From: Shannon Nelson <shannon.nelson@oracle.com>
> Date: Thu, 12 Jan 2017 12:56:08 -0800
>
> >
> >
> > On 1/12/2017 12:41 PM, David Miller wrote:
> >> From: Shannon Nelson <shannon.nelson@oracle.com>
> >> Date: Thu, 12 Jan 2017 12:30:38 -0800
> >>
> >>> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
> >>>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
> >>>>
> >>>>>
> >>>>> I suspect that someplace, somebody is casting val to an int * or
> >>>>> something like that.
> >>>>
> >>>> Then that would be the bug. Can we root cause this please ?
> >>>>
> >>>>
> >>>
> >>> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
> >>>
> >>> struct in6_addr *buf = (struct in6_addr *) tmp.val;
> >>
> >> Oh yeah, that's it. I didn't notice that at all.
> >>
> >
> > It looked to me like swapping the data fields would be the easiest and
> > least impactive way to fix this. I didn't want to mess with the
> > logic. I'm certainly open to other suggestions.
>
> Given the nature of the problem, your fix is probably fine.
>
> Eric, any objections?
I am still objecting to this fix.
gcc makes no provision for aligning an variable that has alignof() = 1
We had such issues in the past.
We need the proper annotation on ->val field itself, to get proper
alignment.
Then moving around the other field is a matter of avoiding a hole.
val should be an union, so that proper alignment is enforced by one
member.
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index fc5848dad7a43216b3f124c4afdaa6b64b23910c..5b790abf4c16313c9110996683be3a7fb368b66f 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -62,8 +62,13 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb)
/* TCP Fast Open Cookie as stored in memory */
struct tcp_fastopen_cookie {
+ union {
+ u8 val[TCP_FASTOPEN_COOKIE_MAX];
+#if IS_ENABLED(CONFIG_IPV6)
+ struct in6_addr addr;
+#endif
+ };
s8 len;
- u8 val[TCP_FASTOPEN_COOKIE_MAX];
bool exp; /* In RFC6994 experimental option format */
};
^ permalink raw reply related
* Re: Marvell Phy (1510) issue since v4.7 kernel
From: Russell King - ARM Linux @ 2017-01-12 21:41 UTC (permalink / raw)
To: Kwok, WingMan
Cc: Andrew Lunn, Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E15354EB0@DFLE11.ent.ti.com>
On Thu, Jan 12, 2017 at 09:31:27PM +0000, Kwok, WingMan wrote:
>
> > > I double checked that ours is actually a 88E1514. According
> > > to Marvell's brief description, it seems that it does support
> > > fiber.
> > >
> > > Reading page 18 reg 30 returns 6.
> >
> > O.K, that is consistent. Looking at the Marvell SDK:
> >
> > phy/Include/madApiDefs.h:#define MAD_SUB_88E1510 4 /* 88E1510 */
> > phy/Include/madApiDefs.h:#define MAD_SUB_88E1518 5 /* 88E1518 */
> > phy/Include/madApiDefs.h:#define MAD_SUB_88E1512 6 /*
> > 88E1512/88E1514 */
> >
> > I took another look at the patch adding Fibre support. The
> > suspend/resume functions are wrong.
> >
> > /* Suspend the fiber mode first */
> > if (!(phydev->supported & SUPPORTED_FIBRE)) {
> >
> > The ! should not be there. Does removing them both fix your problem?
> >
>
> Hi Andrew,
>
> Thanks for taking the time to look into those patches. Yes we notice
> the error in the suspend/resume functions also.
>
> But our problem is caused by the read_status function:
>
> if ((phydev->supported & SUPPORTED_FIBRE)) {
> err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
> if (err < 0)
> goto error;
>
> err = marvell_read_status_page(phydev, MII_M1111_FIBER);
> if (err < 0)
> goto error;
>
> /* If the fiber link is up, it is the selected and used link.
> * In this case, we need to stay in the fiber page.
> * Please to be careful about that, avoid to restore Copper page
> * in other functions which could break the behaviour
> * for some fiber phy like 88E1512.
> * */
> if (phydev->link)
> return 0;
>
> which keeps the fiber page if phydev->link is true (for some
> reason this is the case even though we are not using fiber)
See below.
> However, this causes a problem in kernel reboot because neither
> the suspend/resume is called to restore the copper page and
> u-boot marvell phy driver does not support 1510 fiber, which
> will then result in writing to the wrong phy regs and causes
> a sgmii auto-nego time out.
So what we need to do is to have a .shutdown function installed - but
it's not that simple...
.mdiodrv = {
.driver = {
.shutdown = mv88e1512_shutdown,
},
},
in the appropriate phy_driver array element, and then have:
static void mv88e1512_shutdown(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
}
which will restore the copper page on non-emergency reboots. For
emergency reboots, we're out of luck... the real fix would be for
uboot to ensure that when it detects this PHY, it ensures that the
right page is selected.
Now, that all said, there's a bug in this code, which is fixed by
a patch I recently submitted. If you have an 88E151x connected via
SGMII, then the read_status function incorrectly believes it should
be reading from the fiber page - when in fact the fiber page is
reporting the status of the host-side link. So, before trying the
above modification, please try this patch - it's already been merged
into the net tree, so should hit -rc soon.
My guess from what you've said above is that your 88E151x is connected
via SGMII, so you need the patch below rather than trying to install
a shutdown function.
8<====
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
fiber page is used for the SGMII host-side connection. The PHY driver
notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
for the link status, and ends up reading the MAC-side status instead of
the outgoing (copper) link. This leads to incorrect results reported
via ethtool.
If the PHY is connected via SGMII to the host, ignore the fiber page.
However, continue to allow the existing power management code to
suspend and resume the fiber page.
Fixes: 6cfb3bcc0641 ("Marvell phy: check link status in case of fiber link.")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/marvell.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 6ad76829c7cd..04e439ad5cff 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1190,7 +1190,8 @@ static int marvell_read_status(struct phy_device *phydev)
int err;
/* Check the fiber mode first */
- if (phydev->supported & SUPPORTED_FIBRE) {
+ if (phydev->supported & SUPPORTED_FIBRE &&
+ phydev->interface != PHY_INTERFACE_MODE_SGMII) {
err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
if (err < 0)
goto error;
--
2.7.4
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [net PATCH 0/5] virtio_net XDP fixes and ajust_header xupport
From: John Fastabend @ 2017-01-12 21:43 UTC (permalink / raw)
To: jasowang, mst
Cc: john.r.fastabend, netdev, john.fastabend, alexei.starovoitov,
daniel
This has a fix to handle small buffer free logic correctly and then
also adds adjust head support.
I pushed adjust head at net (even though its rc3) to avoid having
to push another exception case into virtio_net to catch if the
program uses adjust_head and then block it. If there are any strong
objections to this we can push it at net-next and use a patch from
Jakub to add the exception handling but then user space has to deal
with it either via try/fail logic or via kernel version checks. Granted
we already have some cases that need to be configured to enable XDP
but I don't see any reason to have yet another one when we can fix it
now vs delaying a kernel version.
---
John Fastabend (5):
virtio_net: use dev_kfree_skb for small buffer XDP receive
net: virtio: wrap rtnl_lock in test for calling with lock already held
virtio_net: factor out xdp handler for readability
virtio_net: remove duplicate queue pair binding in XDP
virtio_net: XDP support for adjust_head
drivers/net/virtio_net.c | 251 ++++++++++++++++++++++++++++++++--------------
drivers/virtio/virtio.c | 9 +-
include/linux/virtio.h | 3 +
3 files changed, 183 insertions(+), 80 deletions(-)
^ 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