NetworkNews

Linux 7.3 Picks Up Realtek's Cheap 10 Gigabit PHYs

On this page
  1. What is being merged
  2. Why the PHY is the piece that was missing
  3. The out of tree problem, ending
  4. What the hardware is
  5. What we would take from it
  6. Sources and further reading

Mainline Linux support for Realtek's RTL8261C and RTL8261D 10 Gigabit PHYs is queued in net-next for the 7.3 kernel cycle. That matters more than a driver addition usually does, because these are the parts Realtek built to make 10 Gigabit Ethernet cheap enough for consumer routers, switches and cable modems. The RTL8261C draws 1.65 watts in an eight by eight millimetre package, and its companion controller was projected to land in cards around thirty to forty dollars. Mainline support means the hardware works on a stock kernel, with no out of tree module to rebuild after every upgrade.

The short answer

Support for the Realtek RTL8261C and RTL8261D 10 Gigabit PHYs is queued in the networking net-next branch for Linux 7.3, building on the kernel's existing Clause 45 PHY code. The RTL8261C was announced at Computex in May 2025: 1.65 watts, a 56 pin QFN package of 8 by 8 millimetres, USXGMII and SFI on the system side plus 5000Base-X, 2500Base-X, 1000Base-X and SGMII, aimed at 5G customer premises equipment, PON, WiFi 6 and 7 routers, switches and cable modems. The RTL8261D followed earlier in 2026. An out of tree driver existed and was archived in June 2026, so mainline support removes a module that had to be rebuilt on every kernel upgrade.

1.65 Wpower draw of the RTL8261C, in an 8 by 8 mm QFN56 package
7.3kernel cycle that gets mainline support, queued in net-next
$30 to $40projected card pricing for the companion RTL8127 controller
Answer card: Linux 7.3 adds mainline support for the Realtek RTL8261C and RTL8261D 10 Gigabit PHYs, parts that draw 1.65 watts in an eight by eight millimetre package and target WiFi 6 and 7 routers, switches, PON and cable modems, replacing an out of tree driver that was archived in June 2026.
Realtek's low power 10 Gigabit PHYs are heading into mainline Linux. Source: the net-next queue for Linux 7.3. PNG

Ten Gigabit over copper has been ten years away for about ten years, and the reasons have been boring rather than mysterious. The silicon was expensive, it ran hot, and both of those pushed it into equipment with the budget and the thermal headroom to carry it. Realtek's answer to that is a PHY drawing 1.65 watts, and as of the Linux 7.3 cycle the kernel knows what to do with it.

What is being merged

Support for the RTL8261C and RTL8261D is queued in net-next, the networking subsystem's staging branch, for the Linux 7.3 merge window. The work builds on the kernel's existing Clause 45 PHY code rather than arriving as a standalone driver, which is the sensible shape for a part that mostly speaks the standardised register set with vendor specifics on top.

That is a small patch series by any measure. Its significance is not in its size.

Why the PHY is the piece that was missing

Linux splits an Ethernet interface into a MAC, which handles frames, and a PHY, which handles the wire. They talk over a management bus, and the split exists because board designers pair them freely: the same MAC turns up next to a dozen different transceivers depending on what the product needed and what was in stock.

The kernel therefore carries a PHY library and per vendor drivers underneath it. When the PHY has no driver, the kernel falls back on the standard registers, and the results range from fine to quietly wrong. Autonegotiation settles at a lower speed than the link can carry. Link training misbehaves on longer cable runs. Cable diagnostics are unavailable. The interface appears to work, in the specific sense that packets move, while the part of the hardware that would have made it work well sits unused.

That is why a PHY driver is worth more attention than its diff suggests.

The out of tree problem, ending

There has been an out of tree driver for the RTL8261C and RTL8261D. It was archived in June 2026, which is the ordinary and correct fate for such a repository once the code is heading upstream.

It is also a clean illustration of why out of tree is a bad place to keep a driver you depend on. The module has to be rebuilt against every kernel you install, which means DKMS on every machine or a pinned kernel you stop updating, and neither of those is a plan you want on network equipment. It breaks whenever an internal kernel interface shifts, which the kernel is explicitly entitled to do because it makes no stability promise to code outside the tree. And it stops being maintained the moment its author moves on, which you find out during an upgrade.

Once the driver is in mainline, none of that applies. It moves with the kernel, it gets fixed by the people making the changes that would otherwise break it, and it reaches you through your distribution without a build step.

Terminal card showing how to inspect an Ethernet PHY on Linux: ethtool to read negotiated speed and supported link modes, ethtool -i to identify the bound MAC driver, and a filtered dmesg to see which PHY driver the kernel attached at which MDIO bus address.
Finding out which PHY the kernel actually attached, and at what speed. PNG

What the hardware is

The RTL8261C was announced at Computex in May 2025. It is a 56 pin QFN package measuring eight by eight millimetres, drawing 1.65 watts, supporting USXGMII and SFI on the system side along with 5000Base-X, 2500Base-X, 1000Base-X and SGMII. Realtek positions it for 5G customer premises equipment, passive optical network gear, WiFi 6 and WiFi 7 routers, switches and cable modems, with an RTL8261CI industrial grade variant for wider temperature ranges. The RTL8261D began being promoted earlier in 2026 with comparable functionality.

It arrived alongside two companions announced at the same show. The RTL8127 is a PCIe Gen4 controller at 1.95 watts in a 88 pin QFN, projected into add in cards at roughly thirty to forty dollars, with fibre only and DASH capable variants. The RTL8159 is a USB 3.2 Gen2 by 2 controller in a 68 pin QFN, for adapters and docks.

Those three parts together are a deliberate attempt to make 10 Gigabit ordinary rather than premium, at the card, the adapter and the built in port.

What we would take from it

Not that cheap 10 Gigabit has arrived. A low power PHY removes one obstacle out of several, and the remaining ones are real: cabling, per port cost once a switch carries twenty four of these rather than one, and the total power budget of a device that is no longer paying 1.65 watts once.

What has changed is narrower and worth having. When this hardware does show up in a router or a small switch, and it will, Linux will already know how to drive it properly on a stock kernel. That is not usually how it goes with consumer networking silicon, and the difference between a named PHY driver and a generic fallback is the difference between a link that works and a link that works well.

Sources and further reading

Frequently asked questions

What is a PHY, and why does it need its own driver?

The PHY is the physical layer transceiver: the chip that turns the digital side of an Ethernet interface into the electrical or optical signalling that goes down the cable, and back again. It handles autonegotiation, link training, cable diagnostics and the low level timing. The MAC, which is the part that deals with frames, talks to it over a management bus. Linux keeps these separate because the same MAC can be paired with many different PHYs by different board designers, so the kernel has a PHY library and per vendor drivers that plug into it. If your PHY has no driver, the interface may come up at a fallback speed, or negotiate badly, or not come up at all, even though the MAC side is perfectly well supported.

Why does mainline support matter if an out of tree driver already existed?

Because an out of tree module is a maintenance commitment that never ends. It has to be rebuilt against every kernel you install, which means either DKMS on every machine or a pinned kernel you stop updating, and it breaks whenever an internal kernel interface changes, which the kernel is explicitly free to do. The out of tree RTL8261 driver that was circulating was archived in June 2026, which is the normal and reasonable fate of such a repository once the code is heading upstream, and it is also exactly the failure mode: the module you depend on stops being maintained by someone you have no relationship with. Once the driver is in mainline, it moves with the kernel, gets fixed by the people who change the interfaces around it, and arrives in your distribution without you doing anything.

What are the RTL8261C and RTL8261D actually for?

They are aimed at the equipment that sits at the edge of a network rather than inside a server. Realtek lists 5G customer premises equipment, passive optical network gear, WiFi 6 and WiFi 7 routers, switches and cable modems. The RTL8261C was announced at Computex in May 2025 in a fifty six pin QFN package measuring eight by eight millimetres, drawing 1.65 watts, and supporting USXGMII and SFI on the system side along with 5000Base-X, 2500Base-X, 1000Base-X and SGMII. There is an RTL8261CI industrial grade variant. The RTL8261D began being promoted by Realtek earlier in 2026 with comparable functionality.

Does this mean cheap 10 Gigabit gear is finally arriving?

It is one of the conditions, not the whole answer. Ten Gigabit copper has stayed expensive for a long list of reasons, and two of the biggest were that the silicon cost a lot and ran hot enough to need real thermal design, which pushed it into equipment with room and budget for both. A PHY at 1.65 watts in an eight millimetre package changes what a router or a small switch can carry without a redesign. Realtek's companion PCIe controller, the RTL8127, was projected into cards at roughly thirty to forty dollars. What none of that settles is cabling, switch port cost per port at scale, or the power budget of a device with eight of these rather than one. Treat it as the floor coming down rather than the problem being solved.

How do I tell which PHY a Linux box is using?

Start with ethtool on the interface, which reports the supported and advertised link modes, the negotiated speed and duplex, and often the PHY address. The driver and bus information from ethtool -i tells you which MAC driver is bound. For the PHY specifically, the kernel log at boot usually names the device it attached, in the form of a driver name and an MDIO bus address, so a filtered dmesg is the quickest route. On a system where the PHY is not recognised, that log line is where the absence shows up: you will see a generic Clause 45 or Clause 22 attachment rather than a named part, which is the signal that the kernel is falling back on standard registers instead of a driver that knows the chip.