* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Cong Wang @ 2016-10-06 17:30 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: David Miller, Jamal Hadi Salim, Eric Dumazet, Daniel Borkmann,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <CAOrmypK=TZ=cDCDwy=wJgCsMgJWaMfr5dudEwHNnQzpeYJRfHw@mail.gmail.com>
On Thu, Oct 6, 2016 at 6:30 AM, Shmulik Ladkani
<shmulik.ladkani@gmail.com> wrote:
> Hi,
>
> On Mon, Oct 3, 2016 at 12:45 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Thu, Sep 29, 2016 at 4:03 AM, Shmulik Ladkani
>> <shmulik.ladkani@gmail.com> wrote:
>>> skb2->skb_iif = skb->dev->ifindex;
>>> skb2->dev = dev;
>>> - err = dev_queue_xmit(skb2);
>>> + if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
>>> + err = dev_queue_xmit(skb2);
>>> + else
>>> + netif_receive_skb(skb2);
>>
>> Any reason why not check the return value here?
>
> Rationale: netif_receive_skb returns err if there was no protocol
> handler to deliver the skb to.
> If skb is not caught by any protocol handler, this should not be
> considered an "ingress redirect" error. The redirect action should be
> considered successful.
A quick grep shows there are many places returning NET_RX_DROP:
E.g.
net/ipv4/arp.c: return NET_RX_DROP;
net/ipv4/arp.c: return NET_RX_DROP;
net/ipv4/gre_demux.c: return NET_RX_DROP;
net/ipv4/ip_forward.c: return NET_RX_DROP;
net/ipv4/ip_input.c: return NET_RX_DROP;
net/ipv4/ip_input.c: return NET_RX_DROP;
net/ipv4/ipconfig.c: return NET_RX_DROP;
net/ipv4/ipconfig.c: return NET_RX_DROP;
net/ipv4/raw.c: return NET_RX_DROP;
net/ipv4/raw.c: return NET_RX_DROP;
net/ipv4/xfrm4_input.c: return NET_RX_DROP;
net/ipv6/ip6_input.c: return NET_RX_DROP;
net/ipv6/ip6_input.c: return NET_RX_DROP;
net/ipv6/ip6_input.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
net/ipv6/raw.c: return NET_RX_DROP;
^ permalink raw reply
* RE: Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest
From: Williams, Mitch A @ 2016-10-06 17:58 UTC (permalink / raw)
To: 'Koehrer Mathias (ETAS/ESW5)', Julia Cartwright,
Kirsher, Jeffrey T, Greg
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
linux-rt-users@vger.kernel.org, Sebastian Andrzej Siewior
In-Reply-To: <13c3cd3ffee4490fb22b8de383e51361@FE-MBX1012.de.bosch.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On
> Behalf Of Koehrer Mathias (ETAS/ESW5)
> Sent: Thursday, October 06, 2016 12:02 AM
> To: Julia Cartwright <julia@ni.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; Greg <gvrose8192@gmail.com>
> Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-rt-
> users@vger.kernel.org; Sebastian Andrzej Siewior
> <sebastian.siewior@linutronix.de>
> Subject: Re: [Intel-wired-lan] Kernel 4.6.7-rt13: Intel Ethernet driver igb
> causes huge latencies in cyclictest
>
> Hi all,
> >
> > Although, to be clear, it isn't the fact that there exists 8 threads, it's
> that the device is
> > firing all 8 interrupts at the same time. The time spent in hardirq
> context just waking
> > up all 8 of those threads (and the cyclictest wakeup) is enough to cause
> your
> > regression.
> >
> > netdev/igb folks-
> >
> > Under what conditions should it be expected that the i350 trigger all of
> the TxRx
> > interrupts simultaneously? Any ideas here?
I can answer that! I wrote that code.
We trigger the interrupts once a second because MSI and MSI-X interrupts are NOT guaranteed to be delivered. If this happens, the queues being serviced by this "lost" interrupt are completely stuck.
The device automatically masks each interrupt vector after it fires, expecting the ISR to re-enable the vector after processing is complete. If the interrupt is lost, the ISR doesn't run, so the vector ends up permanently masked. At this point, any queues associated with that vector are stuck. The only recovery is through the netdev watchdog, which initiates a reset.
During development of igb, we had several platforms with chipsets that routinely dropped MSI messages under stress. Things would be running fine and then, pow, all the traffic on a queue would stop.
So, I added code to fire each vector once per second. Just unmasking the interrupt isn't enough - we need to trigger the ISR to get the queues cleaned up so the device can work again.
Is this workaround still needed? I don't know. Modern chipsets don't break a sweat handling gigabit-speed traffic, and they *probably* don't drop interrupts. But I'd still rather have that insurance.
You could try to remove the write to the EICS registers in the watchdog task to see if that takes care of your problem. But I wouldn't want to remove that code permanently, because we have seen lost interrupts in the past.
You also could try staggering the writes so that not all vectors fire each second. But then you'll potentially incur a much longer delay if an interrupt does get lost, which means you could trigger netdev watchdog events.
-Mitch
> >
> > See the start of this thread here:
> >
> > http://lkml.kernel.org/r/d648628329bc446fa63b5e19d4d3fb56@FE-
> > MBX1012.de.bosch.com
> >
> Greg recommended to use "ethtool -L eth2 combined 1" to reduce the number of
> queues.
> I tried that. Now, I have actually only three irqs (eth2, eth2-rx-0, eth2-
> tx-0).
> However the issue remains the same.
>
> I ran the cyclictest again:
> # cyclictest -a -i 105 -m -n -p 80 -t 1 -b 23 -C
> (Note: When using 105us instead of 100us the long latencies seem to occur
> more often).
>
> Here are the final lines of the kernel trace output:
> <idle>-0 4d...2.. 1344661649us : sched_switch: prev_comm=swapper/4
> prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcuc/4 next_pid=56
> next_prio=98
> ktimerso-46 3d...2.. 1344661650us : sched_switch:
> prev_comm=ktimersoftd/3 prev_pid=46 prev_prio=98 prev_state=S ==>
> next_comm=swapper/3 next_pid=0 next_prio=120
> ktimerso-24 1d...2.. 1344661650us : sched_switch:
> prev_comm=ktimersoftd/1 prev_pid=24 prev_prio=98 prev_state=S ==>
> next_comm=swapper/1 next_pid=0 next_prio=120
> ktimerso-79 6d...2.. 1344661650us : sched_switch:
> prev_comm=ktimersoftd/6 prev_pid=79 prev_prio=98 prev_state=S ==>
> next_comm=swapper/6 next_pid=0 next_prio=120
> ktimerso-35 2d...2.. 1344661650us : sched_switch:
> prev_comm=ktimersoftd/2 prev_pid=35 prev_prio=98 prev_state=S ==>
> next_comm=swapper/2 next_pid=0 next_prio=120
> rcuc/5-67 5d...2.. 1344661650us : sched_switch: prev_comm=rcuc/5
> prev_pid=67 prev_prio=98 prev_state=S ==> next_comm=ktimersoftd/5
> next_pid=68 next_prio=98
> rcuc/7-89 7d...2.. 1344661650us : sched_switch: prev_comm=rcuc/7
> prev_pid=89 prev_prio=98 prev_state=S ==> next_comm=ktimersoftd/7
> next_pid=90 next_prio=98
> ktimerso-4 0d...211 1344661650us : sched_wakeup: comm=rcu_preempt
> pid=8 prio=98 target_cpu=000
> rcuc/4-56 4d...2.. 1344661651us : sched_switch: prev_comm=rcuc/4
> prev_pid=56 prev_prio=98 prev_state=S ==> next_comm=ktimersoftd/4
> next_pid=57 next_prio=98
> ktimerso-4 0d...2.. 1344661651us : sched_switch:
> prev_comm=ktimersoftd/0 prev_pid=4 prev_prio=98 prev_state=S ==>
> next_comm=rcu_preempt next_pid=8 next_prio=98
> ktimerso-90 7d...2.. 1344661651us : sched_switch:
> prev_comm=ktimersoftd/7 prev_pid=90 prev_prio=98 prev_state=S ==>
> next_comm=swapper/7 next_pid=0 next_prio=120
> ktimerso-68 5d...2.. 1344661651us : sched_switch:
> prev_comm=ktimersoftd/5 prev_pid=68 prev_prio=98 prev_state=S ==>
> next_comm=swapper/5 next_pid=0 next_prio=120
> rcu_pree-8 0d...3.. 1344661652us : sched_wakeup: comm=rcuop/0 pid=10
> prio=120 target_cpu=000
> ktimerso-57 4d...2.. 1344661652us : sched_switch:
> prev_comm=ktimersoftd/4 prev_pid=57 prev_prio=98 prev_state=S ==>
> next_comm=swapper/4 next_pid=0 next_prio=120
> rcu_pree-8 0d...2.. 1344661653us+: sched_switch: prev_comm=rcu_preempt
> prev_pid=8 prev_prio=98 prev_state=S ==> next_comm=kworker/0:0 next_pid=5
> next_prio=120
> kworker/-5 0dN.h2.. 1344661741us : sched_wakeup: comm=cyclictest
> pid=6314 prio=19 target_cpu=000
> kworker/-5 0d...2.. 1344661742us : sched_switch: prev_comm=kworker/0:0
> prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest
> next_pid=6314 next_prio=19
> cyclicte-6314 0d...2.. 1344661743us : sched_switch: prev_comm=cyclictest
> prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=rcuop/0 next_pid=10
> next_prio=120
> rcuop/0-10 0d...2.. 1344661744us!: sched_switch: prev_comm=rcuop/0
> prev_pid=10 prev_prio=120 prev_state=S ==> next_comm=kworker/0:0 next_pid=5
> next_prio=120
> kworker/-5 0dN.h2.. 1344661858us : sched_wakeup: comm=cyclictest
> pid=6314 prio=19 target_cpu=000
> kworker/-5 0d...2.. 1344661859us : sched_switch: prev_comm=kworker/0:0
> prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest
> next_pid=6314 next_prio=19
> cyclicte-6314 0d...2.. 1344661860us!: sched_switch: prev_comm=cyclictest
> prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5
> next_prio=120
> kworker/-5 0dN.h2.. 1344661966us : sched_wakeup: comm=cyclictest
> pid=6314 prio=19 target_cpu=000
> kworker/-5 0d...2.. 1344661966us : sched_switch: prev_comm=kworker/0:0
> prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest
> next_pid=6314 next_prio=19
> cyclicte-6314 0d...2.. 1344661967us+: sched_switch: prev_comm=cyclictest
> prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5
> next_prio=120
> kworker/-5 0dN.h2.. 1344662052us : sched_wakeup: comm=cyclictest
> pid=6314 prio=19 target_cpu=000
> kworker/-5 0d...2.. 1344662053us : sched_switch: prev_comm=kworker/0:0
> prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest
> next_pid=6314 next_prio=19
> cyclicte-6314 0d...2.. 1344662054us!: sched_switch: prev_comm=cyclictest
> prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5
> next_prio=120
> kworker/-5 0dN.h2.. 1344662168us : sched_wakeup: comm=cyclictest
> pid=6314 prio=19 target_cpu=000
> kworker/-5 0d...2.. 1344662168us : sched_switch: prev_comm=kworker/0:0
> prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest
> next_pid=6314 next_prio=19
> cyclicte-6314 0d...2.. 1344662169us+: sched_switch: prev_comm=cyclictest
> prev_pid=6314 prev_prio=19 prev_state=S ==> next_comm=kworker/0:0 next_pid=5
> next_prio=120
> kworker/-5 0dN.h2.. 1344662255us : sched_wakeup: comm=irq/48-eth2-tx-
> pid=6310 prio=49 target_cpu=000
> kworker/-5 0dN.h3.. 1344662256us : sched_wakeup: comm=irq/47-eth2-rx-
> pid=6309 prio=49 target_cpu=000
> kworker/-5 0d...2.. 1344662256us : sched_switch: prev_comm=kworker/0:0
> prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=irq/48-eth2-tx-
> next_pid=6310 next_prio=49
> irq/48-e-6310 0d...2.. 1344662259us : sched_switch: prev_comm=irq/48-
> eth2-tx- prev_pid=6310 prev_prio=49 prev_state=S ==> next_comm=irq/47-eth2-
> rx- next_pid=6309 next_prio=49
> irq/47-e-6309 0d...2.. 1344662260us+: sched_switch: prev_comm=irq/47-
> eth2-rx- prev_pid=6309 prev_prio=49 prev_state=S ==> next_comm=kworker/0:0
> next_pid=5 next_prio=120
> kworker/-5 0dN.h2.. 1344662300us : sched_wakeup: comm=cyclictest
> pid=6314 prio=19 target_cpu=000
> kworker/-5 0d...2.. 1344662300us : sched_switch: prev_comm=kworker/0:0
> prev_pid=5 prev_prio=120 prev_state=R+ ==> next_comm=cyclictest
> next_pid=6314 next_prio=19
> cyclicte-6314 0.....11 1344662306us : tracing_mark_write: hit latency
> threshold (39 > 23)
>
> Just before the long latency, the irqs "48-eth2-tx" and "48-eth2-rx" are
> active.
> When looking at the 4th line from the bottom, the time for irq/47 is
> 1344662260us, for the next line (kworker) it is 1344662300us.
> Does this mean that the irq/47 took 40us for irq processing? Or is this a
> misinterpretation?
>
> For more lines of the trace please see the attached trace-extract.gz.
>
> Thanks for any feedback.
>
> Regard
>
> Mahias
>
>
>
>
>
^ permalink raw reply
* [PATCH] drivers: net: phy: Correct duplicate MDIO_XGENE entry
From: Laura Abbott @ 2016-10-06 18:22 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: Laura Abbott, netdev, linux-kernel, David S. Miller
An extra entry for MDIO_XGENE got added during merging.
Delete it.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/net/phy/Kconfig | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5078a0d..2651c8d 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -142,6 +142,7 @@ config MDIO_THUNDER
config MDIO_XGENE
tristate "APM X-Gene SoC MDIO bus controller"
+ depends on ARCH_XGENE || COMPILE_TEST
help
This module provides a driver for the MDIO busses found in the
APM X-Gene SoC's.
@@ -320,13 +321,6 @@ config XILINX_GMII2RGMII
the Reduced Gigabit Media Independent Interface(RGMII) between
Ethernet physical media devices and the Gigabit Ethernet controller.
-config MDIO_XGENE
- tristate "APM X-Gene SoC MDIO bus controller"
- depends on ARCH_XGENE || COMPILE_TEST
- help
- This module provides a driver for the MDIO busses found in the
- APM X-Gene SoC's.
-
endif # PHYLIB
config MICREL_KS8995MA
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] Panic when tc_lookup_action_n finds a partially initialized action.
From: Cong Wang @ 2016-10-06 19:01 UTC (permalink / raw)
To: Krister Johansen; +Cc: Jamal Hadi Salim, Linux Kernel Network Developers
In-Reply-To: <20161006061150.GA2525@templeofstupid.com>
On Wed, Oct 5, 2016 at 11:11 PM, Krister Johansen
<kjlx@templeofstupid.com> wrote:
>
> I'm not sure. The reason I didn't take this approach from the outset is
> that all of TC's callers of tcf_register_action pass a pointer to a
> static structure as their *ops argument. The existence of code that
> checks the action for uniqueness suggests that it's possible for
> tcf_register_action to get passed two identical tc_action_ops. If that
> happens in the current code base, we'll also get passed a duplicate
Each tc action module has its own unique ops, and kernel doesn't allow
one module to register twice (either in parallel or not, see
add_unformed_module()), so we should not have a duplicated case.
> pernet_operations pointer. The code in register_pernet_subsys() makes
> no attempt to check for duplicates. If we add a pointer that's already
> in the list, and subsequently call unregister, the results seem
> undefined. It looks like we'll remove the pernet_operations for the
> existing action, assuming we don't corrupt the list in the process.
>
> Is this actually safe? If so, what corner case is the act->type /
> act->kind protecting us from?
ops->type and ops->kind should be unique too, user-space already
relies on this (tc action ls action xxx). The code exists probably just
for sanity check.
So please give that patch a try, let's see if we miss any other problem.
>
>> (Sorry that I don't have the environment to reproduce your bug)
>
> I'm sorry that I didn't do a good job of explaining how we end up in
> this situation in the first place. I can give a few more details,
> because it may explain some of my concern about the request_module()
> call.
>
> The system that encounters this bug launches a bunch of containers from
> systemd on boot. Each container creates a new user, net, pid, and mount
> namespace and begins its setup. When the networking in all of these
> containers, each in a new netns, try to configure TC and no modules are
> loaded we end up with this race.
>
> I can also reproduce by unloading the modules, and then launching a
> bunch of processes that configure tc in new namespaces.
>
> Part of the desire to inhibit extra modprobe calls is that if hundreds
> of these all start at once on boot, it's really unnecessary to have all
> of the rest of them wait while lots of extra modprobe calls are forked
> by the kernel.
You can tell systemd to load these modules before starting these
containers to avoid blocking, no?
Thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Eric Dumazet @ 2016-10-06 19:38 UTC (permalink / raw)
To: Cong Wang
Cc: Shmulik Ladkani, David Miller, Jamal Hadi Salim, Eric Dumazet,
Daniel Borkmann, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpXB_LGd0GLmuyjcUqSvBy9nKX_02TEdm4GF3V-yX_rr0g@mail.gmail.com>
On Thu, 2016-10-06 at 10:30 -0700, Cong Wang wrote:
> On Thu, Oct 6, 2016 at 6:30 AM, Shmulik Ladkani
> <shmulik.ladkani@gmail.com> wrote:
> > Hi,
> >
> > On Mon, Oct 3, 2016 at 12:45 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >> On Thu, Sep 29, 2016 at 4:03 AM, Shmulik Ladkani
> >> <shmulik.ladkani@gmail.com> wrote:
> >>> skb2->skb_iif = skb->dev->ifindex;
> >>> skb2->dev = dev;
> >>> - err = dev_queue_xmit(skb2);
> >>> + if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
> >>> + err = dev_queue_xmit(skb2);
> >>> + else
> >>> + netif_receive_skb(skb2);
> >>
> >> Any reason why not check the return value here?
> >
> > Rationale: netif_receive_skb returns err if there was no protocol
> > handler to deliver the skb to.
> > If skb is not caught by any protocol handler, this should not be
> > considered an "ingress redirect" error. The redirect action should be
> > considered successful.
>
> A quick grep shows there are many places returning NET_RX_DROP:
> E.g.
And another quick grep shows that out of 142 drivers, only one [1] of
them (incorrectly) checks netif_receive_skb() return value.
Real question is more like : what is the impact of propagating an error
at this point ?
[1] drivers/net/caif/caif_virtio.c
This is incorrect because at the driver layer, the packet was received
and the rx_packets/rx_bytes counters _should_ be incremented regardless
of packet being dropped or not by upper layers.
^ permalink raw reply
* Re: [PATCH] drivers: net: phy: Correct duplicate MDIO_XGENE entry
From: Florian Fainelli @ 2016-10-06 19:48 UTC (permalink / raw)
To: Laura Abbott, Andrew Lunn; +Cc: netdev, linux-kernel, David S. Miller
In-Reply-To: <1475778171-10905-1-git-send-email-labbott@redhat.com>
On 10/06/2016 11:22 AM, Laura Abbott wrote:
> An extra entry for MDIO_XGENE got added during merging.
> Delete it.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net-next 0/2] drivers: net: xgene: fix: Use GPIO to get link status
From: Iyappan Subramanian @ 2016-10-06 21:35 UTC (permalink / raw)
To: davem, netdev
Cc: linux-arm-kernel, arnd, patches, Iyappan Subramanian, Quan Nguyen
Since the link value reported by the link status register is not
reliable if no SPF module inserted, this patchset fixes the issue by
using GPIO to determine the link status when no module inserted.
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: Quan Nguyen <qnguyen@apm.com>
---
Iyappan Subramanian (2):
drivers: net: xgene: fix: Use GPIO to get link status
arm64: xgene: defconfig: Enable Standby GPIO
arch/arm64/configs/defconfig | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 6 +++++-
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c | 19 +++++++++++++++++--
4 files changed, 24 insertions(+), 3 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net-next 1/2] drivers: net: xgene: fix: Use GPIO to get link status
From: Iyappan Subramanian @ 2016-10-06 21:35 UTC (permalink / raw)
To: davem, netdev
Cc: linux-arm-kernel, arnd, patches, Iyappan Subramanian, Quan Nguyen
In-Reply-To: <1475789758-5196-1-git-send-email-isubramanian@apm.com>
The link value reported by the link status register is not
reliable when no SPF module inserted. This patchset fixes this
issue by using GPIO to determine the link status.
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: Quan Nguyen <qnguyen@apm.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 6 +++++-
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c | 19 +++++++++++++++++--
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 429f18f..f75d955 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1381,9 +1381,13 @@ static void xgene_enet_gpiod_get(struct xgene_enet_pdata *pdata)
{
struct device *dev = &pdata->pdev->dev;
- if (pdata->phy_mode != PHY_INTERFACE_MODE_XGMII)
+ pdata->sfp_gpio_en = false;
+ if (pdata->phy_mode != PHY_INTERFACE_MODE_XGMII ||
+ (!device_property_present(dev, "sfp-gpios") &&
+ !device_property_present(dev, "rxlos-gpios")))
return;
+ pdata->sfp_gpio_en = true;
pdata->sfp_rdy = gpiod_get(dev, "rxlos", GPIOD_IN);
if (IS_ERR(pdata->sfp_rdy))
pdata->sfp_rdy = gpiod_get(dev, "sfp", GPIOD_IN);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 0cda58f..011965b 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -219,6 +219,7 @@ struct xgene_enet_pdata {
u8 rx_delay;
bool mdio_driver;
struct gpio_desc *sfp_rdy;
+ bool sfp_gpio_en;
};
struct xgene_indirect_ctl {
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c b/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
index 6475f38..d1758b0 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c
@@ -415,16 +415,31 @@ static void xgene_enet_clear(struct xgene_enet_pdata *pdata,
xgene_enet_wr_ring_if(pdata, addr, data);
}
+static int xgene_enet_gpio_lookup(struct xgene_enet_pdata *pdata)
+{
+ struct device *dev = &pdata->pdev->dev;
+
+ pdata->sfp_rdy = gpiod_get(dev, "rxlos", GPIOD_IN);
+ if (IS_ERR(pdata->sfp_rdy))
+ pdata->sfp_rdy = gpiod_get(dev, "sfp", GPIOD_IN);
+
+ if (IS_ERR(pdata->sfp_rdy))
+ return -ENODEV;
+
+ return 0;
+}
+
static void xgene_enet_link_state(struct work_struct *work)
{
struct xgene_enet_pdata *pdata = container_of(to_delayed_work(work),
struct xgene_enet_pdata, link_work);
- struct gpio_desc *sfp_rdy = pdata->sfp_rdy;
struct net_device *ndev = pdata->ndev;
u32 link_status, poll_interval;
link_status = xgene_enet_link_status(pdata);
- if (link_status && !IS_ERR(sfp_rdy) && !gpiod_get_value(sfp_rdy))
+ if (pdata->sfp_gpio_en && link_status &&
+ (!IS_ERR(pdata->sfp_rdy) || !xgene_enet_gpio_lookup(pdata)) &&
+ !gpiod_get_value(pdata->sfp_rdy))
link_status = 0;
if (link_status) {
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] arm64: xgene: defconfig: Enable Standby GPIO
From: Iyappan Subramanian @ 2016-10-06 21:35 UTC (permalink / raw)
To: davem, netdev
Cc: linux-arm-kernel, arnd, patches, Iyappan Subramanian, Quan Nguyen
In-Reply-To: <1475789758-5196-1-git-send-email-isubramanian@apm.com>
Enable CONFIG_GPIO_XGENE_SB.
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Signed-off-by: Quan Nguyen <qnguyen@apm.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index eadf485..be52a00 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -240,6 +240,7 @@ CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_PL061=y
CONFIG_GPIO_RCAR=y
CONFIG_GPIO_XGENE=y
+CONFIG_GPIO_XGENE_SB=y
CONFIG_GPIO_PCA953X=y
CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GPIO_MAX77620=y
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Jamal Hadi Salim @ 2016-10-07 0:17 UTC (permalink / raw)
To: Cong Wang, Shmulik Ladkani
Cc: David Miller, Eric Dumazet, Daniel Borkmann,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <CAM_iQpXB_LGd0GLmuyjcUqSvBy9nKX_02TEdm4GF3V-yX_rr0g@mail.gmail.com>
On 16-10-06 01:30 PM, Cong Wang wrote:
> On Thu, Oct 6, 2016 at 6:30 AM, Shmulik Ladkani
> <shmulik.ladkani@gmail.com> wrote:
>> Hi,
>>
>> On Mon, Oct 3, 2016 at 12:45 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> On Thu, Sep 29, 2016 at 4:03 AM, Shmulik Ladkani
>>> <shmulik.ladkani@gmail.com> wrote:
>>>> skb2->skb_iif = skb->dev->ifindex;
>>>> skb2->dev = dev;
>>>> - err = dev_queue_xmit(skb2);
>>>> + if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
>>>> + err = dev_queue_xmit(skb2);
>>>> + else
>>>> + netif_receive_skb(skb2);
>>>
>>> Any reason why not check the return value here?
>>
>> Rationale: netif_receive_skb returns err if there was no protocol
>> handler to deliver the skb to.
>> If skb is not caught by any protocol handler, this should not be
>> considered an "ingress redirect" error. The redirect action should be
>> considered successful.
>
I dont believe we need to bother with the return code in this case.
The core netif_receive_skb() code already increments any necessary
stats.
cheers,
jamal
^ permalink raw reply
* Re: [net-next 00/13] fsl/fman: cleanup and small fixes
From: David Miller @ 2016-10-07 0:32 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, linuxppc-dev, linux-kernel, linuxdev.baldrick
In-Reply-To: <1475566237-4948-1-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Tue, 4 Oct 2016 10:30:24 +0300
> This series contains fixes for the DPAA FMan driver.
> Adding myself as maintainer of the driver.
>
> The following are changes since commit a4cc96d1f0170b779c32c6b2cc58764f5d2cdef0
> net: phy: Add Edge-rate driver for Microsemi PHYs.
> and are available on the fman-next branch in the git repository at
> git://git.freescale.com/ppc/upstream/linux.git
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] xen-netback: guest rx side refactor
From: David Miller @ 2016-10-07 0:38 UTC (permalink / raw)
To: paul.durrant; +Cc: netdev, xen-devel
In-Reply-To: <1475573358-32414-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Tue, 4 Oct 2016 10:29:11 +0100
> This series refactors the guest rx side of xen-netback:
>
> - The code is moved into its own source module.
>
> - The prefix variant of GSO handling is retired (since it is no longer
> in common use, and alternatives exist).
>
> - The code is then simplified and modifications made to improve
> performance.
>
> v2:
> - Rebased onto refreshed net-next
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: axienet: Add missing \n to end of dev_err messages
From: David Miller @ 2016-10-07 0:41 UTC (permalink / raw)
To: colin.king
Cc: anirudh, John.Linn, michal.simek, soren.brinkmann, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20161004111141.11768-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 4 Oct 2016 12:11:41 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix, dev_err messages are missing a \n, so add it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ps3_gelic: Add missing \n to end of deb_dbg message
From: David Miller @ 2016-10-07 0:41 UTC (permalink / raw)
To: colin.king; +Cc: geoff, benh, paulus, mpe, netdev, linuxppc-dev, linux-kernel
In-Reply-To: <20161004111554.11881-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 4 Oct 2016 12:15:54 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix, dev_dbg message is missing a \n, so add it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH][V2] net: hns: Add missing \n to end of dev_err messages, tidy up text
From: David Miller @ 2016-10-07 0:44 UTC (permalink / raw)
To: colin.king
Cc: yisen.zhuang, salil.mehta, yankejian, huangdaode, lipeng321,
lisheng011, netdev, linux-kernel
In-Reply-To: <20161004125701.13032-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 4 Oct 2016 13:57:01 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix, dev_err messages are missing a \n, so add it. Also
> fix grammer, spelling mistake and add white spaces to various
> error messages.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Cong Wang @ 2016-10-07 0:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: Shmulik Ladkani, David Miller, Jamal Hadi Salim, Eric Dumazet,
Daniel Borkmann, Linux Kernel Network Developers
In-Reply-To: <1475782699.28155.251.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, Oct 6, 2016 at 12:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> And another quick grep shows that out of 142 drivers, only one [1] of
> them (incorrectly) checks netif_receive_skb() return value.
>
act_mirred is not a driver, apparently.
> Real question is more like : what is the impact of propagating an error
> at this point ?
_If_ we are going to just propagate the error like egress, then
the difference is m->tcf_action (PIPE or STOLEN) vs TC_ACT_SHOT.
And this error code is propagated from tcf_action_exec() up to
qdisc layer...
^ permalink raw reply
* Re: [net-next PATCH] drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay
From: David Miller @ 2016-10-07 0:45 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, grygorii.strashko, linux-omap, nsekhar
In-Reply-To: <20161004133729.12564-1-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Tue, 4 Oct 2016 19:07:29 +0530
> Add support to enable CPSW RGMII internal delay (id mode) bits
> when rgmii internal delay is configured in phy.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: phy: Add Wake-on-LAN driver for Microsemi PHYs.
From: David Miller @ 2016-10-07 0:48 UTC (permalink / raw)
To: Raju.Lakkaraju; +Cc: netdev, f.fainelli, Allan.Nielsen, andrew
In-Reply-To: <1475657367-13600-1-git-send-email-Raju.Lakkaraju@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Date: Wed, 5 Oct 2016 14:19:27 +0530
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> Wake-on-LAN (WoL) is an Ethernet networking standard that allows
> a computer/device to be turned on or awakened by a network message.
>
> VSC8531 PHY can support this feature configure by driver set function.
> WoL status get by driver get function.
>
> Tested on Beaglebone Black with VSC 8531 PHY.
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Applied.
^ permalink raw reply
* Re: [PATCH] devicetree: net: micrel-ksz90x1.txt: Properly explain skew settings
From: David Miller @ 2016-10-07 0:49 UTC (permalink / raw)
To: mike.looijmans-Oq418RWZeHk
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1475676188-10639-1-git-send-email-mike.looijmans-Oq418RWZeHk@public.gmane.org>
From: Mike Looijmans <mike.looijmans-Oq418RWZeHk@public.gmane.org>
Date: Wed, 5 Oct 2016 16:03:08 +0200
> The KSZ9031 skew registers contain an offset, the chip's default value
> is "neutral" which does not add any skew. Programming a 0 into a skew
> property will actually set it the maximal negative adjustment and not
> to a neutral position as one would expect.
>
> Explain this situation in the devicetree binding documentation and list
> the settings that the chip considers neutral.
>
> Changing the implementation to accept negative values would have been
> a better solution, but would break existing configurations.
>
> Signed-off-by: Mike Looijmans <mike.looijmans-Oq418RWZeHk@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Cong Wang @ 2016-10-07 0:49 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Shmulik Ladkani, David Miller, Eric Dumazet, Daniel Borkmann,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <2d606b1d-0281-403b-cf82-c02c785c0f10@mojatatu.com>
On Thu, Oct 6, 2016 at 5:17 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> I dont believe we need to bother with the return code in this case.
Why?
For a quick example, STOLEN vs. SHOT:
result = tc_classify(skb, filter, &res, false);
if (result >= 0) {
#ifdef CONFIG_NET_CLS_ACT
switch (result) {
case TC_ACT_STOLEN:
case TC_ACT_QUEUED:
*qerr = NET_XMIT_SUCCESS | __NET_XMIT_STOLEN;
case TC_ACT_SHOT:
return 0;
}
#endif
Note, *qerr is the return value to ->enqueue().
^ permalink raw reply
* Re: [PATCH net] packet: call fanout_release, while UNREGISTERING a netdev
From: David Miller @ 2016-10-07 0:50 UTC (permalink / raw)
To: anoob.soman; +Cc: netdev
In-Reply-To: <1475676774-18726-1-git-send-email-anoob.soman@citrix.com>
From: Anoob Soman <anoob.soman@citrix.com>
Date: Wed, 5 Oct 2016 15:12:54 +0100
> If a socket has FANOUT sockopt set, a new proto_hook is registered
> as part of fanout_add(). When processing a NETDEV_UNREGISTER event in
> af_packet, __fanout_unlink is called for all sockets, but prot_hook which was
> registered as part of fanout_add is not removed. Call fanout_release, on a
> NETDEV_UNREGISTER, which removes prot_hook and removes fanout from the
> fanout_list.
>
> This fixes BUG_ON(!list_empty(&dev->ptype_specific)) in netdev_run_todo()
>
> Signed-off-by: Anoob Soman <anoob.soman@citrix.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: disallow rtr_solicits < -1
From: Cong Wang @ 2016-10-07 0:53 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: David Miller, Linux NetDev, Erik Kline, Lorenzo Colitti
In-Reply-To: <CANP3RGdVquyFe1VA2mKMC1HNgnXPhmpsv45R-7P6boWCb8oC2A@mail.gmail.com>
On Mon, Oct 3, 2016 at 11:40 PM, Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>> Please remove the const qualifier and the casts to be consistent
>> with how we handle this elsewhere.
>>
>> Thanks.
>
> I can of course trivially make that change.
>
> But:
>
> (on net-next/master)
> git grep 'extra[12].*=.*\(void *[*]\)'
>
> currently finds 45 matches, and this patch adds a 46th.
Seems the sysctl layer should make them const, but I never look
into it, it doesn't look like it needs to modify these min/max consts.
^ permalink raw reply
* Re: [PATCH net] netlink: do not enter direct reclaim from netlink_dump()
From: David Miller @ 2016-10-07 0:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ast, gthelen
In-Reply-To: <1475694798.28155.215.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Oct 2016 04:13:18 +0900
> From: Eric Dumazet <edumazet@google.com>
>
> Since linux-3.15, netlink_dump() can use up to 16384 bytes skb
> allocations.
>
> Due to struct skb_shared_info ~320 bytes overhead, we end up using
> order-3 (on x86) page allocations, that might trigger direct reclaim and
> add stress.
>
> The intent was really to attempt a large allocation but immediately
> fallback to a smaller one (order-1 on x86) in case of memory stress.
>
> On recent kernels (linux-4.4), we can remove __GFP_DIRECT_RECLAIM to
> meet the goal. Old kernels would need to remove __GFP_WAIT
>
> While we are at it, since we do an order-3 allocation, allow to use
> all the allocated bytes instead of 16384 to reduce syscalls during
> large dumps.
>
> iproute2 already uses 32KB recvmsg() buffer sizes.
>
> Alexei provided an initial patch downsizing to SKB_WITH_OVERHEAD(16384)
>
> Fixes: 9063e21fb026 ("netlink: autosize skb lengthes")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Alexei Starovoitov <ast@kernel.org>
> Cc: Greg Thelen <gthelen@google.com>
> ---
> Note: This will apply to net tree when it has synced with Linus tree.
Applied.
^ permalink raw reply
* Re: [PATCH net-next 00/13] rxrpc: Fixes
From: David Miller @ 2016-10-07 1:04 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <147574823645.30350.16131031458272035074.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 06 Oct 2016 11:03:56 +0100
> This set of patches contains a bunch of fixes:
...
Pulled, thanks David.
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] net: ethernet: mediatek: check the hw lro capability by the chip id instead of the dtsi
From: David Miller @ 2016-10-07 1:08 UTC (permalink / raw)
To: nelson.chang; +Cc: john, nbd, netdev, linux-mediatek, nelsonch.tw
In-Reply-To: <1475754243-12557-1-git-send-email-nelson.chang@mediatek.com>
From: Nelson Chang <nelson.chang@mediatek.com>
Date: Thu, 6 Oct 2016 19:44:00 +0800
> The series modify to check if hw lro is supported by the chip id.
>
> changes since v3:
> - Refine mtk_is_hwlro_supported() function
>
> changes since v2:
> - Refine mtk_get_chip_id() function
>
> changes since v1:
> - Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi.
Series applied, thanks.
^ 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