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

[Oskari Lemmelä]

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 at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>