[RFC PATCH 0/5] add support mikrotik routerboard hex poe

[Sander Vanheule]

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