Since the MAC lookup started returning -EPROBE_DEFER, a probe that
defers while its nvmem provider (e.g. a mac-base cell in the CFE
partition) isn't ready yet leaves the power domain devices attached
by genpd_dev_pm_attach_by_id() behind. The next probe then fails to
re-create them:
sysfs: cannot create duplicate filename '/devices/genpd:0:1000d800.ethernet'
bcm6368-enetsw 1000d800.ethernet: error getting pm 0
bcm6368-enetsw 1000d800.ethernet: probe with driver bcm6368-enetsw failed with error -22
leaving the board without ethernet and the DSA switch deferred forever.
Look up the MAC first, before anything that isn't device-managed has
been set up, so a deferred probe can simply be retried.
Seen on a BCM6328 (BeWAN A2100N) with kernel 6.18.
Fixes: ed545519ee ("bmips: enet: handle EPROBE_DEFER for the MAC address")
Signed-off-by: Max Plekh <mplekh@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25454
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Both bmips ethernet drivers call of_get_mac_address() and throw the
return value away. They then decide from the contents of an
uninitialised stack buffer whether a MAC address was found, and fall
back to eth_hw_addr_random() when it does not look valid. An
-EPROBE_DEFER is therefore turned into a random MAC address instead of
into a retry.
This did not matter while fixed-layout NVMEM cells were parsed
synchronously by the NVMEM core. Linux 6.12.104 picks up 751cc1534316
("nvmem: layouts: Add fixed-layout driver"), which drops the
"fixed-layout" entry from of_nvmem_layout_skip_table and turns it into
an ordinary NVMEM layout bus driver: nvmem_register() now only creates
the layout device and sets nvmem->layout, and the cells show up later,
when fixed_layout_probe() runs. Until then
nvmem_layout_module_get_optional() sees no bound driver and
of_nvmem_cell_get() returns -EPROBE_DEFER.
That window is hit on every boot rather than occasionally, because it
is link order and not a race. nvmem_init() is a subsys_initcall, but
the layout driver is a device_initcall and drivers/Makefile places
nvmem/ after both mtd/ and net/. The flash therefore registers its
NVMEM device first, the ethernet driver probes next and defers, and
only afterwards does the fixed-layout driver bind and add the cells.
28 bmips boards take their MAC address from a "fixed-layout" node and
bmips has no base-files fallback, so all of them would come up with a
random MAC address that changes on every boot. Propagate -EPROBE_DEFER
so that the probe is retried once the cell exists, the same way this
was already fixed for lantiq in 50e7e5c80d ("lantiq: xrx200: handle
EPROBE_DEFER for MAC address").
Fixes: 91a52f22a1 ("treewide: backport support for nvmem on non platform devices")
Fixes: 1c552eb44d ("bmips: add basic BCM6358 ethernet support")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/24808
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It's used in probe to be a generic way to iterate over the children.
Confusingly, device_for_each_child_node_scoped internally calls the
available loop despite not mentioning it.
Avoid pointless variables.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24120
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Include <linux/of.h> instead of <linux/of_device.h>.
This problem arised when adding support for 6.12, but it can be fixed on
older kernels too.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
This problem arised when adding support for 6.12, but it should be fixed on
older kernels too.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
These drivers should include <linux/platform_device.h>, but this wasn't an
issue on kernels < 6.12.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Switch to netif_napi_add_weight and add back weight value from <= v5.15.
Fixes: 8f6033e287 ("bmips: enet: add compatibility with kernel 6.1")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The safe max frame size for this ethernet switch is 1532 bytes,
excluding the DSA TAG and extra VLAN header, so the maximum
outgoing frame is 1542 bytes.
The available overhead is needed when using the DSA switch with
a cascaded Marvell DSA switch, which is something that exist in
real products, in this case the Inteno XG6846.
Use defines at the top of the size for max MTU so it is clear how
we think about this, add comments.
We need to adjust the RX buffer size to fit the new max frame size,
which is 1542 when the DSA tag (6 bytes) and VLAN header (4 extra
bytes) is added.
We also drop this default MTU:
#define ENETSW_TAG_SIZE (6 + VLAN_HLEN)
ndev->mtu = ETH_DATA_LEN + ENETSW_TAG_SIZE;
in favor of just:
ndev->mtu = ETH_DATA_LEN;
I don't know why the default MTU is trying to second guess the
overhead required by DSA and VLAN but the framework will also
try to bump the MTU for e.g. DSA tags, and the VLAN overhead is
not supposed to be included in the MTU, so this is clearly not
right.
Before this patch (on the lan1 DSA port in this case):
dsa_slave_change_mtu: master->max_mtu = 9724, dev->max_mtu = 10218, DSA overhead = 8
dsa_slave_change_mtu: master = extsw, dev = lan1
dsa_slave_change_mtu: master->max_mtu = 1510, dev->max_mtu = 9724, DSA overhead = 6
dsa_slave_change_mtu: master = eth0, dev = extsw
dsa_slave_change_mtu new_master_mtu 1514 > mtu_limit 1510
mdio_mux-0.1:00: nonfatal error -34 setting MTU to 1500 on port 0
My added debug prints before the nonfatal error: the first switch from the top
is the Marvell switch, the second in the bcm6368-enetsw with its 1510 limit.
After this patch the error is gone.
OpenWrt adds a VLAN to each port so we get VLAN tags on all frames. On this
setup we even have 4 more bytes left after the two DSA tags and VLAN so
we can go all the way up to 1532 as MTU.
Testing the new 1532 MTU:
eth0 ext1 enp7s0
.--------. .-----------. cable .------.
| enetsw | <-> | mv88e6152 | <-----> | host |
`--------´ `-----------´ `------´
On the router we set the max MTU for test:
ifconfig eth0 mtu 1520
ifconfig br-wan mtu 1520
ifconfig ext1 mtu 1506
An MTU of 1506 on ext1 is a logic consequence of the above setup:
this is the max bytes actually transferred. The framing added will be:
- 18 bytes standard ethernet header
- 4 bytes VLAN header
- 6 bytes DSA tag for enetsw
- 8 bytes DSA tag for mv88e6152
Sum: 1506 + 18 + 4 + 6 + 8 = 1542 which is out max frame size.
Test pinging from host:
ping -s 1478 -M do 192.168.1.220
PING 192.168.1.220 (192.168.1.220) 1478(1506) bytes of data.
1486 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.696 ms
1486 bytes from 192.168.1.220: icmp_seq=2 ttl=64 time=0.615 ms
Test pinging from router:
PING 192.168.1.2 (192.168.1.2): 1478 data bytes
1486 bytes from 192.168.1.2: seq=0 ttl=64 time=0.931 ms
1486 bytes from 192.168.1.2: seq=1 ttl=64 time=0.810 ms
The max IP packet without headers is 1478, the outgoing ICMP packet is
1506 bytes. Then the DSA, VLAN and ethernet overhead is added.
Let us verify the contents of the resulting ethernet frame of 1542 bytes.
Ping packet on router side as viewed with tcpdump:
00:54:51.900869 AF Unknown (1429722180), length 1538:
0x0000: 3d93 bcae c56b a83d 8874 0300 0004 8100 =....k.=.t......
0x0010: 0000 dada 0000 c020 0fff 0800 4500 05e2 ............E...
0x0020: 0000 4000 4001 b0ec c0a8 0102 c0a8 01dc ..@.@...........
0x0030: 0800 7628 00c3 0001 f5da 1d65 0000 0000 ..v(.......e....
0x0040: ce65 0a00 0000 0000 1011 1213 1415 1617 .e..............
0x0050: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 .........!"#$%&'
0x0060: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ()*+,-./0123456
(...)
- 3d93 = First four bytes are the last two bytes of the destination
ethernet address I don't know why the first four are missing,
but it sure explains why the paket is 1538 bytes and not 1542
which is the actual max frame size.
- bcae c56b a83b = source ethernet address
- 8874 0300 0004 = Broadcom enetsw DSA tag
- 8100 0000 = VLAN 802.1Q header
- dada 0000 c020 0fff = EDSA tag for the Marvell (outer) switch,
- 0800 is the ethertype (part of the EDSA tag technically)
- Next follows the contents of the ping packet as it appears if
we dump it on the DSA interface such as tcpdump -i lan1
etc, there we get the stripped out packet, 1506 bytes.
- At the end 4 bytes of FCS.
This clearly illustrates that the DSA tag is included in the MTU
which we set up in Linux, but the VLAN tag and ethernet headers and
checksum is not.
Tested-by: Paul Donald <newtwen@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
late_initcall_sync() is no longer needed so standard module functions can be
used on all bmips PCI/PCIe drivers.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Sercomm SHG2500 is a BCM63168 with 128M of RAM, 256M of NAND, an external
BCM53124S switch for the LAN ports and internal/external Broadcom wifi.
LEDs are connected to an external MSP430G2513 MCU controlled via SPI.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Register the ethernet driver from iudma, which avoids the attempt to probe the
emac driver before iudma and its consequent deferral.
The ethernet driver can't work without iudma anyway.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
We should ensure that the PHY is properly configured.
This is specially needed in devices using the internal PHY for ethernet0.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The MDIO bus is supported but there are errors when trying to probe and
configure the external BCM5325E switch through B53 DSA.
Therefore, let's add basic ethernet (but working) support for now.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The current implementation of bcm6368-enetsw is a mess of dev, ndev and kdev
variables, which have refer to different things depending on the function.
This commit harmonizes it and resolves the issue.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Without this change, internal and external B53 switches couldn't coexist as
reported in https://github.com/openwrt/openwrt/issues/10313.
In order to fix this we need to force the B53 MMAP DSA switch driver to use
bcm6368-mdio-mux for accessing the PHY registers instead of its own phy_read()
and phy_write() functions.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Use existing rx processed count to track against budget, thereby making
budget decrement operation redundant.
rx_desc_count can be calculated outside the rx loop, making the loop a
bit smaller.
Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com>
napi_build_skb() reuses NAPI skbuff_head cache in order to save some
cycles on freeing/allocating skbuff_heads on every new rx or completed
tx.
Use napi_consume_skb() to feed the cache with skbuff_heads of completed
tx so it's never empty.
Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com>
Check if we're in NAPI context when refilling rx. Normally we're almost
always running in NAPI context. Dispatch to napi_alloc_frag() directly
instead of relying on netdev_alloc_frag() which does the same but with
the overhead of local_bh_disable/enable.
Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com>
[improve code format]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
We can increase the efficiency of rx path by using buffers to receive
packets then build SKBs around them just before passing into the network
stack. In contrast, preallocating SKBs too early reduces CPU cache
efficiency.
Performance is slightly increased but the changes allow more
potential optimizations.
Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com>
[improve code format]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
bmips is using Broadcom B53 DSA driver which means the ethernet driver
must compensate for 6 bytes tags from the internal switch.
This means using NET_IP_ALIGN actually misaligns the skb, lowering
performance significantly. Therefore napi_alloc_skb() which uses
NET_IP_ALIGN is changed to netdev_alloc_skb().
Performance in iperf3 is increased from ~47Mbps to 52Mbps.
Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com>
A devent amount of patches have been upstreamed, so maintaining linux 5.10 on
this target makes no sense.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
In the current state, nvmem cells are only detected on platform device.
To quickly fix the problem, we register the affected problematic driver
with the of_platform but that is more an hack than a real solution.
Backport from net-next the required patch so that nvmem can work also
with non-platform devices and rework our current patch.
Drop the mediatek and dsa workaround and rework the ath10k patches.
Rework every driver that use the of_get_mac_address api.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Max Plekh
Andrew LaMarche
Hauke Mehrtens
Rosen Penev
Mieczyslaw Nalewaj
Álvaro Fernández Rojas
Linus Walleij
Sieng-Piaw Liew
Ansuel Smith