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

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

[John Crispin]

This series adds net/pon, a subsystem for the ONU side of an ITU-T
passive optical network. It follows the thread "[RFC] net: towards a
generic PON framework" [1], which converged on a wiphy-like PON object
that is not a netdev, PLOAM in the MAC driver, service traffic on
ordinary netdevs and OMCI in userspace. This is that design as working
code.

The model is cfg80211 with a fullmac driver:

- struct pon_dev is the PON object. It is not a netdev. Userspace
  addresses it by a device id, as nl80211 addresses a wiphy.
- The MAC driver runs PLOAM activation and the key hierarchy. It
  reports the activation state through pon_dev_state_report(). The
  core validates the edge against ITU-T G.9807.1 Table C.12.4,
  publishes it and sets the carrier from it.
- The core owns the T-CONTs, the GEM ports and the upstream classifier
  rules (the 802.1p mapper of the thread). It stores them and dumps
  them. The driver offloads them.
- The core lends the driver a serialized context: an ordered workqueue
  per instance and the instance lock that the netlink handlers take.
- Service traffic uses a data netdev plus GEM netdevs (rtnetlink link
  kind "gem") where a GEM port needs a bridge port of its own. Frames
  ride the rings of an ethernet controller, the conduit, with the per
  frame information passed as arguments.
- OMCI travels over the pon genl family the way nl80211 carries
  management frames. One socket registers for the OMCI PDUs of a
  device, receives them as notifications and sends with omci-tx. No
  OMCI netdev and no new address family.
- Control is one generic netlink family with a YAML spec. The uapi
  header and the policy are generated.

This posting is the minimal core. The counters, alarms, events, the
ETS scheduler offload, a PON mode for the generic PHY framework, the PON
PCS object and the flow offload are further commits on top of it that
come in later series.

The scope is XGS-PON. The mode enum keeps gpon and xg-pon so that the
uapi order stays clean for later drivers. The core refuses a mode that
the device does not list.

The first driver is for the Airoha AN7581 PON MAC, with its PON PHY, an
optics driver and the conduit in airoha_eth. It is not part of this
posting, because it depends on the Airoha PCS series that is not
upstream yet. pon-tool [2] consumes the family through the libpon
library. It has a verb for every attribute of the family and runs in
OpenWrt today. The stack reaches O5, passes traffic and recovers from
fiber pulls against a production OLT with HGU, SFU and IP host services
at the same time.

[1] https://lore.kernel.org/netdev/20260926174601.1675-1-yhyxwgy@gmail.com/
[2] https://github.com/blogic/pon-tool

John Crispin (12):
  net: pon: add the netlink specification of the pon family
  net: add a PON device pointer to struct net_device
  net: pon: add the PLOAM vocabulary and message codec
  net: pon: add the device state and the lent context
  net: pon: add the conduit contract
  net: pon: add the GEM network devices
  net: pon: add the OMCI channel
  net: pon: add netlink support
  net: pon: add the device registration
  net: pon: build the PON subsystem
  Documentation: networking: describe the PON subsystem
  MAINTAINERS: add the PON subsystem

 Documentation/netlink/specs/pon.yaml     |  604 ++++++++
 Documentation/netlink/specs/rt-link.yaml |   14 +
 Documentation/networking/index.rst       |    1 +
 Documentation/networking/pon.rst         |  302 ++++
 MAINTAINERS                              |   11 +
 include/linux/netdevice.h                |    6 +
 include/net/pon.h                        |   14 +
 include/net/pon/functions.h              |  129 ++
 include/net/pon/ploam.h                  |  266 ++++
 include/net/pon/ploam_msg.h              |  306 ++++
 include/net/pon/types.h                  |  443 ++++++
 include/uapi/linux/if_link.h             |   10 +
 include/uapi/linux/pon.h                 |  166 +++
 net/Kconfig                              |    1 +
 net/Makefile                             |    1 +
 net/pon/Kconfig                          |   17 +
 net/pon/Makefile                         |    6 +
 net/pon/pon-nl-gen.c                     |  286 ++++
 net/pon/pon-nl-gen.h                     |   45 +
 net/pon/pon.h                            |  162 +++
 net/pon/pon_conduit.c                    |  614 ++++++++
 net/pon/pon_gem.c                        |  537 +++++++
 net/pon/pon_main.c                       |  454 ++++++
 net/pon/pon_nl.c                         | 1671 ++++++++++++++++++++++
 net/pon/pon_omci.c                       |  326 +++++
 net/pon/pon_ploam_msg.c                  |  312 ++++
 net/pon/pon_state.c                      |  408 ++++++
 net/pon/pon_work.c                       |  106 ++
 tools/net/ynl/Makefile.deps              |    1 +
 29 files changed, 7219 insertions(+)
 create mode 100644 Documentation/netlink/specs/pon.yaml
 create mode 100644 Documentation/networking/pon.rst
 create mode 100644 include/net/pon.h
 create mode 100644 include/net/pon/functions.h
 create mode 100644 include/net/pon/ploam.h
 create mode 100644 include/net/pon/ploam_msg.h
 create mode 100644 include/net/pon/types.h
 create mode 100644 include/uapi/linux/pon.h
 create mode 100644 net/pon/Kconfig
 create mode 100644 net/pon/Makefile
 create mode 100644 net/pon/pon-nl-gen.c
 create mode 100644 net/pon/pon-nl-gen.h
 create mode 100644 net/pon/pon.h
 create mode 100644 net/pon/pon_conduit.c
 create mode 100644 net/pon/pon_gem.c
 create mode 100644 net/pon/pon_main.c
 create mode 100644 net/pon/pon_nl.c
 create mode 100644 net/pon/pon_omci.c
 create mode 100644 net/pon/pon_ploam_msg.c
 create mode 100644 net/pon/pon_state.c
 create mode 100644 net/pon/pon_work.c


base-commit: 8df0638138d3e0344fd1fb36cf2d1ca1cf5028f0
-- 
2.34.1

[RFC net-next 11/12] Documentation: networking: describe the PON subsystem

[John Crispin]

pon.rst describes the model, activation and why its state machine runs
in the driver, the activation log, the objects across a loss of the
link, the lent context, the OMCI channel, the conduit and the netlink
interface. It says which modes the uapi reserves and that the core
refuses a mode the device does not list.

Assisted-by: LLM
Signed-off-by: John Crispin <john@phrozen.org>
---
 Documentation/networking/index.rst |   1 +
 Documentation/networking/pon.rst   | 302 +++++++++++++++++++++++++++++
 2 files changed, 303 insertions(+)
 create mode 100644 Documentation/networking/pon.rst

diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 44a422ad3b05..05eaac7212f3 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -96,6 +96,7 @@ Contents:
    phy-port
    pktgen
    plip
+   pon
    ppp_generic
    proc_net_tcp
    pse-pd/index
diff --git a/Documentation/networking/pon.rst b/Documentation/networking/pon.rst
new file mode 100644
index 000000000000..732e6449d522
--- /dev/null
+++ b/Documentation/networking/pon.rst
@@ -0,0 +1,302 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+Passive optical network ONU
+===========================
+
+Overview
+========
+
+``net/pon`` is the kernel side of an optical network unit, the subscriber end
+of a passive optical network. One optical line terminal in the exchange serves
+many ONUs over a shared fiber. Downstream is a broadcast the ONU filters.
+Upstream is time division multiple access and an ONU may only transmit inside
+the windows the OLT grants it.
+
+The subsystem implements ITU-T G.9807.1 (XGS-PON): the PLOAM codec and the
+identifier ranges are those of G.9807.1. The uapi also
+reserves the modes of G.984 (GPON) and G.987 (XG-PON) for later drivers, as
+well as the activation state o3 of G.984.3. The core implements none of those
+systems. A device lists the modes it supports in its capabilities. The core
+refuses any other mode. The subsystem does not cover EPON, which is IEEE
+802.3ah and a different access method.
+
+The model
+=========
+
+Three objects carry the datapath and they nest:
+
+Device
+  One PON MAC. It has an identity the OLT authenticates, a mode and an
+  activation state.
+
+T-CONT
+  A transmission container: the entity the OLT grants upstream windows to,
+  named by an alloc-id the OLT assigns over PLOAM. Upstream bandwidth is
+  arbitrated between T-CONTs by the OLT and within one T-CONT by the ONU.
+
+GEM port
+  A flow, named by a GEM port id the OLT assigns over OMCI. Several GEM ports
+  ride one T-CONT. A GEM port id is a label in the frame header, not a
+  scheduling entity. G.9807.1 Table C.6.6 reserves 0 to 1020 for the default
+  GEM port (equal to the ONU-ID, OMCI only) and 65535 for the idle GEM port,
+  so the uapi takes only 1021 to 65534.
+
+One more object supports them:
+
+Classifier rule
+  What upstream traffic maps onto which GEM port, matched on VLAN tag state,
+  VLAN id, priority or DSCP.
+
+Activation
+==========
+
+An ONU reaches the operational state O5 through the PLOAM state machine of
+G.984.3 or G.9807.1: serial number exchange, ONU-ID assignment, ranging and
+finally O5, which is the only state in which the OMCI management channel
+carries traffic.
+
+**The state machine runs in the driver, not in the core.** That is a
+deliberate choice and the reason this subsystem has no software MAC layer.
+On the hardware it was written against, the key hierarchy of G.9807.1 clause
+C.15.3 runs inside the MAC's key generator and the OMCI integrity key never
+leaves it, so no generic layer can compute the OMCI message integrity check.
+A core that owned the state machine would be a core that could not finish the
+job.
+
+What the core owns instead is the vocabulary and the object model:
+
+* the ITU-T constants and message layouts, in ``include/net/pon/ploam.h``
+* the PLOAM message codec, which builds and parses standard message bodies and
+  holds no state, no timer and no policy
+* the objects above, which it stores
+* the activation state, which the driver reports and the core validates and
+  publishes
+* the network devices, their carrier and the OMCI channel
+* the netlink uapi
+
+The driver owns the state machine, its timers, the key hierarchy and every
+register.
+
+Why the core validates the state
+--------------------------------
+
+``ploam-ntf`` and the activation state in the netlink reply are uapi. If each
+driver published its own state, each vendor would invent its own notification
+timing and an OMCI daemon would behave differently per MAC. So the driver
+reports through ``pon_dev_state_report()`` and the core checks the transition
+against the state machine of the standard, publishes it and updates the
+carrier. An out of range value is refused. An illegal edge is published
+anyway and warned about: the hardware is the truth and a driver that reports
+something the standard does not permit is a bug to find, not a state to hide.
+
+Everything the uapi carries follows the ITU-T recommendations. Where a MAC
+deviates from them, its driver translates the hardware to the standard before
+it reports, as a quirk of that driver. The core and the uapi never carry a
+vendor state or a vendor meaning. The states are the union of G.984.3 and
+G.9807.1: G.9807.1 has one Serial Number state, O2-3 (Table C.12.1), which a
+driver reports as ``o2``. Only a G.984.3 device reports ``o3``.
+
+The core logs every edge it publishes at info level, one line per edge, for
+example ``pon0: PLOAM state O5 -> O6``. The log names the Serial Number state
+``O2-3`` in every mode but G-PON. A repeated report logs nothing. A work
+item outside the instance's context prints the line, so a slow console never
+delays the PLOAM exchange. A driver logs its own lines the same way through
+``pon_dev_log()``. All lines keep their order.
+
+Objects outlive the link
+========================
+
+A GEM port is OMCI configuration and the ONU keeps it when the link goes and
+a new activation starts: G.9807.1 clause C.6.1.5.8 has the ONU retain every
+XGEM port id the OMCI assigned when it enters O1 and discard only the default
+one that carries the OMCC. So the driver keeps its GEM ports across a loss of
+the link and the core keeps the objects, exactly as an address on an ethernet
+device outlives a cable pull. Nothing is handed back when the link returns,
+because nothing was taken away.
+
+What the ONU does discard are the alloc-ids (clause C.6.1.5.7). The OLT assigns
+them again over PLOAM once the ONU is back in O5 and the driver binds each one
+to a transmit channel and reports that to the core through
+``pon_dev_event()``. The default alloc-id, equal to the ONU-ID, is not assigned
+by a message. The driver binds it with the ONU-ID and it may carry user traffic
+as well as the OMCC. A GEM port whose
+alloc-id has no channel yet is held and carries no traffic. The carrier of the
+PON interfaces is up in O5 and O6 while at least one GEM port rides an alloc-id
+that has a channel and a conduit (see below) is paired with the device and up.
+The core follows the conduit with a netdev notifier: the carrier falls when the
+conduit starts to go down and when its driver takes it back.
+
+Classifier rules are objects of their own. In G.988 they come from their own
+managed entities, which reference a GEM port rather than belonging to it, so a
+rule outlives the GEM port it names, in the core and in the driver.
+
+The lent context
+================
+
+A PON MAC runs the activation state machine itself, but it must not run it in
+hard interrupt context and it must not run it against a half finished netlink
+transaction. The core therefore lends the driver its own serialized context:
+one ordered workqueue per instance and one lock that the netlink handlers
+take in their ``pre_doit``.
+
+A driver queues a ``pon_work`` from any context, hard interrupt included. The
+handler runs with the instance lock held, so it may sleep. One worker drains
+the list one item at a time, so the ordering a driver sees is the order it
+queued in.
+
+The OMCI channel
+================
+
+OMCI is the management protocol of G.988 and it is userspace's job. The kernel
+carries it over the netlink family, the way nl80211 carries management frames
+to hostapd. A daemon sends ``omci-register`` for a device and from then on
+receives every OMCI PDU of that device as an ``omci-ntf`` message, sent to
+its socket alone. It sends a PDU with ``omci-tx``. One socket owns the OMCI
+channel of a device at a time: another socket is refused with ``EBUSY`` and
+only the owner may send. The registration ends when the socket closes, so a
+daemon that restarts registers again and nothing is left behind.
+
+A PDU crosses the boundary bare, from the transaction correlation id to the
+end of the message contents, in both directions and in both the baseline and
+the extended format. It carries no integrity field, because the MAC computes
+the upstream one and checks the downstream one. A PDU is therefore at most
+1976 bytes: G.988 clause 11.2.5 limits an extended message to 1980 bytes
+and 4 of them are the integrity field.
+
+The downstream check works like a receive checksum offload. The MAC that
+checks the integrity field says so in its receive descriptor, per PDU and
+the core takes such a PDU as verified and stripped. A PDU the MAC passed up
+unchecked still ends with its integrity field, so the core accepts it up to
+1980 bytes and hands it to the driver's ``omci_verify``, which checks and
+strips the field. That check cannot be a generic helper of the core: the
+field is an AES-CMAC with the OMCI integrity key (G.9807.1 clause C.15.7.2) and
+the key belongs to the key hierarchy the driver runs. On some MACs it never
+leaves the key generator.
+
+No network device and no
+EtherType is involved: the OMCC carries the PDU on its own GEM port with no
+Ethernet header and the core knows that port, so there is nothing to
+classify.
+
+A received PDU waits in the instance's context until it reaches the owner. A
+PDU that finds no owner, a full queue or a full socket is dropped. The OLT
+retries. The exchange can be captured on an ``nlmon`` device like any other
+netlink traffic.
+
+No OMCI managed entity is modeled in the kernel. The daemon reads the OLT's
+intent from the MIB and expresses it through the netlink family below.
+
+The conduit
+===========
+
+A PON MAC on a system on chip has no DMA of its own: its frames ride the rings
+of an ethernet port of the same chip. That port is the conduit, in the sense
+DSA gives the word and its driver registers it with ``pon_conduit_register()``
+when the port's firmware node names the MAC through a ``pon-handle``
+reference. The core pairs the two by that node, in whichever order they
+probe and neither waits for the other.
+
+Per frame information crosses the boundary as explicit arguments and never in
+``skb->cb`` or in a frame tag. On transmit the MAC driver names the GEM port,
+the T-CONT channel, the queue and, for an OMCI PDU, the integrity key index
+and the conduit's driver builds its descriptor from them. On receive the
+conduit's driver reads the GEM port and the OMCI and integrity flags from its
+descriptor and hands the frame to ``pon_conduit_rx()``, which delivers it to
+the OMCI channel, to the GEM port's own network device when it has one, or to
+the PON data interface. The MAC driver verifies an OMCI PDU the hardware
+passed up unchecked through ``omci_verify``. Without that callback such a PDU
+is dropped. Such a PDU still carries its integrity field, so the core accepts
+it at up to 1980 bytes and the conduit's MTU never drops below that.
+
+The conduit keeps the address of the PON data interface, because the frame
+engine behind it recognizes the ONU's frames by the conduit's own address.
+The core sets it when the two are paired. When the data interface's address
+changes afterwards, the MAC driver calls ``pon_conduit_addr_set()`` from its
+``ndo_set_mac_address``.
+
+The conduit also takes the largest MTU among the PON network devices, because
+the frames of all of them ride its rings. The core sets it when the two are
+paired and when a GEM port's network device is created or changes its MTU. The
+MAC driver calls ``pon_conduit_mtu_set()`` from the ``ndo_change_mtu`` of the
+data interface. A change that the conduit's driver refuses is refused.
+
+Netlink interface
+=================
+
+The generic netlink family ``pon`` is specified in
+``Documentation/netlink/specs/pon.yaml`` and the uapi header is generated from
+it. Every object can be listed, watched and read back:
+
+=================  ==============================================
+``dev-get``        devices, with a dump
+``tcont-get``      T-CONTs, with a dump
+``gem-get``        GEM ports, with a dump
+``gem-map-get``    classifier rules, a dump
+=================  ==============================================
+
+Notifications share the reply format of the matching get, so a listener parses
+one message shape whether it asked for an object or was told about it. There
+is no sequence number: a listener that overruns its socket re-reads.
+``dev-del-ntf`` stands for the removal of every object of that device. The
+objects go without a notification of their own.
+
+The dumps of the T-CONTs, the GEM ports and the classifier rules take an
+optional device ID and then list the objects of that device only. A
+device ID that names no device ends the dump with ``-ENODEV``. A dump that
+does not fit one message resumes by count, so the kernel sets
+``NLM_F_DUMP_INTR`` when an object joined or left a list in between and the
+reader repeats the dump.
+
+``omci-register``, ``omci-tx`` and ``omci-ntf`` are the OMCI channel, described
+above. ``omci-ntf`` goes to the owner of the channel alone and to no
+multicast group.
+
+``ploam-ntf`` reports every activation transition.
+
+An operation is a ``set`` when it can change an object that already exists
+and a ``new`` when it can only create one. ``tcont-set`` rebinds a T-CONT,
+while ``gem-new`` and ``gem-map-new`` refuse an object that exists with other
+attributes.
+
+A GEM port reaches an alloc-id only through its T-CONT. ``tcont-set`` that
+changes the alloc-id moves the GEM ports of the T-CONT too. If the driver
+refuses one, the core restores the old alloc-id on the T-CONT and on its GEM
+ports and returns the error. ``tcont-del`` answers ``-EBUSY`` while a GEM port
+names the T-CONT, so userspace deletes the GEM ports first. ``tcont-set``
+answers ``-EEXIST`` for an alloc-id that another T-CONT holds: G.988 clause
+9.2.2 relates alloc-ids and T-CONTs one to one, so userspace that moves an
+alloc-id releases it first.
+
+``dev-set`` refuses to start the link until userspace gave the device a serial
+number. The driver carries no serial of its own, so an ONU that has not been
+provisioned stays silent rather than range under a vendor default.
+
+No key material crosses this interface in either direction. ``gem-new`` selects
+the key ring of each GEM port, as G.988 clause 9.2.3 defines it. The key
+ring alone decides whether a GEM port is encrypted and in which direction. The
+keys themselves are derived and rotated below. The broadcast key ring is
+refused, because the OLT distributes those keys over the OMCI and the kernel
+takes none.
+
+Internals
+=========
+
+The kernel-internal interfaces, pulled from the source.
+
+.. kernel-doc:: net/pon/pon_main.c
+   :doc: PON locking
+
+.. kernel-doc:: net/pon/pon_work.c
+   :doc: The lent context
+
+.. kernel-doc:: include/net/pon/ploam.h
+   :doc: The PLOAM vocabulary
+
+.. kernel-doc:: include/net/pon/ploam_msg.h
+   :doc: The PLOAM message codec
+
+.. kernel-doc:: include/net/pon/types.h
+   :internal:
+
+.. kernel-doc:: include/net/pon/functions.h
-- 
2.34.1

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

[Gaoyang Wei]

Hi John,

Your cover letter explicitly presents this series as following the
framework discussion I started. Yet neither Ziyou nor I was copied on
the cover letter or any of the twelve patches.

Given our participation in the original discussion and the cross-vendor
follow-up, both of us should have been copied. We find this omission
inappropriate.

I've added both of us to Cc. Please keep us copied on future revisions
and related framework discussions.

Gaoyang

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

[Andre Ziviani]

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

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

[John Crispin]

On 09.10.26 13:04, Andre Ziviani wrote:
> 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.
> 
[...]
> traces from both ISPs.
> 
> [1] https://github.com/AndreZiviani/odi-oss
> 
> Thanks,
> Andre Ziviani
> 


and those dongle can be bought on fs.com for ~12euro

I'll grab a couple. Thanks for the info !

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

[Stephan Pruecklmayer]

Hi all,

I appreciate to get a common structure for PON gateways, 
HGUs and SFUs in place. 
As mentioned in the other thread on this topic 
([RFC] net: towards a generic PON framework)
https://lore.kernel.org/all/785bffbc-b028-46dd-b3de-b95a28122258@gmail.com/

we from MaxLinear have also discussed and implemented an abstraction at 
the Linux kernel boundary layer to abstract hardware devices and the OMCI stack 
accordingly. For that reason we definitely endorse such endevor in principle
and we will further comment and reply on this mailing list.

Having said that, such implementation shall be an implementation for all 
people using Linux and PON and not only one specific company implementation
that is being pushed here. The required abstraction needs to support multiple
chipsets and their underlying architectures. Different chips may do certain things
already in hardware (example PLOAM) while others do it in software.
Or how the data is being transferred between driver and OMCI (Ethernet or 
something else).

Before nailing down such interface, this homework needs to be done. 
From MaxLinear side we will look into this and compare to whatever public
information on the interface for the proposed Airoha chip is available, but from
a very first glance it cannot  and will not work as is, but needs abstractions for 
several building blocks. 
Our experts will reach out in this mailing list concerning specific implementations 
and questions on this current proposal.


Stephan Pruecklmayer
MaxLinear
Senior Technical Director Strategic Marketing and Standards

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

[Stephan Pruecklmayer]

Apologize for the add-on - looping in my colleagues to the thread
tlanger@maxlinear.com
zdoychev@maxlinear.com