Hi, On Sun, 2021-12-26 at 20:41 +0200, Oskari Lemmela wrote: > RFC patchset because of following open questions: > > --- [...]
> POE driver is implemented as a kernel module. Every port is separate > hwmon device with same label as the DSA port. [...] > > Should this be implemented in Realtek POE switches as well? > > I haven't created any userspace tools for ubus integration yet > Because I'm not sure if this is the right way to go. > > The hwmon part should be upstremable. Only thing is two non-standard sysfs > controls (force_enable, port_state). They are also possible to implement > as debugfs files if they are not accepted by the upstream. A short general comment, as this would be at least the fourth way to manage PoE devices in OpenWrt (GPIO controlled, realtek poe tool, ubiquiti poe tool). So this is more related to how OpenWrt could interface with PoE hardware in a more generic way, rather than this specific implementation (and I'm certainly not asking you to rewrite anything, Oskari). For controlling the outputs of PoE PSE ports, I had actually been thinking of using the the regulator framework in some way. This could range from simple GPIO controlled PoE ports (fixed-regulator), to actual PoE-controllers with current limits (PoE, PoE+...) and overload detection. That way existing interfaces could be used to manage (regulator) and monitor (regulator or hwmon) the outputs. I fear that adding custom hwmon interfaces for every type of PoE PSE out there just won't scale very well. Not that I've ever actually worked with a regulator driver, so maybe I'm just talking nonsense. I would be happy to hear other opinions about this. :-) Best, Sander _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
