Use FIELD_GET and FIELD_PREP instead of open-coding register fields.
Replace 0x1f constant with (PHY_MAX_ADDR - 1).
Some field macros (ATC_HASH, VTCR_VID and STAG_VPID) were previously
defined as object-like macros referencing an undeclared 'x' and were
therefore unusable; convert them into proper FIELD_PREP() accessors.
The masks are equivalent to the open-coded values they replace, with
one exception: mt7530_vlan_cmd() now masks vid through VTCR_VID(vid)
instead of OR-ing it in raw, guarding the adjacent VTCR_FUNC field
against any bits set above the 12-bit VID width. VLAN IDs are always
in 0-4094, so this is a no-op in practice; it is a real hardening
rather than a strictly equivalent mechanical substitution.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/bd4eaf10fb6aa7a1bd056514b61b4481175708a5.1788190568.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert the two remaining switch reset polls to
regmap_read_poll_timeout() and remove struct mt7530_dummy_poll,
INIT_MT7530_DUMMY_POLL() and the mt7530_mii_poll() helper. As with the
command polls addressed by the preceding fixes, a failed read now
terminates the poll with an error instead of being fed to the loop
condition as a zero value.
Generated using the following semantic patch, plus removal of the two
now-unused definitions from mt7530.h:
// Poll the register through regmap so a failed read ends the poll.
@@
expression priv, reg;
identifier p, ret, val;
@@
- INIT_MT7530_DUMMY_POLL(&p, priv, reg);
- ret = readx_poll_timeout(mt7530_mii_poll, &p, val, val != 0,
- 20, 1000000);
+ ret = regmap_read_poll_timeout(priv->regmap, reg, val, val != 0,
+ 20, 1000000);
@@
identifier p;
@@
- struct mt7530_dummy_poll p;
... when != p
@@
identifier p;
type T;
@@
-static T mt7530_mii_poll(struct mt7530_dummy_poll *p) { ... }
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/609dcd8dd0c335e36bbc8df41413da58af1dbfb4.1788190568.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace all mt7530_read() calls with direct regmap_read() calls and
remove the wrapper function. The wrapper returned 0 on failed reads;
preserve that behaviour by zeroing the read-back buffer at the start of
mt7530_regmap_read(), so callers that do not check the return code keep
seeing a deterministic value. The WARN_ON_ONCE error logging is dropped.
Most callsites follow the val = mt7530_read(priv, reg) pattern and are
converted mechanically using the following semantic patch:
@@
expression priv, reg;
identifier val;
@@
-val = mt7530_read(priv, reg);
+regmap_read(priv->regmap, reg, &val);
Remaining inline uses are converted by hand.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/a1dc338ae368554ec6faa974df7ba6f3660ae12b.1788190568.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace all mt7530_rmw() calls with regmap_update_bits(), mt7530_set()
with regmap_set_bits(), and mt7530_clear() with regmap_clear_bits().
Remove the wrapper function definitions.
Generated using the following semantic patch:
@@
expression priv, reg, mask, set;
@@
-mt7530_rmw(priv, reg, mask, set)
+regmap_update_bits(priv->regmap, reg, mask, set)
@@
expression priv, reg, val;
@@
-mt7530_set(priv, reg, val)
+regmap_set_bits(priv->regmap, reg, val)
@@
expression priv, reg, val;
@@
-mt7530_clear(priv, reg, val)
+regmap_clear_bits(priv->regmap, reg, val)
Six regmap_update_bits() call sites with multi-line masks are rewrapped
by hand afterwards, as spatch joins their argument lines.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/182be19b483e77eb1d4ed835813359a27acd8e9c.1788190568.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace all mt7530_write() calls with direct regmap_write() calls
and remove the wrapper function. The per-call error logging is
dropped -- regmap has its own tracing infrastructure.
Generated using the following semantic patch:
@@
expression priv, reg, val;
@@
-mt7530_write(priv, reg, val)
+regmap_write(priv->regmap, reg, val)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/fbb6ee8860fa60326a8af132ed114555e7163350.1788190568.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
With the lock wrappers removed in the previous commit, mt7530_write()
was a trivial wrapper around mt7530_mii_write(), and mt7530_read()
around mt7530_mii_read() via _mt7530_read(). Fold the function bodies
and eliminate the intermediate functions.
The _mt7530_read() poll helper for readx_poll_timeout() is renamed to
mt7530_mii_poll() and calls mt7530_read().
Callers are updated using the following semantic patch:
@@
expression E1, E2, E3;
@@
-mt7530_mii_write(E1, E2, E3)
+mt7530_write(E1, E2, E3)
@@
expression E1, E2;
@@
-mt7530_mii_read(E1, E2)
+mt7530_read(E1, E2)
@@
expression list args;
@@
-readx_poll_timeout(_mt7530_read, args)
+readx_poll_timeout(mt7530_mii_poll, args)
The two readx_poll_timeout() call sites keep their original line
wrapping, which spatch reflows for the longer helper name.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/591c4e7ff5b1b6d39aac7f0f04eb67f36f40d8a2.1788190568.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The switch register regmap was created with .disable_locking = true,
relying on callers to manually lock the MDIO bus. Move the locking
into the regmap using .lock/.unlock callbacks, matching the PCS
regmaps that already do this. This allows any code path reaching the
regmap to be automatically protected.
With regmap handling bus locking, the manual mt7530_mutex_lock/unlock
calls in mt7530_write(), _mt7530_read(), mt7530_rmw() and
mt7530_port_change_mtu() become redundant and are removed, as is the
bus lock held across the ATC/VTCR command poll sequences.
The handle_mask_sync callback added by commit dd52b3df25 ("net: dsa:
mt7530: serialize the regmap IRQ chip like every other user") to hold
mt7530_mutex_lock() around the regmap-irq mask register write is
likewise removed. With the regmap now self-locking, regmap-irq's
default unmask_base sync is serialized on its own, and so are the
status read, ack write and init_ack_masked write that had no hook,
closing the gaps that commit left open. The per-device copy of the irq
chip it needed goes away too.
The MT7531 indirect PHY access functions need serialization of their
multi-step register sequences, but no longer need to hold bus->mdio_lock
across the whole operation. Switch them to reg_mutex.
core_write()/core_rmw() are the only remaining callers of
mt7530_mutex_lock(). They access TRGMII core PHY registers via the
clause 22 MMD indirect protocol -- a separate register space that
bypasses regmap and needs manual bus->mdio_lock protection.
The lock removals are generated using the following semantic patch:
// Collapse mt7530_write() now that regmap serialises bus access.
@@
expression priv, reg, val;
identifier ret;
@@
{
- int ret;
-
- mt7530_mutex_lock(priv);
-
- ret = mt7530_mii_write(priv, reg, val);
-
- mt7530_mutex_unlock(priv);
-
- return ret;
+ return mt7530_mii_write(priv, reg, val);
}
// Remove mt7530_mutex_lock/unlock around single regmap-based calls.
@@
expression priv, reg, mask, set;
@@
{
- mt7530_mutex_lock(priv);
-
regmap_update_bits(priv->regmap, reg, mask, set);
-
- mt7530_mutex_unlock(priv);
}
@@
expression p;
identifier val;
@@
{
- u32 val;
- mt7530_mutex_lock(p->priv);
- val = mt7530_mii_read(p->priv, p->reg);
- mt7530_mutex_unlock(p->priv);
- return val;
+ return mt7530_mii_read(p->priv, p->reg);
}
@@
expression priv;
identifier val;
@@
- mt7530_mutex_lock(priv);
val = mt7530_mii_read(priv, MT7530_GMACCR);
...
mt7530_mii_write(priv, MT7530_GMACCR, val);
- mt7530_mutex_unlock(priv);
// The ATC/VTCR command polls no longer need the bus lock held across
// the poll and the status read-back.
@@
expression priv, reg, cond;
identifier ret, val;
@@
- mt7530_mutex_lock(priv);
-
ret = regmap_read_poll_timeout(priv->regmap, reg, val, cond, 20, 20000);
if (!ret)
ret = regmap_read(priv->regmap, reg, &val);
-
- mt7530_mutex_unlock(priv);
// The MT7531 indirect PHY sequences keep serialising themselves, but
// against reg_mutex rather than the MDIO bus lock.
@@
expression priv;
identifier ret, val;
@@
- mt7530_mutex_lock(priv);
+ mutex_lock(&priv->reg_mutex);
ret = regmap_read_poll_timeout(priv->regmap, MT7531_PHY_IAC, val, ...);
@@
expression priv;
@@
out:
- mt7530_mutex_unlock(priv);
+ mutex_unlock(&priv->reg_mutex);
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/6927a774b87238800de5d6c0c717b0afd02d320b.1788190568.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Markus Stockhausen says:
====================
net: mdio: realtek-rtl9300: Add RTL83xx support
The Realtek Otto switch platform consists of four different series
- RTL838x aka maple : 28 port 1G Switches
- RTL839x aka cypress : 52 port 1G Switches
- RTL930x aka longan : 28 port 1G/2.5G/10G Switches
- RTL931x aka mango : 56 port 1G/2.5G/10G Switches
While the MDIO hardware polling unit and its necessity for the MAC
layer was always well known, no detailed documentation was available.
For this series the MDIO bus was inspected with a logic analyzer for
a better understanding how polling and kernel access interact on the
bus. All this will be explained now in the driver comments.
This patch series adds support for the RTL83xx devices. For this
- Enhance device tree binding.
- Add special handling for limitations enforced by hardware polling.
These already have minor side effects on RTL93xx devices but are even
more critical for the RTL83xx hardware.
- Add RTL83xx coding.
====================
Link: https://patch.msgid.link/20260831143439.2404484-1-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Realtek MDIO driver has been enhanced to support multiple
devices from the RTL83xx/RTL93xx series. Reword Kconfig and
module description accordingly.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-14-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MDIO driver has been prepared for multiple device support. Add all
required bits for the RTL839x (aka cypress) series. This is straightforward
but some things are worth mentioning.
- The device has a lot in common with the RTL931x series. It has 8192
(Realtek) pages and 7 MMIO registers.
- There are two SMI buses for 1G PHYs. Neither the bus nor address map
registers exist.
- The hardware has not much to configure. So the setup_controller()
function is not needed.
- The bit specific registers (polling & port_mask) are 2x32 bit wide. The
ports 0..31 got to <reg> and the ports 32..51 go to <reg+4>.
- C22 read/write functions must be called with PARK_PAGE = 0. Keep code
clean and avoid setting it to zero, matching the behavior of the RTL9310
logic.
- As per SDK the broadcast register allows to write to multiple ports
at the same time. Unlike RTL9310 where this is filled with a bit mask
for the current port RTL8390 does not use it for normal reads/writes.
It is simply set to 0 like the SDK does.
- The SDK fills the EXT_PAGE register with 0x1ff for C22 access and with
0x0 for C45 access. The reason for this is currently unknown and a
meaningful name can not be given. Align the driver coding with the
RTL9300_PHY_CTRL_PARK_PAGE settings and simply fill the hardcoded value.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-13-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MDIO driver has been prepared for multiple device support. Add all
required bits for the RTL838x (aka maple) series. This is straightforward
but some things are worth mentioning.
- The device has a lot in common with the RTL930x series. It has 28 ports,
4096 (Realtek) pages and 4 MMIO registers. With this a lot of the
existing RTL9300 defines could be reused. But to avoid confusion and
for better readability duplicate the defines with a proper prefix.
- The MDIO engine has no fail bit. Thus the mask is set to zero.
- There is only one SMI bus for 1G PHYs. No bus_map_base register exists.
- The setup_controller() function needs no C45 configuration as polling
only works in C22 mode
- The PHY access must be activated by a special register flag.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-12-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
RTL838x devices with 28 ports produce PHY access timeout errors during
one of three boots while waiting for MDIO command completion. This is
currently set to 1ms.
Background: Access to the Realtek Otto ethernet MDIO bus must wait for
a free slot between two hardware polls. The polling sequence consists
of at least 17 commands on the RTL838x devices. This delay can be nicely
seen when disabling polling completely. The following times are measured
on a bus running on the default 2.5MHz. Time measured is from the last
register write that sets the command-start-bit until the hardware
responds with the command-finished-bit set.
- average c22 read with polling enabled on all ports: ~380us
- average c22 read with polling enabled on one port: ~380us
- average c22 read with polling completely disabled: ~180us
For this bus frequency the bare hardware runtime for a single command
(32 bit preamble + 32 bit data) is ~25us. So the hardware adds quite
some overhead. On top of this comes the fact that the RTL838x devices
are low on resources (500Mhz 4Kec core with 16K cache).
Increase the timeout to 10ms to be on the safe side.
Remark! In a future patch the bus clock frequency will be made
configurable with a minimum frequency of 1.25MHz. Setting this
(e.g. for debugging purposes) doubles the command run times but
will safely stay below 10ms.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-10-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The hardware polling unit of the Realtek switches has a very special
handling for c22 PHY register 31 (aka Realtek page register) in place.
- On the RTL838x it is permanently reset to zero.
- On other devices there is some magic saving/restoring (aka parking)
in the background in place.
This makes access to PHYs a gamble.
It is vital to keep the polling alive so the MAC layer can rely on
consistent data. Intercept access to c22 register 31 and handle it
internally. Store the desired value for each port in the driver. When
issuing hardware access to other registers add the page to the command
towards the controller. Given this, the hardware will run two c22
commands that are not interrupted by polling.
... hardware poll ...
phy_write(phy, 31, page)
phy_write(phy, reg, value)
... hardware poll ...
Looking at this implementation one might argue that disabling/enabling
polling might be a cleaner solution. But one must remember that
- This driver differentiates clearly between C22 and C45 buses. During
probing it enables only one of the protocols for a bus.
- All known devices run RTL8218 (B/D/E) or RTL8214FC on 1G
- RTL839x gives link flapping when deactivating polling for a port
So a solution for a Realtek-only ecosystem is required. This commit
copies the downstream-proven driver-only page handling patch without
any new MDIO callbacks and is the lowest common denominator. If a
non-Realtek PHY is identified on a c22 bus the attachment aborts. It
should be noted that bus scan runs with the page handling already in
place before the check in notify_phy_attach(). This is accepted for
now.
Remark: To keep this simple, writes to register 31 are only accepted
if they are lower than the device specific raw page - 0..4094/8190.
Otherwise -EINVAL is returned. Under the above assumption (Only 1G
Realtek PHYs on a c22 bus) this is no limitation.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-9-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
During PHY probing and configuration complex configuration sequences
might be issued and firmware might be loaded. Hardware polling can
interfere badly with that. E.g. a hardware polling MMD c45 over c22
request might break an ongoing firmware loading sequence.
To avoid such issues the polling of the Realtek Otto switches can be
(de)activated with one or two 32 bit mask registers. Each bit enables
(=1) or disables (=0) the polling of the corresponding port. Make use
of this as follows:
- Disable polling for all ports when the MDIO driver starts.
- Reenable polling just after the PHY has been attached.
- Disable polling just before the PHY is being detached.
This synchronizes the kernel and hardware polling to some extent. It
gracefully handles deferred probing of PHYs in case the driver is
loaded asynchronously during boot. Additionally it brings the hardware
polling into a consistent operation mode for devices where U-Boot does
not take care.
Important notes about the implementation:
Realtek is very inconsistent about its register naming. RTL930x uses
SMI_POLL_CTRL for polling control while it is SMI_PORT_POLLING_CTRL
on RTL931x. Keep these vendor names.
These devices do not support power management for the whole system.
So mdio_bus_phy_resume() is not used and it is not required to
disable/enable hardware polling for that usecase.
These devices have no CPU MAC to PHY design. Thus abort phy_attach()
in case PHYs are not mapped to valid switch ports. All MDIO bus
commands will fail afterwards, leaving it in an unusable state.
Enabling/disabling hardware polling is a simple regmap bit access.
For this it is enough to rely on the regmap internal lock.
This polling enabling/disabling does not solve the current inability
of the driver to handle C45-over-C22 access during normal operation.
For all existing designs this is not needed.
[1] https://github.com/openwrt/openwrt/blob/main/target/linux/realtek/files-6.18/drivers/net/mdio/mdio-realtek-otto.c#L818
[2] https://lore.kernel.org/netdev/680696024a8648535ce6dee771fe4de67802e0e8.1769053496.git.daniel@makrotopia.org/
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-8-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Realtek MDIO driver relies on devm managed resources for lifetime
management and allocates its internal central controller structure
otto_emdio_priv via devm_kzalloc(). This can lead to a use-after-free
in the following sitauation:
- If the driver is removed or unbound via sysfs the controller devm
cleanup is triggered immediately. A corrupt devicetree might produce
a load failure and a cleanup too.
- However the MDIO buses are allocated with devm_mdiobus_alloc_size()
and are reference counted. So if a MAC driver still holds a reference
to a PHY device on the bus, the mii_bus will remain alive.
- Any action that is run for the buses afterwards still relies on the
availability of the central priv structure. This will access already
freed memory.
There are multiple mitigations to choose from
- Clone all controller->priv data into the bus->priv structure.
- disable sysfs bind/unbind attributes
- Check for "bus->state != MDIOBUS_REGISTERED" in all callbacks
This SoC-integrated MDIO controller cannot be physically hot-plugged
and manual unbinding gives no benefit. The driver is usually
integrated into the kernel and not loaded as a module. Avoid a
complex driver rewrite (data duplication) for now and set
suppress_bind_attrs to true to prevent unbinding via sysfs. This
mitigates issues for the known use cases.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-7-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some MDIO buses require programming PHY polling registers depending
on the PHY type. RealTek switch SoCs are the most prominent example
of a DSA switch which doesn't allow to program MAC speed, duplex and
flow-control settings without using PHY polling to do so [1].
Avoid a half-baked solution in the MDIO bus driver because
- it must reinvent the bus scanning to determine the PHYs and
- it must anticipate the right point in time (e.g. deferred PHYs).
Hence there is a need to inform the MDIO bus driver that a PHY is
being attached or detached. Provide two hooks in struct mii_bus
- notify_phy_attach(): called in phy_attach_direct() after PHY
hardware has been initialized and just before PHY is resumed.
- notify_phy_detach(): called in phy_detach() right after PHY
has been suspended.
Worth to notice: As of now phy_detach() is not 100% LIFO symmetric
to phy_attach_direct(). E.g. sysfs links are torn down before
suspend while being created before resume. Without reordering of the
detach function the above mentioned notifier placement is the best
possible symmetric implementation. An unconditional call of
notify_phy_detach() was favoured [3].
Remark! A slightly different version of this patch was part of a
former series [2]. The discussion already showed that an initialization
hook should be placed somewhere late during the whole setup. This
commit implants it right after phy_init_hw() as suggested. On top of
this it adds the detach hook.
[1] https://github.com/openwrt/openwrt/pull/21515#discussion_r2714069716
[2] https://lore.kernel.org/netdev/cover.1769053496.git.daniel@makrotopia.org/
[3] https://lore.kernel.org/netdev/9e40f50b-357a-4a93-9f59-94847850835d@lunn.ch/#t
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-6-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For the upcoming MDIO bus notification enhancements the PHY detach path
needs to inform the bus about these actions. Until now phy_detach() is
used for the regular detach path as well as from the phy_attach_direct()
error paths So in the future there must be a clear indication if a
notification is needed (normal path) or not (cleanup path).
Carve out the phy_detach() code into a new helper phy_detach_internal()
and make phy_detach() a short stub that calls the new helper.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-5-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hardware polling breaks C45 over C22 PHY access. Currently this
is accepted by the driver but it silently fails with undefined
results. Make the situation clear to the caller by adding checks,
returning an error and giving a one-time warning message.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-4-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a detailed explanation how the hardware polling unit in the
Realtek Otto switches works. This simplifies developing future
patches and reviewing them.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-3-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The lower end Realtek Otto switches provide 1G only and are divided into
two series:
- Maple : RTL838x up to 28 ports
- Cypress: RTL839x up to 52 ports
The Maple based devices have 3 different SoCs: RTL8380, RTL8381 and
RTL8382. The Cypress series consists of the RTL8391, RTL8392 and
RTL8393 SoCs. The MDIO controller of these switches works like the
existing RTL93xx logic but has different characteristics and different
registers. Add new compatibles in the device tree.
With the extended compatibility list change the title to better reflect
its scope. Especially add the "Ethernet" tag as these devices have
multiple MDIO controllers.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260831143439.2404484-2-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Mike Rapoport says:
====================
USB: replace page allocator calls with kmalloc()
This is a (small) part of larger work of replacing page allocator calls
with kmalloc.
My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.
Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.
Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.
For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.
And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.
The patches are deliberately kept small: each one deals with a single
driver or subsystem and with a single type of allocation, so that every
conversion can be reviewed, and if needed reverted, on its own.
====================
Link: https://patch.msgid.link/20260830-usb-v1-0-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
speedtch_upload_firmware() allocates a temporary buffer used to feed the
firmware to the device.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260830-usb-v1-3-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
cxacru_fw() allocates a temporary buffer used to feed the firmware to the
device and cxacru_bind() allocates the transfer buffers for the command
URBs.
These buffers can be allocated with kmalloc() as there's nothing special
about them to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260830-usb-v1-2-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 71338aa7d0 ("net: convert %p usage to %pK") which is from
2011 and changed the %p annotation for pointer to %pK. Back then the
default behaviour for %p was to print the pointer. The %pK modifier was
introduced to able to control the behaviour of specific pointer values
without changing the behaviour of %p for everyone. It was dedicated to
avoid leaking pointers via /proc.
There was also the idea to remove the check from formatting the string
and move to the open callback with some helpers but this did not happen.
Things changed over time. The default behaviour for %p is now to print a
hash pointer which does not leak the address but allows to correlate if
two pointers are equal.
The policy on %p is to not introduce new ones. This is somehow in
between since it already exists. The pointer are usually socket pointers
and I don't see any value in exposing them. Therefore I am following the
recommendation of removing them. Since their usage in /proc/ can be
considered ABI I replace the pointer with a 0.
Replace the %pK annotation with 0 value. Correct the spacing for the
cases where pointer is at the beginning.
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://patch.msgid.link/20260901160345.eeknHmY2@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A netdevsim VF port cannot process incoming data. It never runs
nsim_queue_init(), so ns->rq is NULL, and nsim_vf_netdev_ops has no
->ndo_open, so its NAPI is never set up either.
nsim_setup() offers NETIF_F_LOOPBACK to both PF and VF ports. Turning
it on for a VF makes nsim_start_xmit() take ns itself as peer_ns and
dereference peer_ns->rq[], which panics.
A VF cannot deliver packets at all: it can't be linked as a peer either,
since netdev_is_nsim() only matches the PF netdev_ops, so ns->peer is
always NULL and every skb ends up dropped. Give VF ports a dedicated
xmit that just drops the traffic, so VFs no longer depend on PF-only
state in nsim_start_xmit().
Reproduce in qemu:
modprobe netdevsim
echo "90 1" > /sys/bus/netdevsim/new_device
echo 2 > /sys/bus/netdevsim/devices/netdevsim90/sriov_numvfs
devlink dev eswitch set netdevsim/netdevsim90 mode switchdev
ethtool -K eth2 loopback on # eth2 is the vfnum 0 port
ip link set eth2 up
Panic:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 141 Comm: kworker/0:3 Not tainted 7.2.0+ #338 PREEMPT
Workqueue: mld mld_ifc_work
RIP: 0010:nsim_start_xmit (drivers/net/netdevsim/netdev.c:159)
dev_hard_start_xmit ( net/core/dev.c:3953)
sch_direct_xmit (net/sched/sch_generic.c:372)
__dev_queue_xmit (net/core/dev.c:4262 net/core/dev.c:4884)
neigh_resolve_output (net/core/neighbour.c:1616)
ip6_finish_output2 (net/ipv6/ip6_output.c:138)
ip6_finish_output (net/ipv6/ip6_output.c:221)
ip6_output (net/ipv6/ip6_output.c:248)
......
Cc: stable+noautosel@kernel.org # netdevsim is a test harness, it's never loaded on production systems
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260901061851.61734-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
selftests: drv-net: split up gro.py
gro.py runs its full set of cases three times over - against SW GRO,
HW GRO and LRO. It's our test with the longest runtime. The 318 cases
take 12m30s on mlx5 with a debug kernel.
We will likely add more subcases here as the time goes on, so it's
time to start splitting it up. Long runtime wastes time on retries
(if any of the 300+ cases fails we try to check if it's a real failure
or flake an re-run the whole thing). It also forces us to increase
timeout for the whole test suite.
v1: https://lore.kernel.org/20260831163734.1121891-1-kuba@kernel.org
====================
Link: https://patch.msgid.link/20260901200728.2063720-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The XDP test takes 9m30s on the slowest NIC with debug kernel.
Let's give ourselves a 50% margin and set the timeout to 15min.
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gro.py runs its full set of cases three times over - against SW GRO,
HW GRO and LRO. It's our test with the longest runtime. The 318 cases
take 12m30s on mlx5 with a debug kernel.
Bumping the timeout for all tests feels wrong when we can so easily
split the GRO test by execution mode. Shorter runtime also helps retry
just the failing portion / mode (we retry failing tests to try to
detect flakes vs real failures).
Move the main logic to gro_lib.py and add one program per mode -
gro_sw.py, gro_hw.py and gro_lro.py, 102 cases each. Move PPPoE to
a dedicated test. It has been tacked onto the tests in an ugly way,
and it only runs against SW GRO anyway.
Note that unfortunately this will case a rename of all test cases.
The mode moves from the case name to the test name
gro.py test.sw_ipv4_data_same
becomes
gro_sw.py test.ipv4_data_same
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We need to free up the gro_hw.py name for the HW-GRO half of gro.py,
which we need to split by mode (sw / hw / lro). The file checks mostly
qstat counters, so name it after stats.
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The binding references ethernet-controller.yaml schema, which already
defines a dependency of pcs-handle-names on pcs-handle, thus duplicating
it here is redundant.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901061255.25734-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Oleksij Rempel says:
====================
net: dsa: realtek: enable RTL8365MB power supplies
The RTL8365MB family has several external power rails (analog, digital I/O
and PLL supplies) that on some boards are gated by regulators. Until now the
driver assumed they were always on, so it could not be used on designs that
keep these rails software-controlled.
This series adds a device-tree description for those supplies and enables
them in the driver before the chip is accessed:
The supplies are optional: boards that hard-wire the rails work unchanged
====================
Link: https://patch.msgid.link/20260831123637.666457-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace the open-coded dev_err() + ERR_CAST() on the reset GPIO error
path with dev_err_cast_probe(), matching the reset controller above and
staying quiet on -EPROBE_DEFER.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260831123637.666457-4-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The power supplies powering the IC may not necessarily be enabled by the
time the driver probes. The binding describes the power rails, so enable
them at probe with devm_regulator_bulk_get_enable(), before the reset line
is requested and driven, so the chip is powered before its pins are driven.
Boards that do not describe these supplies fall back to dummy regulators
(with a "supply not found" warning) and keep working as before.
A board that describes supplies but no reset line still needs to wait for
the chip to boot before the first register access, so apply the existing
start delay in that case too.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260831123637.666457-3-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Document the RTL8365MB power rails as optional supplies. They are optional
because the rails are often always-on; some designs break them out for
granular hwmon monitoring and regulator control.
They are scoped to realtek,rtl8365mb: different Realtek switch families use
different power-rail naming schemes, so these rails do not apply to other
families such as realtek,rtl8366rb (VDDA/VDD_CORE/VDDIO/...).
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260831123637.666457-2-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hangbin Liu says:
====================
bonding: fix TLB load-tracking overflow on high-speed NICs
The bonding TLB (Transmit Load Balancing) mode tracks per-slave and
per-client transmit byte counts in u32 fields. At sustained throughput
above ~3.2 Gbit/s over the 10-second rebalance interval these counters
wrap, causing compute_gap() to produce incorrect gap values and
mis-select transmit slaves. Such speeds are routine on modern NICs
under heavy traffic.
This two-patch series fixes the overflow by widening the relevant
fields to u64.
Patch 1 converts the unbalanced_load counter to per-cpu state as a
preparatory step. The counter sits in the transmit hot path, so
converting it to per-cpu before widening avoids introducing cross-CPU
synchronization overhead for a u64. Also use a prev_total_unbalanced
to store the previous total load to avoid reset per-cpu data.
Patch 2 widens tx_bytes, load_history, load, and the per-cpu
unbalanced_load tx_bytes from u32 to u64. It adds u64_stats_sync
protection for the per-cpu counter to prevent tearing on 32-bit
architectures, and reworks compute_gap() to use s64 arithmetic with
READ_ONCE() on slave->speed.
====================
Link: https://patch.msgid.link/20260831-bond_overflow-v6-0-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The TLB load-tracking fields tx_bytes, load_history, load, and
unbalanced_load are all u32. At sustained throughput above ~3.2 Gbit/s
over the 10-second rebalance interval the byte counters wrap, causing
compute_gap() to produce incorrect gap values and mis-select slaves.
Such speeds are common on modern NICs under heavy traffic.
Widen these fields to u64. Use u64_stats_sync to protect the per-cpu
unbalanced_load_stats against tearing on 32-bit architectures, and
div_u64() for the 64-bit divisions. The tx_bytes and load_history
are protected in spin_lock. Also protect the slave load writing in
bond_alb_monitor() with spin_lock in case of tear on 32-bit.
For compute_gap(), we still use s64 arithmetic throughout, so we can
preserve the existing calculation logic. This order of magnitude is
sufficiently large, there is no need to worry about overflow for now.
Detected by AI code review.
Cc: stable+noautosel@kernel.org # never worked
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Link: https://patch.msgid.link/20260831-bond_overflow-v6-2-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A later patch widens the bonding TLB tx counters from u32 to u64. The
unbalanced_load counter sits in the transmit hot path, and cross-CPU
synchronization of a u64 would introduce measurable overhead. Convert
unbalanced_load to a per-cpu counter first so that the subsequent
widening only touches per-cpu data local to each CPU.
Introduce struct unbalanced_load_stats to hold the per-cpu counter,
and move the aggregation into a helper, reset_unbalanced_load(), which
sums all per-cpu instances. Use the delta of current total load vs
variable prev_total_unbalanced to calculate the loading.
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Link: https://patch.msgid.link/20260831-bond_overflow-v6-1-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This basically reverts the Feb 2021 change:
commit 96854bbda2 ("hv_netvsc: Restrict configurations on isolated guests")
In Feb 2021, PCI device assignment for CoCo VMs on Hyper-V was not
supported: if the host offered a PCI VF NIC device to the VM, the VM
couldn't handle it properly, so the 2021 commit was made to tell the host
"I'm unable to handle SR-IOV NICs, so please don't offer a VF to me".
If the host offers a VF NIC to the VM anyway, the change to
netvsc_receive_inband() ignores the VF NIC.
Since Mar 2023, the VM is able to support PCI device assignment due to
commit 2c6ba42168 ("PCI: hv: Enable PCI pass-thru devices in Confidential VMs")
and related commits, so hv_netvsc can functionally work with a VF NIC, but
we haven't advertised the SR-IOV capability because the MANA NIC driver
(drivers/net/ethernet/microsoft/mana/) hadn't been hardened, so a
malicious MANA NIC might be able to attack the VM.
Recently, we have finished hardening the MANA driver, so we can safely
use the MANA NIC in a CoCo VM now. Note: currently the MANA driver in a
CoCo VM still uses bounce buffering (i.e. shared decrypted memory)
for DMA. In the future, it will be able to use private encrypted
memory for DMA with the help of TDISP.
Now, advertises the SR-IOV capability for CoCo VMs.
Note: for MANA to work properly for CoCo VMs, the following earlier
commits are also required:
commit 2e2a83b499 ("net: mana: Validate the packet length reported by the NIC")
commit c72a0f09c5 ("net: mana: Sync page pool RX frags for CPU")
Note: the host might offer a VF NIC device that's not MANA -- in that
case, if the corresponding VF NIC driver isn't hardened for CoCo VMs,
the driver should be blacklisted in CoCo VMs.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mailbox path warns when a message claims more bytes than the descriptor
but still parses it. The attribute walkers also validate a child TLV before
proving that its declared span fits in the parent remainder.
Reject invalid mailbox message extents and bound each child attribute
before type-specific validation.
Cc: stable+noautosel@kernel.org # assumes malicious PCIe device
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260830142516.38145-1-pengpeng@iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Sitnicki says:
====================
net: Prepare skb extensions for reuse across scrubs
Following Florian's suggestion from the discussion in [1].
The skb extension allocator retains the extension's offset after the
extension is deleted. This, in theory, allows skb_ext_add() to reuse the
existing storage instead of appending another copy when an extension is
added again. However, it also means that we can't rely on the offset as an
indicator that the extension is present.
Make the extension cleanup safe, even when the offset is already allocated
and set, by making the individual extension put helpers idempotent, so that
they can be called multiple times.
This is preparatory work to support skb extension chunk area reuse after
skb scrubbing, which would be needed to persist BPF metadata skb extension
across scrubs [2].
[1] https://lore.kernel.org/ao9UV9S7rUkyQ8jv@strlen.de
[2] https://lore.kernel.org/64365932-c765-472e-bf6c-b07c9ee25eaf@kernel.org
====================
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-0-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MCTP flow extension can be released either when it is deleted from an
skb or when the last skb holding the extension block is freed. Handle the
release in __skb_ext_del(), which is currently missing, and make
skb_ext_put_mctp() safe to call from both paths.
This will let __skb_ext_put() release the MCTP key without checking whether
the extension is present first, which is needed if we want to reuse skb_ext
chunks area after skb scrubbing.
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Acked-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-2-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The sec_path extension can be released either when it is deleted from an
skb or when the last skb holding the extension block is freed. Make
skb_ext_put_sp() safe to call from both paths by returning when
sec_path->len is zero and clearing it after dropping the XFRM state
references.
This will let __skb_ext_put() release the sec_path without checking whether
the extension is present first, which is needed if we want to reuse skb_ext
chunks area after skb scrubbing.
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-1-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add missing enum member force-forwarding to ipv6-devconf.
In commit f24987ef69 ("ipv6: add `force_forwarding` sysctl to
enable per-interface forwarding"), the DEVCONF_* enum was extended
with DEVCONF_FORCE_FORWARDING, however Gabriel forgot to add it
to the spec.
This pre-existing issue was detected by Sashiko, when reviewing the
first patch in this series.
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824103816.40040-1-ast%40fiberby.net
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://patch.msgid.link/20260831093458.472180-4-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add missing enum member accept-ra-min-lft to ipv6-devconf.
In commit 1671bcfd76 ("net: add sysctl accept_ra_min_rtr_lft")
the DEVCONF_* enum was extended with DEVCONF_ACCEPT_RA_MIN_RTR_LFT.
It was renamed to DEVCONF_ACCEPT_RA_MIN_LFT in commit 5027d54a9c
("net: change accept_ra_min_rtr_lft to affect all RA lifetimes").
Shortly thereafter, this spec was introduced in commit b2f63d904e
("doc/netlink: Add spec for rt link messages").
This pre-existing issue was detected by Sashiko, when reviewing the
first patch in this series.
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824103816.40040-1-ast%40fiberby.net
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260831093458.472180-3-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
devconf is even odder than described in commit 720447bd0b
("netlink: specs: rt-link: remove implicit structs from devconf"),
where both IPv4 and IPv6 are described in an identical way:
"u32 indexed by ipv?-devconf - 1 on output, on input it's a nest".
There are two issues with that line for IPv6:
1) The subtraction is an IPv4 specific quirk, to avoid having an unused
u32 at index 0, thus saving 4 bytes per net device being dumped:
- In include/uapi/linux/ip.h the IPV4_DEVCONF_* enum begins with
IPV4_DEVCONF_FORWARDING = 1, so the enum starts at 1, which is
the reason for the subtraction in the IPv4 variant.
- In include/uapi/linux/ipv6.h the DEVCONF_* enum begins with
DEVCONF_FORWARDING = 0, so subtraction would underflow.
- ipv6_store_devconf() in net/ipv6/addrconf.c also doesn't do the
subtraction in the output path.
2) Setting IPv6 devconf through Netlink is not yet supported, as
IFLA_INET6_CONF is not handled in inet6_set_link_af().
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Link: https://patch.msgid.link/20260831093458.472180-2-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
dwmac can do ARP offloading, where the HW replies to incoming ARP
requests. This requires multiple steps to work well :
- Program the local IP address in a dedicated register
- Enable ARP offloading
This is halfway implemented in stmmac, as it's only ever used by
selftests, and these selftests are failing on at least 2 platforms :
stm32mp1, and jh7110.
There have been some attempts in the past to support this feature, but
this never made it upstream. Let's just remove the test and that code,
until someone actually wants that to work. We should likely have a
proper API for that so that drivers can use it.
Let's also not mention ARP offload in the stmmac documentation.
Leave the defines in place and the capability detection, this doesn't
hurt and gives some information about how the IP is synthesized.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260831071351.354255-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In __stmmac_open() and stmmac_xdp_open(), the DMA engine is started
before stmmac_request_irq() is called. If the IRQ request fails, the
clean-up paths free the DMA descriptor rings via dma_free_coherent()
without stopping the DMA engine first.
With the DMA engine still running, hardware may continue to access the
descriptor ring memory after it has been freed. Add stmmac_stop_all_dma()
to both error paths, matching the teardown order in __stmmac_release().
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Link: https://patch.msgid.link/32EB352EB66D74E7+20260827025415.2684733-1-zhaojinming@uniontech.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
