[PATCH 2/2] realtek: add support for HPE 1920-24G-PoE-370w

[Tim Small]

Hi Evan,

On 19/09/2024 01:36, Evan Jobling wrote:

> I don't have a JG925A to test so I wasn't game to submit for that.
> Everything else looks similar which is nice.

So far as I know everything is the same except the power supply module. 
There were a couple of users willing to test here:

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2670

> So your feedback here is to get this merged, I should change the fan control into the DTS as you have done?

I think that seems best to me - the kernel has a thermal management 
subsystem and future enhancements could use this for fan control by 
implementing the same algorithm as the OEM firmware.

> I was also unaware that there was another GPIO for fan failure so that's great news.

It looked like the OEM firmware could be made aware of this, so I just 
found this by trial and error.  Safest way to provoke this during test 
is to poke something soft and non-conductive (e.g. plastic foam) in 
through the fan grille to temporarily stop one fan.


>> The best policy is unfortunately probably to run the fans at full speed by default.
> 
> I guess then we should also submit a patch so the default for the JG922A is also max?
> Then the user can elect to turn down the fans?

Yes, I think that's the case.  The OEM firmware setup is that during boot:

Initially fan speed is set to high (by uboot and/or OEM kernel - can't 
remember exactly)

. OEM user space manages fan speed based on some unknown algorithm 
(presumably by the "FanT" user space process, which isn't present on the 
very similar fanless JG924A).

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2668

The behaviour of the in-kernel gpio fan speed controller is to leave the 
fan speed as it was when the driver loaded (e.g. to inherit hardware 
default speed, or the speed which was set by the bootloader etc.). 
IIRC, the OpenWRT kernel resets the GPIO state at init time, so the fan 
speed is set to low - which is "wrong".  One approach would be some sort 
of addition to the patch set to change that (either to force it back 
high again, or to retain the pre-boot settings), but I didn't have time 
to look at that, and then life got in the way as usual...

The SoC does have a temperature sensor built-in, but the driver is 
incomplete and not upstreamed.

Also relevant:

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2676

and:

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2679

https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2680

... and a few other posts around that time in that thread.

Cheers,

Tim.