The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
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.
--- End Message ---
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
