Turris Omnia pins a Luleey LL-XS2510 XPON stick to 1000baseX and ethtool never offers 2.5G

Post the full ethtool eth2 output and the sfp lines from dmesg, not only the link message. The interesting part is what the host decided the module is capable of: if phylink settled on inband/1000base-x, it took that from the module's own EEPROM, and nothing you configure on the router will add a mode the driver never saw.

The cage on the Omnia is fine up to 2.5G, so the hardware is not what is limiting you here. Also say whether anything changed on the host recently, an image upgrade included.

dmesg, identical on every boot:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full

ethtool eth2 gives 1000baseX/Full as both the supported and the advertised set, and Link detected: yes at 1000Mb/s full duplex. Nothing above 1G appears anywhree in the output.

flash set LAN_SDS_MODE 6 on the stick does go through and survives a reboot of the module, but the host side does not react to it at all: same message, same 1G. The router has been on this image since the stick went in, so there is nothing to roll back to.

That is the host taking the module at its word. The sfp driver reads the EEPROM, ses a part that declares 1000base-x, and pins eth2 to inband/1000base-x; phylink then has no 2.5G mode to offer, which is exactly the ethtool output you posetd. What you set inside the RTL960x with LAN_SDS_MODE touches the module's own serdes, not what it advertises to the router, so it was never going to change the negotiated mode.

Two ways out, and I only know of these two. Either rewrite the module EEPROM so it advertises 2.5G, which is the known trick on the DFP-34X-2C3, but yours is a 2C2 and I would not assume the same offsets. Or patch the host: add a quirk for this module in sfp.c and run a kernel with it, leaving the stick untouched.

On balance I would patch the host. A bricked EEPROM in a stick you cannot easily reflash is a much worse afternoon than a kernel you can roll back.

Another reason to keep the host under suspicino rather than the module. On OpenWrt snapshots there was a spell when the backported generic phylink validate code broke the Omnia SFP cage outright: ethtool still advertised 2500baseX/Full and the port just reported Link detected: no. It bisected cleanly to that kernel commit, dropping the backport brought the link back at 2500Mb/s full duplex, and a follow-up fix closed it.

Different symptom from yours, same lesson. On mvneta and phylink boards the host software decides what the cage is allowed to do, and it pays to keep a known-good image to fall back to before you start building your own.

If you do go the custom kernel route on Turris OS, take a snapshot first: schnapps create "Before new kernel", then opkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipk and reboot. If the kernel misbehaves you roll back instead of taking the router apart.

The second thing nobody mentions until afterwards: a 2.5 Gbps link is not 2.5 Gbps of traffic. The Armada CPU in the Omnia will not push that on a single queue, so plan on packet steering and RPS tuning before the number on the wire turns into throughput.

Unrelated trrap for anyone else reading this with a different stick: some PON modules run their own operating system and need roughly a minute before they answer at all, so on a cold boot the router probes the cage too early and falls back to the copper magnetics. fw_setenv bootdelay 60 in U-Boot is the usual cure. Not your case, since your module is detected straiight away.

Closing the loop: the patched host won. Built a kernel with the modified sfp.c, took the schnapps snapshot first, installed the ipk with --force-reinstall and rebooted. ethtool eth2 now lists 2500baseX/Full and the link comes up at 2.5 Gbps.

Nothing was done to the module in the end. LAN_SDS_MODE stayed where it was and turned out to be irrelevant, so I never had to touch the EEPROM.

Throughput needed the second piece of advice as well. Straight after the reboot the box sat well under the link rate on a single queue; with packet steering tuned the WAN finally does what the stick was bought for.