From: Théo Lebrun theo.lebrun@bootlin.com
[ Upstream commit 70a5ce8bc94545ba0fb47b2498bfb12de2132f4d ]
bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32 pointer and dereferencing implies dealing manually with endianness, which is error-prone.
Replace by calls to get_unaligned_le32|le16() helpers.
This was found using sparse: ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o warning: incorrect type in assignment (different base types) expected unsigned int [usertype] bottom got restricted __le32 [usertype] warning: incorrect type in assignment (different base types) expected unsigned short [usertype] top got restricted __le16 [usertype] ...
Reviewed-by: Sean Anderson sean.anderson@linux.dev Signed-off-by: Théo Lebrun theo.lebrun@bootlin.com Reviewed-by: Simon Horman horms@kernel.org Link: https://patch.msgid.link/20250923-macb-fixes-v6-5-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES – this should go to stable.
- `drivers/net/ethernet/cadence/macb_main.c:276-283` now programs the MAC address with `get_unaligned_le32()` / `get_unaligned_le16()` instead of casting `bp->dev->dev_addr` to wider pointers and dereferencing. Because `struct net_device::dev_addr` is only byte- aligned, the old `*((u32 *)...)` / `*((u16 *)...)` pattern could fault on architectures without efficient unaligned loads; this code runs every time the interface comes up (`macb_init_hw`, `macb_set_mac_addr`, `at91ether_open`), so the bug hits real users on strict-alignment platforms. - The helpers retain the little-endian layout expectations of the hardware (the value is converted through `macb_or_gem_writel()` just as before), so behaviour remains unchanged on little-end systems while eliminating undefined behaviour on stricter CPUs. No other logic is touched, and the change is confined to two register writes.
Small, well-scoped bug fix with clear user impact and negligible regression risk – good stable material. Next steps if you want extra assurance: (1) boot a platform with `CONFIG_DEBUG_ALIGN_RODATA` / strict alignment and bring the interface up; (2) sanity-check MAC programming via `ip link show`.
drivers/net/ethernet/cadence/macb_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index fc082a7a5a313..4af2ec705ba52 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -274,9 +274,9 @@ static void macb_set_hwaddr(struct macb *bp) u32 bottom; u16 top;
- bottom = cpu_to_le32(*((u32 *)bp->dev->dev_addr)); + bottom = get_unaligned_le32(bp->dev->dev_addr); macb_or_gem_writel(bp, SA1B, bottom); - top = cpu_to_le16(*((u16 *)(bp->dev->dev_addr + 4))); + top = get_unaligned_le16(bp->dev->dev_addr + 4); macb_or_gem_writel(bp, SA1T, top);
if (gem_has_ptp(bp)) {