Re: [RFC net-next 00/12] net: add the PON subsystem

Hi John,

On Thu, Oct 08, 2026 at 04:32:37PM +0200, John Crispin wrote:

The scope is XGS-PON. The mode enum keeps gpon and xg-pon so that the
uapi order stays clean for later drivers.

A G-PON data point, since the framework thread mentioned Realtek only
as work with proprietary components. odi-oss [1] is open firmware for a
GPON SFP ONU stick on the Realtek RTL9602C. It runs mainline 6.18 with
GPL drivers of our own for the GPON MAC, the PLOAM state machine of
G.984.3, the CPU NIC and the switch, and with a userspace OMCI daemon.
Apart from the stock bootloader, the image has no vendor code or
binaries. It runs in production on two ISPs, and a user has it working
on a third.

I should be upfront: I am not a PON or kernel expert. The drivers were
written with an AI coding assistant, working from the ITU-T
recommendations and from register traces of the stock firmware, and
checked by trial and error on my own sticks against live OLTs. So take
what follows as field data from one G-PON implementation, not as
review from someone who knows the standards well. Corrections are very
welcome.

Our split is already the one this series takes: PLOAM in the MAC driver,
OMCI in userspace over netlink (a private family for now). So our G-PON
driver should be able to sit on net/pon, as a second MAC and a first
G-PON one, at least out of tree (the RTL9602C platform itself is not
upstream). Reading the series with that in mind, four things would get
in the way:

1. The activation edges. pon_state_legal[] is one table for every mode,
   and the comment says a per-mode split can wait for a second MAC. Our
   state machine follows G.984.3 Table 10-1, and five of its edges are
   not in the table:

     O3 -> O2  TO1 expires in Serial_Number
     O5 -> O2  Deactivate_ONU-ID in Operation (O6 -> O2 too)
     O6 -> O4  broadcast POPUP
     O6 -> O7  Disable_Serial_Number in POPUP
     O7 -> O2  Disable_Serial_Number "enable"; G.9807.1 goes to O1

   Each would be published with a warning on every occurrence. A table
   per mode, selected by the device mode, would fix it.

2. GEM port ids. The spec takes 1021 to 65534, the XGEM Port-ID range. A
   G-PON Port-ID is 12 bits. The operator with six GEM ports mentioned
   above assigns 269 to 909, and ours on the other ISP 1434 to 1946.
   The range would need to depend on the mode too.

3. The datapath of an SFP ONU. Service traffic never reaches the CPU on
   this stick. The switch bridges the host SerDes and the PON in
   hardware, and our OMCI daemon programs it from the MIB: GEM flows,
   upstream queues and VLAN treatment from the Extended VLAN Tagging ME.
   Only OMCI goes through the CPU NIC: received frames carry a trap
   reason in the RX descriptor, and we send with per-frame descriptor
   words (port and GEM stream). So OMCI fits the conduit contract well,
   but there is no data netdev to pair and nothing to bridge in Linux.
   Can a driver own the T-CONT, GEM and gem-map objects and offload
   them without a data netdev or GEM netdevs? The VLAN rules we need
   also go beyond tag/vid/pbit/dscp (double-tag rules, TPID, the
   treatment side), but that may belong to switchdev rather than here.

4. Observing OMCI. omci-ntf goes to the one registered socket. Being able
   to watch the exchange without taking over the channel, as Benjamin and
   Ziyou asked in the earlier thread, is what we use most when an OLT
   behaves oddly. A read-only multicast copy of the PDUs in both
   directions would cover it.

One small note for the docs: baseline G-PON OMCI ends with a CRC-32
trailer, not a MIC. On the RTL9602C neither direction is checked or
added by the MAC, so our driver would compute it in software. That fits
the current pdu attribute; the docs could just name the G-PON trailer
alongside the MIC.

If a per-mode state table and Port-ID range are acceptable, I can port
our driver onto the series and report back. I can also share PLOAM
traces from both ISPs.

[1] https://github.com/AndreZiviani/odi-oss

Thanks,
Andre Ziviani