<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/dsa, branch v5.4-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>net: dsa: sja1105: Fix sleeping while atomic in .port_hwtstamp_set</title>
<updated>2019-10-02T16:19:53+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>olteanv@gmail.com</email>
</author>
<published>2019-10-01T18:58:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3e8db7e56082156a37b71d7334860c10fcea8025'/>
<id>3e8db7e56082156a37b71d7334860c10fcea8025</id>
<content type='text'>
Currently this stack trace can be seen with CONFIG_DEBUG_ATOMIC_SLEEP=y:

[   41.568348] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909
[   41.576757] in_atomic(): 1, irqs_disabled(): 0, pid: 208, name: ptp4l
[   41.583212] INFO: lockdep is turned off.
[   41.587123] CPU: 1 PID: 208 Comm: ptp4l Not tainted 5.3.0-rc6-01445-ge950f2d4bc7f-dirty #1827
[   41.599873] [&lt;c0313d7c&gt;] (unwind_backtrace) from [&lt;c030e13c&gt;] (show_stack+0x10/0x14)
[   41.607584] [&lt;c030e13c&gt;] (show_stack) from [&lt;c1212d50&gt;] (dump_stack+0xd4/0x100)
[   41.614863] [&lt;c1212d50&gt;] (dump_stack) from [&lt;c037dfc8&gt;] (___might_sleep+0x1c8/0x2b4)
[   41.622574] [&lt;c037dfc8&gt;] (___might_sleep) from [&lt;c122ea90&gt;] (__mutex_lock+0x48/0xab8)
[   41.630368] [&lt;c122ea90&gt;] (__mutex_lock) from [&lt;c122f51c&gt;] (mutex_lock_nested+0x1c/0x24)
[   41.638340] [&lt;c122f51c&gt;] (mutex_lock_nested) from [&lt;c0c6fe08&gt;] (sja1105_static_config_reload+0x30/0x27c)
[   41.647779] [&lt;c0c6fe08&gt;] (sja1105_static_config_reload) from [&lt;c0c7015c&gt;] (sja1105_hwtstamp_set+0x108/0x1cc)
[   41.657562] [&lt;c0c7015c&gt;] (sja1105_hwtstamp_set) from [&lt;c0feb650&gt;] (dev_ifsioc+0x18c/0x330)
[   41.665788] [&lt;c0feb650&gt;] (dev_ifsioc) from [&lt;c0febbd8&gt;] (dev_ioctl+0x320/0x6e8)
[   41.673064] [&lt;c0febbd8&gt;] (dev_ioctl) from [&lt;c0f8b1f4&gt;] (sock_ioctl+0x334/0x5e8)
[   41.680340] [&lt;c0f8b1f4&gt;] (sock_ioctl) from [&lt;c05404a8&gt;] (do_vfs_ioctl+0xb0/0xa10)
[   41.687789] [&lt;c05404a8&gt;] (do_vfs_ioctl) from [&lt;c0540e3c&gt;] (ksys_ioctl+0x34/0x58)
[   41.695151] [&lt;c0540e3c&gt;] (ksys_ioctl) from [&lt;c0301000&gt;] (ret_fast_syscall+0x0/0x28)
[   41.702768] Exception stack(0xe8495fa8 to 0xe8495ff0)
[   41.707796] 5fa0:                   beff4a8c 00000001 00000011 000089b0 beff4a8c beff4a80
[   41.715933] 5fc0: beff4a8c 00000001 0000000c 00000036 b6fa98c8 004e19c1 00000001 00000000
[   41.724069] 5fe0: 004dcedc beff4a6c 004c0738 b6e7af4c
[   41.729860] BUG: scheduling while atomic: ptp4l/208/0x00000002
[   41.735682] INFO: lockdep is turned off.

Enabling RX timestamping will logically disturb the fastpath (processing
of meta frames). Replace bool hwts_rx_en with a bit that is checked
atomically from the fastpath and temporarily unset from the sleepable
context during a change of the RX timestamping process (a destructive
operation anyways, requires switch reset).
If found unset, the fastpath (net/dsa/tag_sja1105.c) will just drop any
received meta frame and not take the meta_lock at all.

Fixes: a602afd200f5 ("net: dsa: sja1105: Expose PTP timestamping ioctls to userspace")
Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently this stack trace can be seen with CONFIG_DEBUG_ATOMIC_SLEEP=y:

[   41.568348] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909
[   41.576757] in_atomic(): 1, irqs_disabled(): 0, pid: 208, name: ptp4l
[   41.583212] INFO: lockdep is turned off.
[   41.587123] CPU: 1 PID: 208 Comm: ptp4l Not tainted 5.3.0-rc6-01445-ge950f2d4bc7f-dirty #1827
[   41.599873] [&lt;c0313d7c&gt;] (unwind_backtrace) from [&lt;c030e13c&gt;] (show_stack+0x10/0x14)
[   41.607584] [&lt;c030e13c&gt;] (show_stack) from [&lt;c1212d50&gt;] (dump_stack+0xd4/0x100)
[   41.614863] [&lt;c1212d50&gt;] (dump_stack) from [&lt;c037dfc8&gt;] (___might_sleep+0x1c8/0x2b4)
[   41.622574] [&lt;c037dfc8&gt;] (___might_sleep) from [&lt;c122ea90&gt;] (__mutex_lock+0x48/0xab8)
[   41.630368] [&lt;c122ea90&gt;] (__mutex_lock) from [&lt;c122f51c&gt;] (mutex_lock_nested+0x1c/0x24)
[   41.638340] [&lt;c122f51c&gt;] (mutex_lock_nested) from [&lt;c0c6fe08&gt;] (sja1105_static_config_reload+0x30/0x27c)
[   41.647779] [&lt;c0c6fe08&gt;] (sja1105_static_config_reload) from [&lt;c0c7015c&gt;] (sja1105_hwtstamp_set+0x108/0x1cc)
[   41.657562] [&lt;c0c7015c&gt;] (sja1105_hwtstamp_set) from [&lt;c0feb650&gt;] (dev_ifsioc+0x18c/0x330)
[   41.665788] [&lt;c0feb650&gt;] (dev_ifsioc) from [&lt;c0febbd8&gt;] (dev_ioctl+0x320/0x6e8)
[   41.673064] [&lt;c0febbd8&gt;] (dev_ioctl) from [&lt;c0f8b1f4&gt;] (sock_ioctl+0x334/0x5e8)
[   41.680340] [&lt;c0f8b1f4&gt;] (sock_ioctl) from [&lt;c05404a8&gt;] (do_vfs_ioctl+0xb0/0xa10)
[   41.687789] [&lt;c05404a8&gt;] (do_vfs_ioctl) from [&lt;c0540e3c&gt;] (ksys_ioctl+0x34/0x58)
[   41.695151] [&lt;c0540e3c&gt;] (ksys_ioctl) from [&lt;c0301000&gt;] (ret_fast_syscall+0x0/0x28)
[   41.702768] Exception stack(0xe8495fa8 to 0xe8495ff0)
[   41.707796] 5fa0:                   beff4a8c 00000001 00000011 000089b0 beff4a8c beff4a80
[   41.715933] 5fc0: beff4a8c 00000001 0000000c 00000036 b6fa98c8 004e19c1 00000001 00000000
[   41.724069] 5fe0: 004dcedc beff4a6c 004c0738 b6e7af4c
[   41.729860] BUG: scheduling while atomic: ptp4l/208/0x00000002
[   41.735682] INFO: lockdep is turned off.

Enabling RX timestamping will logically disturb the fastpath (processing
of meta frames). Replace bool hwts_rx_en with a bit that is checked
atomically from the fastpath and temporarily unset from the sleepable
context during a change of the RX timestamping process (a destructive
operation anyways, requires switch reset).
If found unset, the fastpath (net/dsa/tag_sja1105.c) will just drop any
received meta frame and not take the meta_lock at all.

Fixes: a602afd200f5 ("net: dsa: sja1105: Expose PTP timestamping ioctls to userspace")
Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge ra.kernel.org:/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2019-09-17T21:51:10+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2019-09-17T21:51:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1bab8d4c488be22d57f9dd09968c90a0ddc413bf'/>
<id>1bab8d4c488be22d57f9dd09968c90a0ddc413bf</id>
<content type='text'>
Pull in bug fixes from 'net' tree for the merge window.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull in bug fixes from 'net' tree for the merge window.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: dsa: sja1105: Advertise the 8 TX queues</title>
<updated>2019-09-16T19:32:57+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>olteanv@gmail.com</email>
</author>
<published>2019-09-15T02:00:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5f06c63bd3f03767e763c3ba2a361299247001a3'/>
<id>5f06c63bd3f03767e763c3ba2a361299247001a3</id>
<content type='text'>
This is a preparation patch for the tc-taprio offload (and potentially
for other future offloads such as tc-mqprio).

Instead of looking directly at skb-&gt;priority during xmit, let's get the
netdev queue and the queue-to-traffic-class mapping, and put the
resulting traffic class into the dsa_8021q PCP field. The switch is
configured with a 1-to-1 PCP-to-ingress-queue-to-egress-queue mapping
(see vlan_pmap in sja1105_main.c), so the effect is that we can inject
into a front-panel's egress traffic class through VLAN tagging from
Linux, completely transparently.

Unfortunately the switch doesn't look at the VLAN PCP in the case of
management traffic to/from the CPU (link-local frames at
01-80-C2-xx-xx-xx or 01-1B-19-xx-xx-xx) so we can't alter the
transmission queue of this type of traffic on a frame-by-frame basis. It
is only selected through the "hostprio" setting which ATM is harcoded in
the driver to 7.

Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a preparation patch for the tc-taprio offload (and potentially
for other future offloads such as tc-mqprio).

Instead of looking directly at skb-&gt;priority during xmit, let's get the
netdev queue and the queue-to-traffic-class mapping, and put the
resulting traffic class into the dsa_8021q PCP field. The switch is
configured with a 1-to-1 PCP-to-ingress-queue-to-egress-queue mapping
(see vlan_pmap in sja1105_main.c), so the effect is that we can inject
into a front-panel's egress traffic class through VLAN tagging from
Linux, completely transparently.

Unfortunately the switch doesn't look at the VLAN PCP in the case of
management traffic to/from the CPU (link-local frames at
01-80-C2-xx-xx-xx or 01-1B-19-xx-xx-xx) so we can't alter the
transmission queue of this type of traffic on a frame-by-frame basis. It
is only selected through the "hostprio" setting which ATM is harcoded in
the driver to 7.

Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: dsa: Pass ndo_setup_tc slave callback to drivers</title>
<updated>2019-09-16T19:32:57+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>olteanv@gmail.com</email>
</author>
<published>2019-09-15T01:59:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=47d23af29220bf38c312cf434487500d93789c7c'/>
<id>47d23af29220bf38c312cf434487500d93789c7c</id>
<content type='text'>
DSA currently handles shared block filters (for the classifier-action
qdisc) in the core due to what I believe are simply pragmatic reasons -
hiding the complexity from drivers and offerring a simple API for port
mirroring.

Extend the dsa_slave_setup_tc function by passing all other qdisc
offloads to the driver layer, where the driver may choose what it
implements and how. DSA is simply a pass-through in this case.

Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Acked-by: Kurt Kanzenbach &lt;kurt@linutronix.de&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
DSA currently handles shared block filters (for the classifier-action
qdisc) in the core due to what I believe are simply pragmatic reasons -
hiding the complexity from drivers and offerring a simple API for port
mirroring.

Extend the dsa_slave_setup_tc function by passing all other qdisc
offloads to the driver layer, where the driver may choose what it
implements and how. DSA is simply a pass-through in this case.

Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Acked-by: Kurt Kanzenbach &lt;kurt@linutronix.de&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: dsa: Fix load order between DSA drivers and taggers</title>
<updated>2019-09-15T18:49:19+00:00</updated>
<author>
<name>Andrew Lunn</name>
<email>andrew@lunn.ch</email>
</author>
<published>2019-09-12T13:16:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=23426a25e55a417dc104df08781b6eff95e65f3f'/>
<id>23426a25e55a417dc104df08781b6eff95e65f3f</id>
<content type='text'>
The DSA core, DSA taggers and DSA drivers all make use of
module_init(). Hence they get initialised at device_initcall() time.
The ordering is non-deterministic. It can be a DSA driver is bound to
a device before the needed tag driver has been initialised, resulting
in the message:

No tagger for this switch

Rather than have this be fatal, return -EPROBE_DEFER so that it is
tried again later once all the needed drivers have been loaded.

Fixes: d3b8c04988ca ("dsa: Add boilerplate helper to register DSA tag driver modules")
Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The DSA core, DSA taggers and DSA drivers all make use of
module_init(). Hence they get initialised at device_initcall() time.
The ordering is non-deterministic. It can be a DSA driver is bound to
a device before the needed tag driver has been initialised, resulting
in the message:

No tagger for this switch

Rather than have this be fatal, return -EPROBE_DEFER so that it is
tried again later once all the needed drivers have been loaded.

Fixes: d3b8c04988ca ("dsa: Add boilerplate helper to register DSA tag driver modules")
Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON</title>
<updated>2019-09-12T10:36:12+00:00</updated>
<author>
<name>George McCollister</name>
<email>george.mccollister@gmail.com</email>
</author>
<published>2019-09-10T13:18:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f4073e9164b5a9f5cc4f395a98caea89a5db35cd'/>
<id>f4073e9164b5a9f5cc4f395a98caea89a5db35cd</id>
<content type='text'>
Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
NET_DSA_TAG_KSZ. Update the description to mention the three switch
families it supports. No functional change.

Signed-off-by: George McCollister &lt;george.mccollister@gmail.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
NET_DSA_TAG_KSZ. Update the description to mention the three switch
families it supports. No functional change.

Signed-off-by: George McCollister &lt;george.mccollister@gmail.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: dsa: Fix off-by-one number of calls to devlink_port_unregister</title>
<updated>2019-09-02T18:59:29+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>olteanv@gmail.com</email>
</author>
<published>2019-08-31T12:46:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4ba0ebbc6cdecb9fad7c551a3d97b172ebc7b2fa'/>
<id>4ba0ebbc6cdecb9fad7c551a3d97b172ebc7b2fa</id>
<content type='text'>
When a function such as dsa_slave_create fails, currently the following
stack trace can be seen:

[    2.038342] sja1105 spi0.1: Probed switch chip: SJA1105T
[    2.054556] sja1105 spi0.1: Reset switch and programmed static config
[    2.063837] sja1105 spi0.1: Enabled switch tagging
[    2.068706] fsl-gianfar soc:ethernet@2d90000 eth2: error -19 setting up slave phy
[    2.076371] ------------[ cut here ]------------
[    2.080973] WARNING: CPU: 1 PID: 21 at net/core/devlink.c:6184 devlink_free+0x1b4/0x1c0
[    2.088954] Modules linked in:
[    2.092005] CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.3.0-rc6-01360-g41b52e38d2b6-dirty #1746
[    2.100912] Hardware name: Freescale LS1021A
[    2.105162] Workqueue: events deferred_probe_work_func
[    2.110287] [&lt;c03133a4&gt;] (unwind_backtrace) from [&lt;c030d8cc&gt;] (show_stack+0x10/0x14)
[    2.117992] [&lt;c030d8cc&gt;] (show_stack) from [&lt;c10b08d8&gt;] (dump_stack+0xb4/0xc8)
[    2.125180] [&lt;c10b08d8&gt;] (dump_stack) from [&lt;c0349d04&gt;] (__warn+0xe0/0xf8)
[    2.132018] [&lt;c0349d04&gt;] (__warn) from [&lt;c0349e34&gt;] (warn_slowpath_null+0x40/0x48)
[    2.139549] [&lt;c0349e34&gt;] (warn_slowpath_null) from [&lt;c0f19d74&gt;] (devlink_free+0x1b4/0x1c0)
[    2.147772] [&lt;c0f19d74&gt;] (devlink_free) from [&lt;c1064fc0&gt;] (dsa_switch_teardown+0x60/0x6c)
[    2.155907] [&lt;c1064fc0&gt;] (dsa_switch_teardown) from [&lt;c1065950&gt;] (dsa_register_switch+0x8e4/0xaa8)
[    2.164821] [&lt;c1065950&gt;] (dsa_register_switch) from [&lt;c0ba7fe4&gt;] (sja1105_probe+0x21c/0x2ec)
[    2.173216] [&lt;c0ba7fe4&gt;] (sja1105_probe) from [&lt;c0b35948&gt;] (spi_drv_probe+0x80/0xa4)
[    2.180920] [&lt;c0b35948&gt;] (spi_drv_probe) from [&lt;c0a4c1cc&gt;] (really_probe+0x108/0x400)
[    2.188711] [&lt;c0a4c1cc&gt;] (really_probe) from [&lt;c0a4c694&gt;] (driver_probe_device+0x78/0x1bc)
[    2.196933] [&lt;c0a4c694&gt;] (driver_probe_device) from [&lt;c0a4a3dc&gt;] (bus_for_each_drv+0x58/0xb8)
[    2.205414] [&lt;c0a4a3dc&gt;] (bus_for_each_drv) from [&lt;c0a4c024&gt;] (__device_attach+0xd0/0x168)
[    2.213637] [&lt;c0a4c024&gt;] (__device_attach) from [&lt;c0a4b1d0&gt;] (bus_probe_device+0x84/0x8c)
[    2.221772] [&lt;c0a4b1d0&gt;] (bus_probe_device) from [&lt;c0a4b72c&gt;] (deferred_probe_work_func+0x84/0xc4)
[    2.230686] [&lt;c0a4b72c&gt;] (deferred_probe_work_func) from [&lt;c03650a4&gt;] (process_one_work+0x218/0x510)
[    2.239772] [&lt;c03650a4&gt;] (process_one_work) from [&lt;c03660d8&gt;] (worker_thread+0x2a8/0x5c0)
[    2.247908] [&lt;c03660d8&gt;] (worker_thread) from [&lt;c036b348&gt;] (kthread+0x148/0x150)
[    2.255265] [&lt;c036b348&gt;] (kthread) from [&lt;c03010e8&gt;] (ret_from_fork+0x14/0x2c)
[    2.262444] Exception stack(0xea965fb0 to 0xea965ff8)
[    2.267466] 5fa0:                                     00000000 00000000 00000000 00000000
[    2.275598] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.283729] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    2.290333] ---[ end trace ca5d506728a0581a ]---

devlink_free is complaining right here:

	WARN_ON(!list_empty(&amp;devlink-&gt;port_list));

This happens because devlink_port_unregister is no longer done right
away in dsa_port_setup when a DSA_PORT_TYPE_USER has failed.
Vivien said about this change that:

    Also no need to call devlink_port_unregister from within dsa_port_setup
    as this step is inconditionally handled by dsa_port_teardown on error.

which is not really true. The devlink_port_unregister function _is_
being called unconditionally from within dsa_port_setup, but not for
this port that just failed, just for the previous ones which were set
up.

ports_teardown:
	for (i = 0; i &lt; port; i++)
		dsa_port_teardown(&amp;ds-&gt;ports[i]);

Initially I was tempted to fix this by extending the "for" loop to also
cover the port that failed during setup. But this could have potentially
unforeseen consequences unrelated to devlink_port or even other types of
ports than user ports, which I can't really test for. For example, if
for some reason devlink_port_register itself would fail, then
unconditionally unregistering it in dsa_port_teardown would not be a
smart idea. The list might go on.

So just make dsa_port_setup undo the setup it had done upon failure, and
let the for loop undo the work of setting up the previous ports, which
are guaranteed to be brought up to a consistent state.

Fixes: 955222ca5281 ("net: dsa: use a single switch statement for port setup")
Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Reviewed-by: Vivien Didelot &lt;vivien.didelot@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a function such as dsa_slave_create fails, currently the following
stack trace can be seen:

[    2.038342] sja1105 spi0.1: Probed switch chip: SJA1105T
[    2.054556] sja1105 spi0.1: Reset switch and programmed static config
[    2.063837] sja1105 spi0.1: Enabled switch tagging
[    2.068706] fsl-gianfar soc:ethernet@2d90000 eth2: error -19 setting up slave phy
[    2.076371] ------------[ cut here ]------------
[    2.080973] WARNING: CPU: 1 PID: 21 at net/core/devlink.c:6184 devlink_free+0x1b4/0x1c0
[    2.088954] Modules linked in:
[    2.092005] CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.3.0-rc6-01360-g41b52e38d2b6-dirty #1746
[    2.100912] Hardware name: Freescale LS1021A
[    2.105162] Workqueue: events deferred_probe_work_func
[    2.110287] [&lt;c03133a4&gt;] (unwind_backtrace) from [&lt;c030d8cc&gt;] (show_stack+0x10/0x14)
[    2.117992] [&lt;c030d8cc&gt;] (show_stack) from [&lt;c10b08d8&gt;] (dump_stack+0xb4/0xc8)
[    2.125180] [&lt;c10b08d8&gt;] (dump_stack) from [&lt;c0349d04&gt;] (__warn+0xe0/0xf8)
[    2.132018] [&lt;c0349d04&gt;] (__warn) from [&lt;c0349e34&gt;] (warn_slowpath_null+0x40/0x48)
[    2.139549] [&lt;c0349e34&gt;] (warn_slowpath_null) from [&lt;c0f19d74&gt;] (devlink_free+0x1b4/0x1c0)
[    2.147772] [&lt;c0f19d74&gt;] (devlink_free) from [&lt;c1064fc0&gt;] (dsa_switch_teardown+0x60/0x6c)
[    2.155907] [&lt;c1064fc0&gt;] (dsa_switch_teardown) from [&lt;c1065950&gt;] (dsa_register_switch+0x8e4/0xaa8)
[    2.164821] [&lt;c1065950&gt;] (dsa_register_switch) from [&lt;c0ba7fe4&gt;] (sja1105_probe+0x21c/0x2ec)
[    2.173216] [&lt;c0ba7fe4&gt;] (sja1105_probe) from [&lt;c0b35948&gt;] (spi_drv_probe+0x80/0xa4)
[    2.180920] [&lt;c0b35948&gt;] (spi_drv_probe) from [&lt;c0a4c1cc&gt;] (really_probe+0x108/0x400)
[    2.188711] [&lt;c0a4c1cc&gt;] (really_probe) from [&lt;c0a4c694&gt;] (driver_probe_device+0x78/0x1bc)
[    2.196933] [&lt;c0a4c694&gt;] (driver_probe_device) from [&lt;c0a4a3dc&gt;] (bus_for_each_drv+0x58/0xb8)
[    2.205414] [&lt;c0a4a3dc&gt;] (bus_for_each_drv) from [&lt;c0a4c024&gt;] (__device_attach+0xd0/0x168)
[    2.213637] [&lt;c0a4c024&gt;] (__device_attach) from [&lt;c0a4b1d0&gt;] (bus_probe_device+0x84/0x8c)
[    2.221772] [&lt;c0a4b1d0&gt;] (bus_probe_device) from [&lt;c0a4b72c&gt;] (deferred_probe_work_func+0x84/0xc4)
[    2.230686] [&lt;c0a4b72c&gt;] (deferred_probe_work_func) from [&lt;c03650a4&gt;] (process_one_work+0x218/0x510)
[    2.239772] [&lt;c03650a4&gt;] (process_one_work) from [&lt;c03660d8&gt;] (worker_thread+0x2a8/0x5c0)
[    2.247908] [&lt;c03660d8&gt;] (worker_thread) from [&lt;c036b348&gt;] (kthread+0x148/0x150)
[    2.255265] [&lt;c036b348&gt;] (kthread) from [&lt;c03010e8&gt;] (ret_from_fork+0x14/0x2c)
[    2.262444] Exception stack(0xea965fb0 to 0xea965ff8)
[    2.267466] 5fa0:                                     00000000 00000000 00000000 00000000
[    2.275598] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.283729] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    2.290333] ---[ end trace ca5d506728a0581a ]---

devlink_free is complaining right here:

	WARN_ON(!list_empty(&amp;devlink-&gt;port_list));

This happens because devlink_port_unregister is no longer done right
away in dsa_port_setup when a DSA_PORT_TYPE_USER has failed.
Vivien said about this change that:

    Also no need to call devlink_port_unregister from within dsa_port_setup
    as this step is inconditionally handled by dsa_port_teardown on error.

which is not really true. The devlink_port_unregister function _is_
being called unconditionally from within dsa_port_setup, but not for
this port that just failed, just for the previous ones which were set
up.

ports_teardown:
	for (i = 0; i &lt; port; i++)
		dsa_port_teardown(&amp;ds-&gt;ports[i]);

Initially I was tempted to fix this by extending the "for" loop to also
cover the port that failed during setup. But this could have potentially
unforeseen consequences unrelated to devlink_port or even other types of
ports than user ports, which I can't really test for. For example, if
for some reason devlink_port_register itself would fail, then
unconditionally unregistering it in dsa_port_teardown would not be a
smart idea. The list might go on.

So just make dsa_port_setup undo the setup it had done upon failure, and
let the for loop undo the work of setting up the previous ports, which
are guaranteed to be brought up to a consistent state.

Fixes: 955222ca5281 ("net: dsa: use a single switch statement for port setup")
Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Reviewed-by: Vivien Didelot &lt;vivien.didelot@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2019-09-02T18:20:17+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2019-09-02T18:20:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=765b7590c92d849806e9a27ab3a5a17cfc6a47a9'/>
<id>765b7590c92d849806e9a27ab3a5a17cfc6a47a9</id>
<content type='text'>
r8152 conflicts are the NAPI fixes in 'net' overlapping with
some tasklet stuff in net-next

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r8152 conflicts are the NAPI fixes in 'net' overlapping with
some tasklet stuff in net-next

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: dsa: tag_8021q: Restore bridge VLANs when enabling vlan_filtering</title>
<updated>2019-08-31T20:21:19+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>olteanv@gmail.com</email>
</author>
<published>2019-08-30T00:53:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5f33183b7fdfeba98d02b099c9de887378d47943'/>
<id>5f33183b7fdfeba98d02b099c9de887378d47943</id>
<content type='text'>
The bridge core assumes that enabling/disabling vlan_filtering will
translate into the simple toggling of a flag for switchdev drivers.

That is clearly not the case for sja1105, which alters the VLAN table
and the pvids in order to obtain port separation in standalone mode.

There are 2 parts to the issue.

First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
identification. But we need to disable tag_8021q when vlan_filtering
kicks in, and at that point, the VLAN configured as pvid will have to be
removed from the filtering table of the ports. With an invalid pvid, the
ports will drop all traffic.  Since the bridge will not call any vlan
operation through switchdev after enabling vlan_filtering, we need to
ensure we're in a functional state ourselves. Hence read the pvid that
the bridge is aware of, and program that into our ports.

Secondly, tag_8021q uses the 1024-3071 range privately in
vlan_filtering=0 mode. Had the user installed one of these VLANs during
a previous vlan_filtering=1 session, then upon the next tag_8021q
cleanup for vlan_filtering to kick in again, VLANs in that range will
get deleted unconditionally, hence breaking user expectation. So when
deleting the VLANs, check if the bridge had knowledge about them, and if
it did, re-apply the settings. Wrap this logic inside a
dsa_8021q_vid_apply helper function to reduce code duplication.

Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Reviewed-by: Vivien Didelot &lt;vivien.didelot@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The bridge core assumes that enabling/disabling vlan_filtering will
translate into the simple toggling of a flag for switchdev drivers.

That is clearly not the case for sja1105, which alters the VLAN table
and the pvids in order to obtain port separation in standalone mode.

There are 2 parts to the issue.

First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
identification. But we need to disable tag_8021q when vlan_filtering
kicks in, and at that point, the VLAN configured as pvid will have to be
removed from the filtering table of the ports. With an invalid pvid, the
ports will drop all traffic.  Since the bridge will not call any vlan
operation through switchdev after enabling vlan_filtering, we need to
ensure we're in a functional state ourselves. Hence read the pvid that
the bridge is aware of, and program that into our ports.

Secondly, tag_8021q uses the 1024-3071 range privately in
vlan_filtering=0 mode. Had the user installed one of these VLANs during
a previous vlan_filtering=1 session, then upon the next tag_8021q
cleanup for vlan_filtering to kick in again, VLANs in that range will
get deleted unconditionally, hence breaking user expectation. So when
deleting the VLANs, check if the bridge had knowledge about them, and if
it did, re-apply the settings. Wrap this logic inside a
dsa_8021q_vid_apply helper function to reduce code duplication.

Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Reviewed-by: Vivien Didelot &lt;vivien.didelot@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: dsa: Advertise the VLAN offload netdev ability only if switch supports it</title>
<updated>2019-08-28T03:46:26+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>olteanv@gmail.com</email>
</author>
<published>2019-08-25T19:46:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9b236d2a69da41da4aef3531cc3a034bf9dfc26d'/>
<id>9b236d2a69da41da4aef3531cc3a034bf9dfc26d</id>
<content type='text'>
When adding a VLAN sub-interface on a DSA slave port, the 8021q core
checks NETIF_F_HW_VLAN_CTAG_FILTER and, if the netdev is capable of
filtering, calls .ndo_vlan_rx_add_vid or .ndo_vlan_rx_kill_vid to
configure the VLAN offloading.

DSA sets this up counter-intuitively: it always advertises this netdev
feature, but the underlying driver may not actually support VLAN table
manipulation. In that case, the DSA core is forced to ignore the error,
because not being able to offload the VLAN is still fine - and should
result in the creation of a non-accelerated VLAN sub-interface.

Change this so that the netdev feature is only advertised for switch
drivers that support VLAN manipulation, instead of checking for
-EOPNOTSUPP at runtime.

Suggested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When adding a VLAN sub-interface on a DSA slave port, the 8021q core
checks NETIF_F_HW_VLAN_CTAG_FILTER and, if the netdev is capable of
filtering, calls .ndo_vlan_rx_add_vid or .ndo_vlan_rx_kill_vid to
configure the VLAN offloading.

DSA sets this up counter-intuitively: it always advertises this netdev
feature, but the underlying driver may not actually support VLAN table
manipulation. In that case, the DSA core is forced to ignore the error,
because not being able to offload the VLAN is still fine - and should
result in the creation of a non-accelerated VLAN sub-interface.

Change this so that the netdev feature is only advertised for switch
drivers that support VLAN manipulation, instead of checking for
-EOPNOTSUPP at runtime.

Suggested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
