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

[Florian Fainelli]

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