[PATCH] realtek-poe: add support for PoE on Realtek switches

Birger Koblitz mail at birger-koblitz.de
Tue May 11 12:06:34 PDT 2021

On 11/05/2021 19:51, Rafał Miłecki wrote:
> On 11.05.2021 19:46, John Crispin wrote:
>> On 11.05.21 19:45, Rafał Miłecki wrote:
>>> I'm really tired of dealing with such hacky solutions. Look at netifd,
>>> DSA and LuCI as example. We ended up with something that noone fully
>>> understands. Jo - our UI guru - couldn't deal with designing a proper
>>> UI for that f*cked config syntax. 
>> sorry mate, I am not the reason you are having a bad day, so dont vent it out on me.
> It's just an example of shitty situation we got. Nothing more.
> I took a good amount of time to provide valuable review for the
> [PATCH v2] rtl83xx-poe: add package
> I described problems, missing parts, provided examples how one can
> solve it. Let's discuss that please. Instead of commenting on one
> example I provided.
I think the growing RTL83xx crowd has shown that we are able to refactor
code and strive for the good stuff, see all the drivers that are now
getting into mainline. I also don't think we are getting into any kind
of cul-de-sac we cannot get out, because also other platforms will make
use of the uart-based interface these PoE chips offer, so I do not see
that there would be any need for major re-designs, and in particular no
need to implement this in kernel space. If for some reasons there are
PoE solutions that have a similar command-set but different (GPIO) interface
then if necessary this could be handled by a separate kernel module
that would offer a uart interface for the user-space. Alternatively
we go to a different user-space interface altogether, but it is clear
a user-space solution which talks PoE commands will be needed.


More information about the openwrt-devel mailing list