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.
Birger
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
