So a little update on my WIP branch, after shouting at myself trying to debug this for days, turns out, naming is hard 
anyway, I fixed it (was my own fault after-all) and I think it's in a pretty decent state right now, that I want to push it to my DEV branch soon. Networking still suffers from the same issues as before, so hopefully the other guys are getting closer on that
So now I can go back on debugging my new I2C driver that I was working on a few weeks ago.
Have any programmer tried making the Mode switch and act/poe mode led and poe/act status led array work as factory default on the dgs-1210 series poe switches?
Aren't these leds normally driven directly by the POE microcontroller?
As far as I know they are driven trough the normal LED array control IC’s (the 74HC14 chips if I remember the model number right) from the SoC and port expander and shifted between act/poe function with the mode button.
It is the two ACT orPoE led that show what the array are showing.
But default is act function on the array.
I really don't know much/anything about this, but could be that they are 'faking' some sort of networking mode. The switch is normally in control of the leds, or you can configure them as 'software controlled leds' actually. Once sander and christian are getting the led stuff merged, we should have similar ways to control this stuff. Though on our switches, it might be a little tricky to deal with some weird configurations that we have ...
Has anyone else noticed SNAPSHOT r22569-b8e1fcad38 restricts GS308T Gigabit ports to fast Ethernet speeds?
I can't pin down the exact commit, but this problem first started with a commit a week or two before r22569 (I flashed r22569 to see if it fixed it, and had flashed a prior SNAPSHOT a week or two before that introduced the problem).
My home network consists of a DOCSIS 3.0 modem (500/20 Mbps service) to an R4S (multiple vlans) to a GS308T (multiple trunked vlans), and from there to a couple wired back haul APs with Gigabit switch ports and a single hardwired Fast Ethernet client (security system). With all hardware running a commit from a week or two before r22569, I noticed my WiFi connections were limited to 93.x Mbps, then confirmed same speed on direct Ethernet connection to an AP switch. I flashed everything with r22569 - same problem.
Our neighborhood is being excavated to install fiber and there have been many service interruptions (electrical, cable, you name it they found the underground cables to dig through!) over the last few weeks, so at first I attributed the problem to that.
Before calling the cable company to "fix" my provisioning after the last service restoration, I set up a direct modem to thin client PC Ethernet connect just to be sure and - bang - speedtest clocked back in at a very respectable 570/23 Mbps.
My first debug step was to put 22.03.4 stable on the GS308T switch....and that fixed it. So something is definitely up with SNAPSHOT on the GS308T. As I type this, I realize I should probably have first tried unplugging the Fast Ethernet client from the GS308T first to see if that did it - water under the bridge.
I'm running out of ports on my 24-port switches so I bought a used and cheap HP 1920-48G (JG927A). Thanks to @janh's excellent work, the initramfs image booted immediately.
The three RTL8231 are in shift-register mode and the LEDs work OOTB - nothing to be done here.
As expected, the RTL8214FC PHY is misdetected so SFP cages won't work, a patch for the RTL8393 SoC is required.
@janh do you have any GPL code from HPE? At https://svanheule.net/switches/gpl_source_drops there is only a U-Boot for the 1910 series.
Are you using my hpe-1920-48g branch? It contains a commit that makes the SFP ports work on my HPE 1920-48G (at least it did the last time I tried). It's just not finished, and I don't know if it doesn't break other devices. (The branch also contains some unrelated stuff, only this commit and the one before and after it are relevant for 1920-48G / RTL8214FC.)
No, I don't have other source code for the HPE devices.
No, I didn't know this branch existed - I started based on the other HPE devices. But that still saves me a lot of work, I was missing most of the GPIOs, especially for the SFP ports.
I suppose you will carry on with this model once you find the time?
Speaking of SFP, I have another problem on the GS1900 devices (tested on GS1900-10HP and GS1900-24HPv2): I have several Netgear AGM734 SFP modules with Marvell 88E1111 PHY. Unfortunately, they are not detected properly, the kernel only reports "no PHY detected". A Digitus module with the same PHY works flawlessly. Any hints what I should check?
EDIT: This SFP module is detected properly and working fine with the HP firmware on the HPE 1920-48G.
EDIT2: I applied your patches for the RTL8214FC and it seems to be working, although the speed is reported as 100M (I didn't test the actual speed, but my notebook shows 1000M on the other end).
EDIT3: The PHY on the AGM734 seems to have address 0x53 instead of 0x56 - and this address it no probed by default.
Finishing RTL8214FC support doesn't have a high priority on my list of things to do (I don't actually have any need for it as I only use this device occasionally for testing). If you want to work on it yourself, feel free to do so.
Currently, I have several (unrelated) pending patches and started to work on fixing LAG support. But all those branches are getting annoying to handle (as they end up conflicting or depending on each other), and I moved to other things for now. (@svanheule: If you have some time, it would be great if you could review the already submitted patches!)
The link speed is just not reported correctly. That is a general issue with the RTL8214FC, I'm also seeing it on my HPE 1920-16G.
I had a look at your code - are you referring to the upload of the firmware to the PHY and some other initialization stuff that's done on the 8380 platform?
This PHY doesn't have high priority for me either (I only have copper SFP modules anyway), but if that's the reason why the 1920-48G is currently not supported, I'm willing to work on it.
RTL8214FC support is in my branch, birger did that a year? ago I think.
Yes that is mostly what is missing. But more importantly, I'm not really sure if my changes to rtl8218b_ext_match_phy_device and the MDIO stuff are really correct. These changes should definitely be tested on other devices to make sure they don't break anything.
For RTL838x devices, this PHY is already supported in upstream OpenWrt. But RTL839x is explicitly excluded in rtl8214fc_phy_probe. Do you actually have a branch that changes this?
I have no device (yet) in this config, so haven't looked at all of this at all.
OK, I can do some testing on RTL8382M switches with 24 ports (DGS-1201-28MP, GS1900-24E, T1600G-28TS). I do not have any other RTL839x switches, apart from a GS1920 where I'm currently trying to get U-Boot working (I got my first build booted today, but for now I completely replaced ZyXEL's BootBase).
I have a Trendnet TEG-S750 (RTL9303) on its way to me and am under the impression that this is also the right thread for this chipset. I'd appreciate any pointers to branches (this?) and instructions to get up and running with the most recent development branch for that chipset. I'll be happy to invest some time to figure that hardware out, but it is new ground for me. I was also curious how to coordinate with other ongoing work (and whether there's a better place than this very long thread).
I've spent some more time on this and managed to figure out the required hoops to build an image that the web interface will accept. I haven't manage to figure out how to talk to the SFP cage, but a 1000baseT SFP module works ok in it. PoE is working too.
The major problem is that if I don't do "rtk network on" in u-boot then there's no networking, which means you need to open up the device to be able to access the serial console and enable this in u-boot. I thought this was a problem that was only affecting the RTL93* series, not the RTL83*?
Does the Netgear source include the source to uboot? If so, then you would need to determine what 'rtk network on' is doing and then replicate it in the appropriate driver in linux.
By SMI mode you mean the I2C-like mode, right? The kernel has some support for this bus (drivers/net/dsa/realtek/realtek-smi.c), although I did modify the upstream code when testing my regmap RTL8231 driver in SMI mode. The driver required a bit of extra code in the MFD core, but other than that the regmap interface took care of the underlying difference. The driver in OpenWrt hard-codes MDIO access IIRC, so that may not be trivial to extend.
Any insights about SPI mode for rtl9301?
I'm currently stuck trying to talk to it over SPI via usermode