The Community Is Asking Espressif to Officially Support W6300 Quad SPI Ethernet

Community Spotlight. A developer in the ESP32 community has opened a feature request on Espressif's official esp-eth-drivers repository asking for Dual SPI / Quad SPI (QSPI) Ethernet driver support — and the chip they put forward as the example is WIZnet's W6300 (Issue #148, IDFGH-17521). It's a meaningful signal: the case for high-throughput SPI Ethernet on ESP32 is now being made by the community, with W6300 as the reference.

Tags — Espressif / ESP-IDF · QSPI · Dual SPI · W6300 · WIZ630io · Open Source

How it started

The request began with a real wall a maker hit. The developer was building an MJPEG image-streaming node on the ESP32-C5 and ran into two practical problems:

1. Wi-Fi wasn't reliable enough for a continuous stream, and
2. the ESP32-C5 doesn't expose RMII, so the usual "internal EMAC + external PHY" 100 Mbps path wasn't available.

That left SPI-based Ethernet as the natural fallback — but ordinary single-line SPI controllers bottleneck well below the 100 Mbps line rate, because the SPI bus itself becomes the limit. For pushing video, that ceiling matters. So the developer reached for a chip that breaks the single-line bottleneck — the W6300, which speaks Quad SPI — and measured it saturating 90 Mbps+ over QSPI in their own setup. The reasoning behind the request: if a single community member can already hit those numbers, official driver support would let many more makers experiment with Dual/Quad SPI Ethernet out of the box.

On the number: the 90 Mbps+ in the issue is the requester's own reported result. It lines up with WIZnet's published spec for the W6300 — rated for over 90 Mbps at a 150 MHz system clock over the 4-lane QSPI interface.

The advantages the request highlights

• More throughput, same SPI simplicity — QSPI uses 4 data lines instead of 1, getting close to 100 Mbps-class performance without the complexity of RMII/MII, an external PHY, and the associated PCB routing.
• A viable path where RMII isn't an option — on parts like the ESP32-C5 that lack RMII, high-speed serial Ethernet isn't a compromise; it's the only practical wired route, and QSPI raises its ceiling substantially.
• A robust alternative to flaky Wi-Fi — for always-on, performance-critical workloads (live video, telemetry), a wired link removes RF variability.
• Streaming-class use cases become realistic — MJPEG streaming from an ESP32-C5 is exactly the kind of bandwidth-hungry task single-SPI struggles with but QSPI can serve.

What the W6300 brings to the table

Because the TCP/IP stack runs inside the chip, the host MCU is freed from software networking overhead — it just reads and writes socket buffers over the now-faster QSPI bus, leaving an ESP32-C5 free to spend its cycles on the application (encoding/forwarding frames). Easy experimentation hardware includes the WIZ630io / WIZ630MJ modules and the W6300-EVB-Pico / Pico2 boards; the issue itself name-checks the WIZ630io.

Where it stands today — and why the direction is positive

To be precise about the status: this is currently an open feature request, not a merged driver. It has an Espressif internal tracker ID (IDFGH-17521), which simply means the issue has been synced into their system where the team can see it — it does not mean implementation is committed. Priority assessment, scheduling, development, and review/merge all still lie ahead, and feature requests can stall or be left open for community contribution along the way.

What's encouraging is the direction, not a finished feature:

• Espressif's esp-eth-drivers collection already includes an official W5500 driver — but, like every other SPI Ethernet driver there today (CH390, DM9051, ENC28J60, KSZ8851SNL, LAN865X), it runs over single-line SPI.
• A W6300 QSPI driver would therefore be the first multi-lane SPI Ethernet driver in Espressif's official collection — opening a performance tier that doesn't exist there yet.

The push for high-throughput SPI Ethernet on ESP32 is coming organically from developers solving real problems, and the W6300 is the chip they're rallying around. When an ecosystem's official tooling starts moving toward a capability because makers keep asking for it, that's usually how good support eventually lands.

If you're building on ESP32 and have ever wished your SPI Ethernet link could move more data, this thread is worth watching — and worth adding to. Benchmark QSPI throughput yourself on a W6300-EVB-Pico or WIZ630io, share your use case, and follow Issue #148. Real numbers from real setups are the most persuasive thing you can contribute toward turning a feature request into a roadmap item.