Summary

Point lib/wiznet5k at WIZnet's ioLibrary_Driver instead of a fork that carries MicroPython-specific patches and has drifted from the library WIZnet maintains and tests, and rewrite extmod/network_wiznet5k.c against it. The library is vendored unchanged. WIZnet unified it last year, so one codebase now covers W5100 through W6300, which is what lets the later PRs add the W6xxx parts without a second driver.

The API is unchanged: same network.WIZNET5K class, same MICROPY_PY_NETWORK_WIZNET5K values, same wiznet5k_poll() / wiznet5k_deinit() entry points. No board files are touched, and the port build files only lose the fork-only defines.

The rewrite also carries a few fixes the driver needed anyway:

• the DHCP wait drives the library's one-second tick, so a lost request is retransmitted rather than stalling until the overall timeout
• the MAC address and the network configuration both survive active(False) / active(True)
• on lwIP, a failed send no longer takes the interface down, which nothing brought back up

The W6100 and W6300 register branches are in the driver already, but nothing selects those chips until the boards PR, so that code is not reachable yet.

First of the PRs splitting up #18035, which stays open for now. Once this is merged:

2. the new W5100S/W5500/W6100 EVB boards, which need no PIO
3. a general-purpose machine.PIOSPI on the rp2 port, plus the W6300 and W55RP20 boards, which talk to the chip over PIO and need it
4. socket timeout and setsockopt, which the old driver never had

Testing

Hardware, on W5100S-EVB-Pico and W5500-EVB-Pico, each built both with lwIP and with the WIZnet stack (MICROPY_PY_LWIP=0):

• DHCP, ifconfig(), status(), DNS
• TCP connect / send / recv, UDP sendto / recvfrom
• the MAC address and the configured address both survive active(False) / active(True)
• WIZnet stack only: Ctrl-C breaks out of a blocked recv(), which is what the second commit is for
• WIZnet stack only: a 32 KB send to a deliberately slow peer, to force the retry loop that replaces the library's blocking wait

Builds, with no warnings and no warning suppression:

• rp2: W5100S-EVB-Pico, W5500-EVB-Pico, SIL_RP2040_SHIM
• stm32: PYBV10, PYBV11, PYBLITEV10 (NETWORK variant), GARATRONIC_PYMATE_CORE8ADI8DOSC — build-tested only

The warnings the library's own headers used to raise were fixed upstream in Wiznet/ioLibrary_Driver#186, which the submodule is pinned to.

Known gaps on the WIZnet stack, the same before and after this change, so not regressions:

• socket.settimeout() is unimplemented
• recv() raises OSError(7) after the peer closes instead of returning b""
• a DNS lookup that gets no answer never returns, because DNS_run() only gives up on a one-second tick that the driver has never driven. gethostbyname() now refuses the lookup when the interface has no address, which is the way that is easy to hit by accident, but a DNS server that simply stays silent still hangs.

All three need the same waiting machinery, so they go with the socket timeout PR at the end of the series.

Trade-offs and Alternatives

• The alternative is to keep the fork and extend it for the W6xxx parts, which means maintaining the W6100 and W6300 register logic separately from the library WIZnet ships.
• The submodule at lib/wiznet5k now points at a different repository, so existing checkouts need git submodule sync --recursive before git submodule update --init --recursive.
• network.WIZNET5K keeps its name even though the driver now covers the W6xxx parts too, so existing user code is unaffected.
• The fork called a yield hook from the blocking loops in socket.c, which upstream has no equivalent for. Adding one to ioLibrary_Driver was the obvious fix, but that library has plenty of other users and shouldn't carry a MicroPython hook. The second commit opens the sockets non-blocking and waits in the driver instead, which the library already supports and which is also where a socket timeout has to live.