I just pushed my support branch from a few months ago. Looks like I intended to submit two patches: One for the device and one for the PHYs. The one for the device should still apply with only little changes, but the PHY patch needs more attention.
Both are clearly based on @janh's excellent work on the HPE series, I just made a few small changes to the PHY code.
I'm pretty sure I won't have much time to work on this for the next weeks, feel free to port this forward.
Needs to be entered as a PR to get merged into master, then it will be available as a SNAPSHOT build.
I'll try testing this now, been a busy few days but should have more time soon.
I also cherry-picked that commit onto 23.05.3 and it works fine, running it right now.
EDIT2 - 23.05.3 has been running without glitches for a day and VLAN mapping is working as well as LLDP using the updated LLDP package from master.
Only artifact visible is that phantom link status on port lan50 which claims to be up but is not connected, guess it's due to SFP driver issues.
Overall happy with the switch and the ~23MB of overlay space is a relief compared to the situation on the Zyxel GS1900-48.
Sure - just keep in mind that my commit is mostly (or even entirely?) @janh's version without proper credit. Please make sure to credit him for his work.
While testing this patch, I noticed an unrelated issue in current main branch: Untagged ports with a VLAN other than 1 can't communicate with the CPU.
It looks like this is a regression caused by pull request Fix rtl930x VLAN, LEDs and status (#14221). The two commits "rtl83xx: dsa: Do nothing when vid 0" and "rtl83xx: dsa: reset PVID to 1 instead of 0" appeared to me like the most likely culprits, and a quick test has confirmed that.
The issue occurs on RTL838x and RTL839x. Has anyone else seen this? Does it also happen on RTL93xx (which seems to have been the primary target of this pull request)?
Yes, I had noticed that too, thanks for bringing that up. I have seen that on (at least) gs1900-8POE and GS110TPP.
Thanks a lot too for finding the time to also dig up the reason. That commit being tagged RTL93XX probably was the reason I did not spot it the quick look when I noticed the issue a month after the patch when master was at r0-5e395f0c2.
Because I stopped making new builds at that point for realteks, I'm a bit out the loop w.r.t kernel dev:
Is the status of kernel-version 6.1. still "Boots, but no ethernet"?
And what about 6.6? realtek seems to be last of the targets in use here still stuck on 5.15.
Have you checked that you actually only get 10 Mbit/s? The link speed is not reported correctly for the SFP ports on this device. In my case it is reported as 100 Mbit/s with a fiber SFP module, but the link is actually running at full Gigabit speed.
However, there was some discussion in this thread about DAC cables not being fully supported. But it is also possible that things are different for these devices, as the SFP ports are connected to a RTL8214FC PHY instead of the internal SerDes of the SoC.
For manual configuration you could try using ethtool.