daniel-p-carvalho opened a new pull request, #20237: URL: https://github.com/apache/nuttx/pull/20237
## Summary When the PHY has not finished its reset yet, the Ethernet drivers of the STM32H7 and of the STM32H5 went on with the default configuration and did not say so, and the interface stayed up with a speed and a duplex that did not match the PHY. `stm32_phyinit()` polls the reset bit of the PHY and, if it does not clear in time, printed `ERROR: Phy reset timeout` and returned the result of the last MDIO read. When the PHY does not answer yet the bus reads all ones, and that read succeeds, so the function returned OK. The driver then configured the MAC with its default of 10 Mbps and half duplex, while the PHY went on to negotiate 100 Mbps and full duplex. The interface was up (`RUNNING`) and could not talk to anyone, and nothing said why. ### Commits 1. `arch/arm/stm32h7: fail the PHY initialization when the reset times out.` Returns `-ETIMEDOUT`, so that bringing the interface up fails. 2. `arch/arm/stm32h7: do not log the frames of packet sockets as unknown.` A frame that a packet socket consumes was given to `pkt_input()` and then logged as `DROPPED Unknown type` because it is neither IP nor ARP. With a PTP grandmaster on the network that is one warning for each frame, and the log of RAM fills in seconds, so it hides the messages of the start of the system, the ones that show a failed initialization. It is the same change that the driver of the legacy STM32 has. 3. `arch/arm/stm32h5: fail the PHY initialization when the reset times out.` The STM32H5 driver has the same code as the STM32H7 one. ## Impact - A board on which the PHY was not ready in time used to get an interface that was up with a wrong configuration, and now `ifup` fails with `ERROR: Phy reset timeout` and the interface stays down, so the failure can be seen and the interface brought up again once the PHY is ready. Boards on which the reset always completes are not affected. - Commit 2 only changes what is logged, with `CONFIG_NET_PKT`. ## Testing Built for a custom board with an STM32H753, a DP83848 PHY and `HCLK` at 200 MHz, with and without `CONFIG_NET_PKT`, on the current `master`, without errors or warnings. `./tools/checkpatch.sh -g upstream/master..HEAD` passes. On hardware (STM32H7, DP83848), with cold boots, that is with the power of the board cut: - Before the change, a cold boot could end with `Phy reset timeout` in the log, the MAC configured for 10 Mbps and half duplex while the PHY had negotiated 100 Mbps and full duplex, and an interface that showed `RUNNING` and did not answer ping or telnet. This happened in the three cold boots in a row that were checked, and never in a warm reset. - With the change, the same failure is reported: `ifup` fails, the MAC is left unconfigured and the interface stays down. A reboot (warm) brings it up. Once the board waited for the PHY to be ready (a board change that is not part of this PR), the following cold boots came up with 100 Mbps and full duplex. Not tested: - The STM32H5 change (commit 3) is the same line for the same code. It builds for `nucleo-h563zi:netnsh`, but it was not tested on hardware. - Commit 2 was built but not exercised on hardware with a grandmaster connected: the grandmaster was disconnected during the tests of this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
