netdev - Issue with SJA1105QELY on STM32MP151CAA3T over RGMII Interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zo6NIINGn53fIa5M@pengutronix.de>
Date: Wed, 10 Jul 2024 15:31:12 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, kernel@...gutronix.de,
	David Jander <david@...tonic.nl>
Subject: Issue with SJA1105QELY on STM32MP151CAA3T over RGMII Interface

Hi Vladimir,

I hope this email finds you well.

I'm reaching out because I'm having an issue with the SJA1105QELY switch
connected to an STM32MP151CAA3T over an RGMII interface. About 1 in
every 10 starts, the SJA1105 fails to receive frames from the CPU.
Specifically, the p04_n_rxfrm counters stay at 0, and all RX error
counters are zero too, indicating that the port doesn't seem to see any
frames at all.

I can reproduce this issue even without rebooting, just by using the
unbind/bind sequence:

```sh
echo spi0.0 > /sys/bus/spi/drivers/sja1105/unbind
echo spi0.0 > /sys/bus/spi/drivers/sja1105/bind
ip l s dev t10 up
sleep 1
ethtool -t t10
```

Running the ethtool self-test is the most reliable way to reproduce the
problem early without additional software.

I've checked the RX_CTL and RX_CLK lines of the SJA1105 port 4 with an
oscilloscope, and both look correct and identical in both working and
non-working cases.

Interestingly, the external RGMII switch ports are working fine. I can
bridge them and push frames in all directions without issues.
Transferring frames from the switch to the CPU works fine as well, which
makes me suspect that the problem is isolated to the reception of frames
on the CPU RGMII interface.

Is it possible there's some RGMII-specific race condition during the
initialization stage? The bootloader implementation of the SJA1105 on same HW
seems to work fine too, so this seems to be a Linux kernel-specific issue.

Any insights or suggestions you might have would be greatly appreciated!

Thanks a lot for your help.

Best regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |