drivers: ethernet: stm32: remove phy specific code #87593

maass-hamburg · 2025-03-24T21:00:52Z

enable mdio also on legacy devices
remove phy specific code from stm32 ethernet driver
setting the phy-handle of the ethernac mac is now mandatory
phys, that don't use mdio or the standard registers can now be used.

drivers/ethernet/eth_stm32_hal.c

mathieuchopstm

FWIW, I had something similar in stock (but not upstreamed); I have published the branch here if you want to take a look: https://github.com/mathieuchopstm/zephyr/tree/stm32_ethernet_rework

This branch is more conservative in terms of changes to the ETH driver, but uses some macrobatics in the MDIO driver to share the ETH_HandleTypeDef with its parent controller (saves RAM as the structure is quite large, but inhibits usage as a general-purpose MDIO; maybe an in-between solution could be found).

Another change I did was rename all "MDIO"-related stuff to clearly emphasize that this driver is for the MDIO controller built into the Ethernet IP (as opposed to the dedicated "general-purpose" MDIO controllers found on STM32H7) - this could be appreciated, but is mostly cosmetic, so not that important.

boards/arduino/opta/arduino_opta_stm32h747xx_m7.dts

boards/st/stm32f746g_disco/stm32f746g_disco.dts

drivers/ethernet/Kconfig.stm32_hal

drivers/mdio/mdio_stm32_hal.c

dts/arm/st/f1/stm32f107.dtsi

dts/arm/st/h5/stm32h5.dtsi

dts/arm/st/h7/stm32h7.dtsi

dts/arm/st/n6/stm32n6.dtsi

dts/arm/st/f1/stm32f107.dtsi

drivers/ethernet/eth_stm32_hal.c

drivers/mdio/mdio_stm32_hal.c

mathieuchopstm · 2025-03-27T16:06:42Z

Can someone verify, that it works on boards, that use the v1 eth hal api? I don't have a stm32f1* or stm32f2* board on hand.

Tested OK on Nucleo-F207ZG with samples/net/dhcpv4_client. I haven't found stm3210c_eval board here, and it seems to be the only STM32F1 board supported in Zephyr that has Ethernet, so F1 is untested for now...

Not 100% related but the call to HAL_ETH_Init() in eth_initialize() is blocking, delaying boot and console output by 5s when cable is unplugged (and still ~1.5s when plugged). I would have sworn I didn't encounter this behavior when I was testing my original patch, but I can't see any commit that changed this behavior, so I'm not really sure that my memory is correct... either way, this falls outside PR scope so ignore it.

maass-hamburg · 2025-03-27T16:20:36Z

Can someone verify, that it works on boards, that use the v1 eth hal api? I don't have a stm32f1* or stm32f2* board on hand.

Tested OK on Nucleo-F207ZG with samples/net/dhcpv4_client. I haven't found stm3210c_eval board here, and it seems to be the only STM32F1 board supported in Zephyr that has Ethernet, so F1 is untested for now...

Not 100% related but the call to HAL_ETH_Init() in eth_initialize() is blocking, delaying boot and console output by 5s when cable is unplugged (and still ~1.5s when plugged). I would have sworn I didn't encounter this behavior when I was testing my original patch, but I can't see any commit that changed this behavior, so I'm not really sure that my memory is correct... either way, this falls outside PR scope so ignore it.

The thing is, that HAL_ETH_Init() in the v1 api also communicates (blocking) with the phy via mdio. Best thing would be, that f1 and f2 get the new api in the hal, next best thing would be to copy the content of these functions to the zepyhr tree and remove the communication part with the phy.

mathieuchopstm · 2025-03-27T16:35:35Z

The thing is, that HAL_ETH_Init() in the v1 api also communicates (blocking) with the phy via mdio.

I didn't look at the implementation but assumed it was something like that, so makes sense.
Though as I said, it's not an issue/regression since the driver presumably always behaved like this. We can think of ways to improve this in a follow-up PR 🙂

mathieuchopstm · 2025-03-27T16:11:24Z

dts/arm/st/f1/stm32f107.dtsi

+			clocks = <&rcc STM32_CLOCK(AHB1, 14)>;
+			mac: ethernet {


To improve readability, please add a newline between the properties and the child nodes:

Suggested change

clocks = <&rcc STM32_CLOCK(AHB1, 14)>;

mac: ethernet {

clocks = <&rcc STM32_CLOCK(AHB1, 14)>;

mac: ethernet {

Ditto for all DTSI.

mathieuchopstm · 2025-03-27T16:36:17Z

drivers/mdio/mdio_stm32_hal.c

+#ifdef CONFIG_ETH_STM32_HAL_API_V2
+	HAL_ETH_SetMDIOClockRange(heth);
+#else /* CONFIG_ETH_STM32_HAL_API_V1 */
+	/* The legacy V1 HAL API does not provide a way to set the MDC clock range
+	 * via a separated function call.
+	 */
+	uint32_t tmpreg1 = 0U;
+
+	/* Get the ETHERNET MACMIIAR value */
+	tmpreg1 = (heth->Instance)->MACMIIAR;
+	/* Clear CSR Clock Range CR[2:0] bits */
+	tmpreg1 &= ETH_MACMIIAR_CR_MASK;
+
+	/* Set CR bits depending on CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC value */
+#ifdef SOC_SERIES_STM32F1X
+	if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 20000000U) &&
+	    (CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 35000000U)) {
+		/* CSR Clock Range between 20-35 MHz */
+		tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_DIV16;
+	} else if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 35000000U) &&
+		   (CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 60000000U)) {
+		/* CSR Clock Range between 35-60 MHz */
+		tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_DIV26;
+	} else {
+		/* CSR Clock Range between 60-72 MHz */
+		tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_DIV42;
+	}
+#else  /* SOC_SERIES_STM32F2X */
+	if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 20000000U) &&
+	    (CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 35000000U)) {
+		/* CSR Clock Range between 20-35 MHz */
+		tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div16;
+	} else if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 35000000U) &&
+		   (CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 60000000U)) {
+		/* CSR Clock Range between 35-60 MHz */
+		tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div26;
+	} else if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 60000000U) &&
+		   (CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 100000000U)) {
+		/* CSR Clock Range between 60-100 MHz */
+		tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div42;
+	} else {
+		/* CSR Clock Range between 100-120 MHz */
+		tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div62;
+	}
+#endif /* SOC_SERIES_STM32F2X */
+
+	/* Write to ETHERNET MAC MIIAR: Configure the ETHERNET CSR Clock Range */
+	(heth->Instance)->MACMIIAR = (uint32_t)tmpreg1;
+#endif /* CONFIG_ETH_STM32_HAL_API_V1 */


Please split out to a dedicated function somewhere else in this file:

Suggested change

#ifdef CONFIG_ETH_STM32_HAL_API_V2

HAL_ETH_SetMDIOClockRange(heth);

#else /* CONFIG_ETH_STM32_HAL_API_V1 */

/* The legacy V1 HAL API does not provide a way to set the MDC clock range

* via a separated function call.

*/

uint32_t tmpreg1 = 0U;

/* Get the ETHERNET MACMIIAR value */

tmpreg1 = (heth->Instance)->MACMIIAR;

/* Clear CSR Clock Range CR[2:0] bits */

tmpreg1 &= ETH_MACMIIAR_CR_MASK;

/* Set CR bits depending on CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC value */

#ifdef SOC_SERIES_STM32F1X

if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 20000000U) &&

(CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 35000000U)) {

/* CSR Clock Range between 20-35 MHz */

tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_DIV16;

} else if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 35000000U) &&

(CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 60000000U)) {

/* CSR Clock Range between 35-60 MHz */

tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_DIV26;

} else {

/* CSR Clock Range between 60-72 MHz */

tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_DIV42;

}

#else /* SOC_SERIES_STM32F2X */

if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 20000000U) &&

(CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 35000000U)) {

/* CSR Clock Range between 20-35 MHz */

tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div16;

} else if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 35000000U) &&

(CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 60000000U)) {

/* CSR Clock Range between 35-60 MHz */

tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div26;

} else if ((CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC >= 60000000U) &&

(CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC < 100000000U)) {

/* CSR Clock Range between 60-100 MHz */

tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div42;

} else {

/* CSR Clock Range between 100-120 MHz */

tmpreg1 |= (uint32_t)ETH_MACMIIAR_CR_Div62;

}

#endif /* SOC_SERIES_STM32F2X */

/* Write to ETHERNET MAC MIIAR: Configure the ETHERNET CSR Clock Range */

(heth->Instance)->MACMIIAR = (uint32_t)tmpreg1;

#endif /* CONFIG_ETH_STM32_HAL_API_V1 */

#ifdef CONFIG_ETH_STM32_HAL_API_V2

HAL_ETH_SetMDIOClockRange(heth);

#else /* CONFIG_ETH_STM32_HAL_API_V1 */

/* The legacy V1 HAL API does not provide a way to set the MDC clock range

* via a separated function call. Implement an equivalent function ourselves

* based on what the V1 HAL performs in HAL_ETH_Init().

*/

eth_set_mdio_clock_range_for_hal_v1(heth);

#endif /* CONFIG_ETH_STM32_HAL_API_V1 */

(function name is a suggestion, feel free to use something else if it feels better to you)

maass-hamburg · 2025-03-28T14:03:54Z

#85679 seems to be merged soon, have to apply changes to their new boards/st/nucleo_f439zi/nucleo_f439zi.dts too, when it's merged

drivers/mdio/mdio_stm32_hal.c

add mdio for legacy stm32 api Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

The api takes care, if the mdio bus_enable and bus_disable are not needed, so there is no need to have tis in the driver. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

add mdio and phy node to every stm32board that supports ethernet. Also set the phy-handle for every ethernet mac. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

mac and mdio are now on the same level, this way phy-handle can be used. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

move stmmaceth clock to parent, so it can also be used by mdio and rename it to ``stm-eth``. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

rewirte code and remove code that use internal phy functions. A few Kconfig options got removed, that are now set by the phy via the DT. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

make stm32 mdio driver more independent Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

unfortunatly HAL_ETH_SetMDIOClockRange() isn't available in the V1 API, so I had to copy the parts from the hal. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

update migration guide for changes of the stm32 ethernet driver. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

maass-hamburg · 2025-03-28T15:21:22Z

#85679 seems to be merged soon, have to apply changes to their new boards/st/nucleo_f439zi/nucleo_f439zi.dts too, when it's merged

Done

maass-hamburg mentioned this pull request Mar 24, 2025

Ethernet: Add support stm32n6570_dk #87562

Open

maass-hamburg force-pushed the stm32_ethernet_improve branch 3 times, most recently from 44412ae to 24d4c5b Compare March 25, 2025 10:05

maass-hamburg marked this pull request as ready for review March 25, 2025 10:10

zephyrbot added area: MDIO area: Ethernet platform: STM32 ST Micro STM32 labels Mar 25, 2025

zephyrbot requested review from decsny, djiatsaf-st, erwango, facchinm, FRASTM, gautierg-st, GeorgeCGV, lmajewski, marwaiehm-st, mathieuchopstm, pdgendt and pillo79 March 25, 2025 10:10

zephyrbot assigned pillo79 Mar 25, 2025

maass-hamburg assigned erwango and unassigned pillo79 Mar 25, 2025

marwaiehm-st reviewed Mar 25, 2025

View reviewed changes

drivers/ethernet/eth_stm32_hal.c Outdated Show resolved Hide resolved

drivers/ethernet/eth_stm32_hal.c Outdated Show resolved Hide resolved

drivers/ethernet/eth_stm32_hal.c Outdated Show resolved Hide resolved

maass-hamburg force-pushed the stm32_ethernet_improve branch from 24d4c5b to 60cc0af Compare March 25, 2025 12:30

marwaiehm-st reviewed Mar 25, 2025

View reviewed changes

drivers/ethernet/eth_stm32_hal.c Outdated Show resolved Hide resolved

maass-hamburg force-pushed the stm32_ethernet_improve branch from 60cc0af to ac5451d Compare March 25, 2025 15:51

mathieuchopstm reviewed Mar 25, 2025

View reviewed changes

marwaiehm-st reviewed Mar 25, 2025

View reviewed changes

mathieuchopstm reviewed Mar 25, 2025

View reviewed changes

drivers/ethernet/eth_stm32_hal.c Outdated Show resolved Hide resolved

drivers/mdio/mdio_stm32_hal.c Outdated Show resolved Hide resolved

maass-hamburg requested review from marwaiehm-st and erwango March 27, 2025 15:08

maass-hamburg force-pushed the stm32_ethernet_improve branch from a215d4f to b8091e7 Compare March 27, 2025 15:24

mathieuchopstm reviewed Mar 27, 2025

View reviewed changes

maass-hamburg force-pushed the stm32_ethernet_improve branch from b8091e7 to f4d8759 Compare March 27, 2025 18:42

maass-hamburg requested a review from mathieuchopstm March 27, 2025 18:43

maass-hamburg removed the DNM This PR should not be merged (Do Not Merge) label Mar 27, 2025

github-actions bot added the Release Notes To be mentioned in the release notes label Mar 27, 2025

github-actions bot requested a review from fabiobaltieri March 27, 2025 19:14

maass-hamburg force-pushed the stm32_ethernet_improve branch 2 times, most recently from 45c454a to f333bf5 Compare March 28, 2025 11:10

marwaiehm-st reviewed Mar 28, 2025

View reviewed changes

drivers/mdio/mdio_stm32_hal.c Outdated Show resolved Hide resolved

maass-hamburg force-pushed the stm32_ethernet_improve branch from f333bf5 to 6950734 Compare March 28, 2025 14:27

maass-hamburg requested a review from marwaiehm-st March 28, 2025 14:28

maass-hamburg added 2 commits March 28, 2025 16:17

drivers: mdio: stm32: add mdio for legacy api

0a6343d

add mdio for legacy stm32 api Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

drivers: mdio: stm32: remove unused functions

f8d3797

The api takes care, if the mdio bus_enable and bus_disable are not needed, so there is no need to have tis in the driver. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

maass-hamburg force-pushed the stm32_ethernet_improve branch from 6950734 to f89f9aa Compare March 28, 2025 15:17

maass-hamburg added 7 commits March 28, 2025 16:21

boards: dts: stm32: add mdio and phy node

ef88607

add mdio and phy node to every stm32board that supports ethernet. Also set the phy-handle for every ethernet mac. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

drivers: ethernet: stm32: make mac a child like the mdio node

7b322f5

mac and mdio are now on the same level, this way phy-handle can be used. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

drivers: ethernet: mdio: stm32: move stmmaceth clock to parent

a3de2d6

move stmmaceth clock to parent, so it can also be used by mdio and rename it to ``stm-eth``. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

drivers: ethernet: stm32: remove internal phy code

55117f2

rewirte code and remove code that use internal phy functions. A few Kconfig options got removed, that are now set by the phy via the DT. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

drivers: mdio: stm32: make driver more independent

e67a09e

make stm32 mdio driver more independent Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

drivers: mdio: stm32: set mdio clock for v1 api

97e0e32

unfortunatly HAL_ETH_SetMDIOClockRange() isn't available in the V1 API, so I had to copy the parts from the hal. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

doc: update migration guide for stm32 ethernet driver

d20d92f

update migration guide for changes of the stm32 ethernet driver. Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>

maass-hamburg force-pushed the stm32_ethernet_improve branch from f89f9aa to d20d92f Compare March 28, 2025 15:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

drivers: ethernet: stm32: remove phy specific code #87593

drivers: ethernet: stm32: remove phy specific code #87593

maass-hamburg commented Mar 24, 2025 •

edited

Loading

mathieuchopstm left a comment

mathieuchopstm commented Mar 27, 2025

maass-hamburg commented Mar 27, 2025 •

edited

Loading

mathieuchopstm commented Mar 27, 2025

mathieuchopstm Mar 27, 2025

maass-hamburg Mar 28, 2025

mathieuchopstm Mar 27, 2025

maass-hamburg Mar 27, 2025

maass-hamburg Mar 28, 2025

maass-hamburg commented Mar 28, 2025

maass-hamburg commented Mar 28, 2025

drivers: ethernet: stm32: remove phy specific code #87593

Are you sure you want to change the base?

drivers: ethernet: stm32: remove phy specific code #87593

Conversation

maass-hamburg commented Mar 24, 2025 • edited Loading

mathieuchopstm left a comment

Choose a reason for hiding this comment

mathieuchopstm commented Mar 27, 2025

maass-hamburg commented Mar 27, 2025 • edited Loading

mathieuchopstm commented Mar 27, 2025

mathieuchopstm Mar 27, 2025

Choose a reason for hiding this comment

maass-hamburg Mar 28, 2025

Choose a reason for hiding this comment

mathieuchopstm Mar 27, 2025

Choose a reason for hiding this comment

maass-hamburg Mar 27, 2025

Choose a reason for hiding this comment

maass-hamburg Mar 28, 2025

Choose a reason for hiding this comment

maass-hamburg commented Mar 28, 2025

maass-hamburg commented Mar 28, 2025

maass-hamburg commented Mar 24, 2025 •

edited

Loading

maass-hamburg commented Mar 27, 2025 •

edited

Loading