@JohannesMaierhofer @DuaneKaufman are you able to test this PR?

@dpgeorge I tested this on a board with LAN8671 chip and when I try to create the LAN object I get this error:

>>> lan = network.LAN(mdc = machine.Pin(8), mdio = machine.Pin(7),
...                   power = None, phy_type = network.PHY_LAN8670, phy_addr=0)
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
OSError: esp_eth_driver_install failed with invalid argument

Which is odd, because on the same board, a previously hacked together proof-of-concept MicroPython build initializes the LAN8671 as expected without error. Not sure what the difference is.

Oh, if I run it again after that failure, I get an extra error:

>>> lan = network.LAN(mdc = machine.Pin(8), mdio = machine.Pin(7),
...                   power = None, phy_type = network.PHY_LAN8670, phy_addr=0)
E (2977611) esp_netif_lwip: esp_netif_new_api: Failed to configure netif with config=0x3ffd74fc (config or if_key is NULL or duplicate key)
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
OSError: esp_eth_driver_install failed with invalid argument

I tested this on a board with LAN8671 chip and when I try to create the LAN object I get this error:

@xorbit There was a bug, the LAN8670 was accidentally grouped with the SPI/Ethernet PHYs so it failed to install. I've pushed an updated commit and it should work now, but I'm not able to test it apart from verifying that the install step passes.

I tried this new commit and it seems to work on my boards. 👍

However, I had some problem with the make submodules not pulling in berkeley db, I needed to apply this fix first:
https://github.com/orgs/micropython/discussions/10658

Anyway, that's not really related to this PR I think.

I was wondering if it would make sense to have the idf_component.yml defined per board?

If not, how many boards fail to build with IDF 5.3+?

@DuaneKaufman it is a custom board that hopefully soon will become a product. The timing of which may hinge on this PR making it into mainline MicroPython. 😆

I was wondering if it would make sense to have the idf_component.yml defined per board?

Probably not, we already have multiple copy-paste copies and changing to that we'd have dozens. However, we could maybe provide a way to override idf_component.yml for a particular board.

(I think you can already add a custom in-tree component to a board via mpconfigboard.cmake, and that component can have its own idf_component.yml file that pulls in a Component Manager component like this one. However that's likely not even a per-board solution for this case as the "main" network.LAN implementation needs to know about the PHY component...)

If not, how many boards fail to build with IDF 5.3+?

Probably none, but the question is more "are there subtle behaviour changes or regressions when built with IDF 5.3+?"

Updating the minimum IDF version boils down to two things:

• Currently the nightly builds are done with IDF 5.2.2. We can switch this up to 5.3 at some point, but there's some risk of a subtle regression that tests haven't found. So ideally we don't do this right before a release (for example).
• After doing that, we could drop support for IDF 5.2.x and anyone building their own board will need to update ESP-IDF. We can do this whenever we want, but it's not particularly convenient for folks (and we only dropped support for <5.2 six weeks ago, in esp32: Remove support for ESP-IDF <5.2 #16128).

There's also the bigger picture view, which is that if MicroPython has a need to keep adding support for features distributed via ESP-IDF component manager, and if these components may have particular version or platform requirements, then we may need a way to support them flexibly.

I've reworked this PR so that it builds a new main_esp32_idf53 component if IDF>=5.3 is in use, and the old main_esp32 component otherwise. When we drop support for ESP-IDF 5.2.x these components can be merged again.

Nightly builds currently use ESP-IDF 5.2.2 so they won't contain LAN8670 support immediately after this merges. To get support you'll need to build MicroPython locally with a newer ESP-IDF version (5.3.x or 5.4.x).

Suggest after 1.25.0 releases that we bump the build version (for nightly and CI) to use ESP-IDF 5.3.2.

I've reworked this PR so that it builds a new main_esp32_idf53 component if IDF>=5.3 is in use, and the old main_esp32 component otherwise. When we drop support for ESP-IDF 5.2.x these components can be merged again.

Turns out I didn't look hard enough at the Component Manager docs, it can do conditional dependencies just fine. 🤦 So have simplified to this!

I think we can use this technique to collapse the per-target main_xyz components down to one main component again. Have made a note to look at this when I have a chance.

Is there a reason this is not being merged? I'm waiting on this functionality to create a new board definition.

Is there a reason this is not being merged? I'm waiting on this functionality to create a new board definition.

Thanks for being patient. The 1.25 release has run behind and this feature is slated for 1.26. 1.25 should be released very soon, at which point we'll start merging 1.26 changes.

I've just rebased this PR on master to resolve the merge conflict.

Thank you for the update, I just wanted to ensure this wasn't lost in the shuffle. 😊

IDF is now at 5.4.1 and this PR is now merged. LAN8670 should be supported by the ESP32 (only) in latest downloads.

Awesome, thank you!

Yes, this is good news - thanks!