Netgear GS310TP GPIOs

For Developers
1

Continuing the discussion from Support for RTL838x based managed switches.

As reported by @ListerWRT, current main does not properly enable the PoE outputs. It was found that the GS110TPP uses gpio10 on the RTL8231 as a gpio-enable line. It would be good if somebody could test this on the GS310TP as well, to verify it is the same line there.

@RaylynnKnight, you wrote the initial support for this device, so maybe you have time to test this as well?

I also noticed there are no other GPIO definitions for the GS310TP for the front panel LEDs or the SFP cages. It would be good if these could also be determined and added to the devicetree.

2

If you can describe how to do it, I'm happy to test this.

I know how to use the build system but not much beyond that.

3

As described earlier, you can just change the GPIO lines of the RTL8231 to input one-by-one. Or just test line 10 first.

Go to /sys/class/gpio and check that gpiochip536 points to the RTL8231 (ls -l should make this clear). To export for example gpio10 on the RTL8231, you can then run (536 + 10 = 546):

echo 546 > export
cat gpio546/direction # most likely "out"
echo in > gpio546/direction # change to input, the old behaviour

Wait a few seconds and your PoE device(s) should be powered again if you found the correct GPIO.

1 Like
4

I won't have time to look at this until this coming weekend. However the reason the SFP cages were not originally implemented was that according to the output of vendor board configuration some of the GPIOs appeared to be used for multiple functions. See the output on https://svanheule.net/switches/gs310tp#vendor_board_definition where it appears the GPIO EXT_36 and EXT_28 are used for multiple functions.

5

I've seen that board definition too. It seems bonkers to me as well... Perhaps that's just the main configuration state, but the vendors sometimes do GPIO changes outside of the central board/GPIO config.

6

I would like to backport the RTL8231 changes to 24.10, but unless I get some feedback on these GPIOs (or a patch) the PoE-regression will be included.

7

I'm having trouble locating my GS310TP. I have a storage room I will need to dig through to find it and that likely won't occur until early March!

8

@svanheule mine is currently running two APs so it's difficult to find time to test. I have a few hours tomorrow, I'll try to get it done

9

@svanheule confirmed, it is gpio10. PoE devices all getting power and the port LEDs turned on.

BusyBox v1.37.0 (2025-02-21 09:44:42 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt SNAPSHOT, r28869-6936deac67
 -----------------------------------------------------
root@***:~# cd /sys/class/gpio
root@***:/sys/class/gpio# ls -l
--w-------    1 root     root          4096 Jan  1  1970 export
lrwxrwxrwx    1 root     root             0 Jan  1  1970 gpiochip512 -> ../../devices/platform/soc/18003500.gpio-controller/gpio/gpiochip512
lrwxrwxrwx    1 root     root             0 Jan  1  1970 gpiochip536 -> ../../devices/platform/1b000000.switchcore/1b000000.switchcore:mdio-aux/mdio_bus/realtek-aux-mdio/realtek-aux-mdio:1f/gpio/gpiochip536
--w-------    1 root     root          4096 Jan  1  1970 unexport
root@***:/sys/class/gpio# echo 546 > export
root@***:/sys/class/gpio# cat gpio546/direction
out
root@***:/sys/class/gpio# echo in > gpio546/direction
1 Like
10

Thanks for checking! I'll create a patch for main and backport it to 24.10 with the rest of the RTL8231 changes.

2 Likes
11

Power LED is identical to GS308T (run-tested against 24.10.0).

Patch 
--- a/target/linux/realtek/dts/rtl8380_netgear_gs310tp-v1.dts
+++ b/target/linux/realtek/dts/rtl8380_netgear_gs310tp-v1.dts
@@ -2,10 +2,36 @@
 
 #include "rtl8380_netgear_gigabit.dtsi"
 
+#include <dt-bindings/leds/common.h>
+
 / {
 	compatible = "netgear,gs310tp-v1", "realtek,rtl838x-soc";
 	model = "Netgear GS310TP v1";
 
+	aliases {
+		led-boot = &led_power_green;
+		led-failsafe = &led_power_amber;
+		led-running = &led_power_green;
+		led-upgrade = &led_power_amber;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led_power_amber: led-0 {
+			label = "amber:power";
+			color = <LED_COLOR_ID_AMBER>;
+			function = LED_FUNCTION_POWER;
+			gpios = <&gpio1 32 GPIO_ACTIVE_LOW>;
+		};
+
+		led_power_green: led-1 {
+			label = "green:power";
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_POWER;
+			gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
+		};
+	};
 };
 
 &gpio1 {
12

Could you submit this patch as a pull request (or send to the mailing list)?

13

I could create a PR, but it won't be accepted, because I'm not going to add my real name or email address to the From: and SoB: tags. So I wonder whether it'd be of any use or it's better you commit it directly.

15

If color/function is defined for LEDs then label is redundant.
Please remove label = "amber:power"; and label = "green:power"; from file rtl8380_netgear_gs310tp-v1.dts.

16

Right, that was an oversight on my end.

FWIW OpenWrt still contains about 3000 of these labels. Most using functions that aren't in the LED binding, but not all were (automatically) converted. The function property is just a string though, so we're could use arbitrary functions downstream.

17

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.