Re: [RFC PATCH 0/5] add support mikrotik routerboard hex poe
On 1/13/2022 9:46 AM, Oskari Lemmelä wrote: Hi, On 1/4/22 23:28, Sander Vanheule wrote: 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. I do not think the regulatory framework is the best for PoE control. It is more for displaying power dependencies and controlling power for power saving purposes. The best option could be to extend the netlink ethtool interface to support PoE standard data. This is quite similar to what SFP support has today. Ethtool is used to read EEPROM / FEC statistics and hwmon to display monitoring data. A GPIO controlled passive POE could only implement some parts of the ethtool netlink interface. IMHO, passive POE should never have been introduced, but I understand that the price of a product is more important than safety. Maybe getting feedback from the upstream Linux kernel maintainers would be a good way to move forward, assuming you would want these PoE drivers to land upstream as some point. From a quick look it seems to me that these PoE controllers should actually be modeled by a combination of regulator (for control) + hwmon (for reporting), possibly linked from a single parent device. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/5] add support mikrotik routerboard hex poe
Hi, On 1/4/22 23:28, Sander Vanheule wrote: 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. I do not think the regulatory framework is the best for PoE control. It is more for displaying power dependencies and controlling power for power saving purposes. The best option could be to extend the netlink ethtool interface to support PoE standard data. This is quite similar to what SFP support has today. Ethtool is used to read EEPROM / FEC statistics and hwmon to display monitoring data. A GPIO controlled passive POE could only implement some parts of the ethtool netlink interface. IMHO, passive POE should never have been introduced, but I understand that the price of a product is more important than safety. Oskari 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/5] add support mikrotik routerboard hex poe
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
