drivers: mdio_esp32: let the REF_CLK be initialized before the PHY.

[iwasz]

When GPIO17 or 16 is used as an external REF_CLK signal, the output is enabled in eth_esp32.c This was added in PR number #65759 (by @bbilas ) and then refined in PR #74442 (by @sylvioalves). However this does not work for PHYs which need the REF_CLK for MDIO communication, such as LAN8720A. In such cases phy_mii driver tries to get the ID of such a PHY before REF_CLK is present. Therefore in this PR I propose to move REF_CLK initialization from eth_esp32.c to mdio_esp32.c which gets initialized before PHY and ETH.

There's a topic about this as well: #68907

[github-actions]

Hello @iwasz, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[marekmatej]

Hi @iwasz, any reason why the original location of the clock init remains the same? eth_esp32.c:282

[iwasz]

why the original location of the clock init remains the same? eth_esp32.c:282

Hey! I was unsure what to do about it. There's an #if DT_INST_NODE_HAS_PROP(0, ref_clk_output_gpios) there which decides if we want enable RMII input or output. If I remove the whole "true case" block that I moved to mdio_esp32.c then we would be left with something like:

#if !DT_INST_NODE_HAS_PROP(0, ref_clk_output_gpios)
		emac_hal_iomux_rmii_clk_input();
		emac_ll_clock_enable_rmii_input(dev_data->hal.ext_regs);
#endif

And then having ref-clk-output-gpios defined in the eth (i mean here dts/bindings/ethernet/espressif,esp32-eth.yaml) makes little sense - it would be used kinda like a boolean flag even though it's a phandle-array.

[cbrake]

This PR gets Ethernet working on the Olimex ESP32_POE boards.

My current setup:

https://github.com/simpleiot/zephyr-siot

https://github.com/simpleiot/zephyr-siot/blob/main/boards/esp32_poe/esp32_poe_procpu.dts#L169

Note, ref-clk-output-gpios = <&gpio0 17 0>; is required in both the mdio and eth sections, otherwise the mdio driver sets up the clock and the phy is detected, but then the eth driver shuts it off.

[MaureenHelm]

@sylvioalves please take a look

[bbilas]

Those changes do not look correct. That is copied and pasted from the eth_esp32 driver. @sylvioalves, could you take a look at it?

[kartben]

@sylvioalves wonder if you can have a look so we can unblock this

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cbrake]

Hi, we still need this fix. Is there any chance this can be merged, or an alternate solution worked on?

[bbilas]

unblock

unblock

[github-actions]

Hi @iwasz!
Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a fantastic achievement, and we're thrilled to have you as part of our community!

To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge.

Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁