Generic Linux PON framework RFC - looking for cross-vendor input

[John Crispin]

well. I guess that ship sailed ... 

I'll post https://github.com/blogic/linux/commits/main/ as a RFC within the next two days

for context --> https://lore.kernel.org/all/0077ab02-2215-4015-9e74-eeb8c3de6b14@phrozen.org/



On 03.10.26 19:45, Ziyou Xu wrote:
> Hi,
> 
> We recently started an RFC discussion on netdev about whether Linux
> needs a small generic framework for PON devices:
> 
>   [RFC] net: towards a generic PON framework
>   https://lore.kernel.org/netdev/20260926174601.1675-1-yhyxwgy@gmail.com/
> 
> The discussion started from existing work on Airoha AN7581/AN7583.
> That implementation already has working PON MAC/activation support,
> OMCI transport, GEM/T-CONT handling and an Ethernet datapath:
> 
>   https://github.com/pbs05/openwrt-pon-drivers
>   https://github.com/pbs05/openwrt-pon-userspace
> 
> There is also ongoing OpenWrt work for older EcoNet/Airoha PON
> hardware:
> 
>   https://github.com/openwrt/openwrt/pull/20104
> 
> The goal of the RFC is not to turn the current Airoha API into a
> generic Linux API.
> 
> We are instead trying to determine which concepts, if any, are common
> between different PON implementations before one vendor's model gets
> frozen into a userspace ABI.
> 
> Some of the questions currently being discussed are:
> 
>   - whether Linux needs a common PON device/line object;
>   - how Ethernet service netdevs relate to GEM/LLID bearers;
>   - where the boundary between TC/VLAN classification and PON bearer
>     mapping should be;
>   - how raw OMCI PDUs should cross the kernel/userspace boundary;
>   - which GEM/T-CONT/LLID state belongs in generic code versus a
>     hardware driver;
>   - how activation/PLOAM/MPCP state should be exposed;
>   - how fixed PON optics should interact with PHY, hwmon and NVMEM.
> 
> The discussion has already shown that different working implementations make different choices about OMCI, activation and optical control, which is why another hardware family would be useful.
> 
> We would especially like to hear from people working on Realtek,
> Lantiq/Intel/MaxLinear, Broadcom, or any other PON-capable SoCs.
> 
> Even a partially working port is useful. In particular, information
> about how another PON MAC represents GEM/T-CONT/LLID resources,
> service classification, OMCI transport and activation state would help
> us identify which parts of the current Airoha designs are actually
> generic and which are hardware-specific.
> 
> If you are working on xPON support in OpenWrt or Linux, please take a
> look at the RFC and join the discussion on netdev. Replies here
> pointing to existing code, vendor-open source trees or work-in-progress
> ports would also be very useful.
> 
> Thanks,
> Ziyou Xu
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel