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
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
