Re: Issue with SJA1105QELY on STM32MP151CAA3T over RGMII Interface

[Vladimir Oltean <olteanv@gmail.com>]

Hi Oleksij,

On Wed, Jul 10, 2024 at 03:31:12PM +0200, Oleksij Rempel wrote:
> 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.

The symptoms sound awfully similar to a situation described in NXP
document AH1704, chapter 6.1.13.3. I can't disclose anything from its
contents here, since it is not a public document, requiring, AFAIK,
sign-in.

But there have been workarounds implemented in other drivers for this
particular issue, used as DSA masters for this switch. For example
commit 4fa6c976158b ("net: stmmac: dwmac-imx: pause the TXC clock in
fixed-link"). If you get access to the NXP document, maybe you can
confirm that the circumstances leading to the issue are the same, and
you are able to implement a similar workaround for this NIC (also stmmac
driver, I believe?!).

Hope this helps.