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 ---Thanks for your response Tim! >> I don't have a JG925A to test so I wasn't game to submit for that. >> Everything else looks similar which is nice. Thanks for providing the context. If we ever get to the stage where the patch set is looking good I guess i can reach out. > > 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've put my patches in patchwork as "changes requested" and will be working on another set. Similarly I've started work on updating JG922A and getting that with gpio-fan driver. > >> 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. Confirmed and checked that JG922A also has the same functionality. I used a paperclip but foam is a good idea. Fan datasheet for JG922A says 8200rpm max. Haven't estimated the low speed RPM. > > >>> The best policy is unfortunately probably to run the fans at full speed by >>> default. I've also looked and the 48G model also just got merged, but I didn't see any fan control stuff there? the 48G-PoE model (jg928a) appears to have two fan levels per HPE documentation. The non poe one (jg927a) says it has one fan loudness (i.e. speed). > > Initially fan speed is set to high (by uboot and/or OEM kernel - can't > remember exactly) uboot does it from what I understand. > 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... I had a look into this on JG922A today. I can set the fans to max on initialisation of RTL8231 using gpio-hog. But it not only is setting initalisation, it also 'hogs' it per description. So that basically locks out gpio-fan or userspace setting it. I don't think there's currently a method in openwrt to set fan speed without writing your own fan_ctrl script like on one of the d-link switches, or doing the control in the device tree thermal section? I don't know the best way to set /sys/class/hwmon/hwmon0/pwm1_enable and then /sys/class/hwmon/hwmon0/pwm1 to 1 at boot. I'm thinking duplicate something like /etc/init.d/gpio_switch but for various hwmon devices? That sounds like lots of work =( I had a look at what fancontrol and pwmconfig did ( lm-sensors ?) They require a temperature sensor and aren't in openwrt yet anyway. > > The SoC does have a temperature sensor built-in, but the driver is incomplete > and not upstreamed. So we can set the fan speeds by thermal, if we can get that upstreamed? Or per Bjørn's patch and keep it in OpenWrt? I don't understand how much "Further work" is required there. Whilst I can code in C. My kernel device driver experience approximates zero. I can try to build it and get closed loop fan control working. I haven't figured out whether a fan alarm can be part of the thermal control scheme in device tree to set the fan state. The scope creep here is getting a little much for me if I need to get closed or open loop fan control working in a short time frame. JG922A and JG928A got accepted without max fans by default? So I hope moving to hwmon and gpio-fan is sufficient? Then of course update the wiki on how to control/slow down fans, leave it up to user? As I'm going to be operating in hot environments with large PoE loads. I am also eager to have some sort of algorithm implemented. But I'd like to put that as "future work"? I've had thoughts regarding what fan control algorithm to use. (Without attempting to reverse engineer what factory did, or do my own thermal characterisation of the power supply and PSE controller FET's) I'm thinking "just max the fans" if sourcing more than 65W, fan failure, or CPU temp gets too high. Further reasoning/notes on thermal load: 65W passive was deemed acceptable by factory for JG921A. JG922A is same except for 180W PSU. So 65W passive is fine per set of 8 ports. So if sourcing >65W is an unknown, max the fans? (I know that even minimal airflow is much more efficient than convection cooling, so the set point for should be higher but eh) For JG925A, we have three sets of 8. Theoretically if we distribute evenly the PoE load we probably don't have an issue at stock as it is <65W per set of 8? We could have 180W through a one set of 8 ports, which would be a "Max the fans" scenario. Still safest would be sourcing >65W max the fans. For JG926A/JG928A we have an EPS port so we can have significant thermal load. We could end up with internal PSU sourcing 370W and the EPS providing another ~400? We can end up in a situation where we have 240W through a set of 8 ports.
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
