Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
Hi John, On 9/26/21 14:31, John Crispin wrote: On 26.09.21 13:34, David Bauer wrote: That being set, the goal of poemgr is not to replace the other efforts. I'm sorry if I caused this impression. it did not replace anything. I am fully with you on this one, realtek-poe took the same approach but merging it was NAK'ed with the argument, that we can only merge the ultimate solution. which is why till this day there is no upstream support for realtek. From my perspective, providing both for the time being via the packages feed (not preinstalled) is a good-enough solution. Otherwise, iterating over the project with multiple people starts to become difficult, as multiple forks (each fixing one issue / adding one feature) start to come up and bringing them together becomes harder and harder. Having it not in the core repository should indicate enough that it is not a definitive solution. Maybe I'm bringing up points which are already off the list, but at least i can try :) Best David John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
David Bauer writes: > That being set, the goal of poemgr is not to replace the other > efforts. I'm sorry if I caused this impression. Not my intention to complain at all. Just wanted those with a stake in this to be aware of your work. Thanks a lot for the efforts you have done to add complete support for this very interesting device. As well as many other devices. Connected to a Unifi 6 lite right now, so I do appreciate that work! And having these two implementations for widely different PoE systems is extremely useful for further "poe manager" design discussions. What I would want to avoid by posting is that we end up having two separate poe managers in OpenWrt (including "packages") forever... Which is how things look right now.. IMHO it would be better to combine them before mergin. Or at least agree on one of them as a basis for further developement and discussion, so we can avoid adding a userspace API which is doomed to go away soon. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 26.09.21 13:34, David Bauer wrote: That being set, the goal of poemgr is not to replace the other efforts. I'm sorry if I caused this impression. it did not replace anything. I am fully with you on this one, realtek-poe took the same approach but merging it was NAK'ed with the argument, that we can only merge the ultimate solution. which is why till this day there is no upstream support for realtek. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
Hi Bjorn, Hi John, On 9/26/21 10:43, Bjørn Mork wrote: John Crispin writes: poemgr does not use the APIs provided by libubox so I doubt that this will land in the tree. It's going through the packages repo according to https://github.com/openwrt/openwrt/commit/a9839697896c4fdf8c44a06bbce466ce52493069 The distinction is of little imprtance to the outside world. You will have poemgr in OpenWrt. poemgr is set to land in the packages feed. I don't have stakes in the realtek PoE business and poemgr is more or less the result of a weekend hacking around the specific device (USW-Lite). I didn't fully catch up what the ultimate goal around PoE support is, but having the ability to control the ports in the first place being it with a non-preinstalled tool from the packages repo is a good start where we can iterate upon and either integrate support for an additional PSE controller with it's quirks or aim for an extension of a kernel subsystem. That being set, the goal of poemgr is not to replace the other efforts. I'm sorry if I caused this impression. Best David Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
Raylynn Knight writes: > It’s not clear to me what OpenWrt supported device(s) the below poemgr > is meant for! The Ubiquiti USW-Flex. And maybe other devices. David will know. I just noticed it from the recent commit in master. Looks like a really nice little MT7621 device with 802.3af/at/bt in and 4 x 802.3af out. Obviously without much budget if powered by 802.3af, but that's still a docuemnted and supported configuration! > It might be helpful to compile a list of currently supported OpenWrt > devices that have PoE capability. Below would be my contribution of > OpenWrt supported devices that I know have PoE capability: > > Device > Processor PoE out > —— > D-Link DGS-1210-10P RTL8380M8x > 802.3af/at > develo WiFi pro 1750e QCA9558 1x 802.3af > MikroTik RB750P-PBr2 QCA9533 4x Passive PoE > MikroTik RB750UPr2 (hEX PoE lite)QCA9531 4x Passive PoE > MikroTik RB2011iL-IN AR9344 1x > Passive PoE > MikroTik RBcAPGi (cAP ac)IPQ4018 1x > Passive PoE > MikroTik RB962UiGS (hAP ac) QCA9558 1x Passive PoE > MikroTik RBmAP-2nD (wAP) QCA9531 1x Passive PoE > Netgear GS110TPP RTL8380M8x > 802.3af/at > Netgear GS310TPv1 RTL8380M8x > 802.3af/at > TP-Link TPE210AR9344 > 1x Passive PoE > TP-Link TEP510AR9350 > 1x Passive PoE > Ubiquiti EdgeRouter 6PCN7130 > 5x Passive PoE > Ubiquiti EdgeRouter X MT7621AT1x > Passive PoE > Ubiquiti EdgeRouter X SFP MT7621AT5x > Passive PoE > Ubiquiti ToughSwitch TS-5-POE AR7240 5x Passive PoE > Ubiquiti EdgePoint R6 MT7621AT5x > Passive PoE > ZyXEL GS1900-10HP RTL8380M8x > 802.3af/at > ZyXEL GS1900-8HP RTL8380M8x > 802.3af/at > ZyXEL GS1900-8HP RTL8380M > 8x802.3af/at > ZyXEL GS1900-24HP v2 RTL8382M24x 802.3af/at > > I actually have the D-Link switch, 1 of the Netgear switches, 4 of the > Ubiquiti devices and 2 of the ZyXEL switches. I also have additional > realtek based PoE switches I plan on submitting support for when I get > time. Great list! Can't add anything morte than the USW-Flex here. I only have two GS1900-10HP myself Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
John Crispin writes: > poemgr does not use the APIs provided by libubox so I doubt that this > will land in the tree. It's going through the packages repo according to https://github.com/openwrt/openwrt/commit/a9839697896c4fdf8c44a06bbce466ce52493069 The distinction is of little imprtance to the outside world. You will have poemgr in OpenWrt. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
poemgr does not use the APIs provided by libubox so I doubt that this will land in the tree. John On 26.09.21 07:22, Raylynn Knight wrote: It’s not clear to me what OpenWrt supported device(s) the below poemgr is meant for! It might be helpful to compile a list of currently supported OpenWrt devices that have PoE capability. Below would be my contribution of OpenWrt supported devices that I know have PoE capability: Device Processor PoE out —— D-Link DGS-1210-10P RTL8380M8x 802.3af/at develo WiFi pro 1750e QCA9558 1x 802.3af MikroTik RB750P-PBr2QCA9533 4x Passive PoE MikroTik RB750UPr2 (hEX PoE lite) QCA9531 4x Passive PoE MikroTik RB2011iL-INAR9344 1x Passive PoE MikroTik RBcAPGi (cAP ac) IPQ4018 1x Passive PoE MikroTik RB962UiGS (hAP ac) QCA9558 1x Passive PoE MikroTik RBmAP-2nD (wAP)QCA9531 1x Passive PoE Netgear GS110TPPRTL8380M8x 802.3af/at Netgear GS310TPv1 RTL8380M8x 802.3af/at TP-Link TPE210 AR9344 1x Passive PoE TP-Link TEP510 AR9350 1x Passive PoE Ubiquiti EdgeRouter 6P CN7130 5x Passive PoE Ubiquiti EdgeRouter X MT7621AT1x Passive PoE Ubiquiti EdgeRouter X SFP MT7621AT5x Passive PoE Ubiquiti ToughSwitch TS-5-POE AR7240 5x Passive PoE Ubiquiti EdgePoint R6 MT7621AT5x Passive PoE ZyXEL GS1900-10HP RTL8380M8x 802.3af/at ZyXEL GS1900-8HPRTL8380M8x 802.3af/at ZyXEL GS1900-8HPRTL8380M 8x802.3af/at ZyXEL GS1900-24HP v2RTL8382M24x 802.3af/at I actually have the D-Link switch, 1 of the Netgear switches, 4 of the Ubiquiti devices and 2 of the ZyXEL switches. I also have additional realtek based PoE switches I plan on submitting support for when I get time. Ray On Sep 25, 2021, at 6:01 PM, Bjørn Mork wrote: And then we had https://github.com/blocktrron/poemgr But without support for the MCU controlled broadcom PSE chips in the realtek target, and without ubus support. Time to consolidate some of this code? Or is poemgr the result of that, just not yet with those features implmented? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- It’s not clear to me what OpenWrt supported device(s) the below poemgr is meant for! It might be helpful to compile a list of currently supported OpenWrt devices that have PoE capability. Below would be my contribution of OpenWrt supported devices that I know have PoE capability: Device Processor PoE out —— D-Link DGS-1210-10P RTL8380M8x 802.3af/at develo WiFi pro 1750e QCA9558 1x 802.3af MikroTik RB750P-PBr2QCA9533 4x Passive PoE MikroTik RB750UPr2 (hEX PoE lite) QCA9531 4x Passive PoE MikroTik RB2011iL-INAR9344 1x Passive PoE MikroTik RBcAPGi (cAP ac) IPQ4018 1x Passive PoE MikroTik RB962UiGS (hAP ac) QCA9558 1x Passive PoE MikroTik RBmAP-2nD (wAP)QCA9531 1x Passive PoE Netgear GS110TPPRTL8380M8x 802.3af/at Netgear GS310TPv1 RTL8380M8x 802.3af/at TP-Link TPE210 AR9344 1x Passive PoE TP-Link TEP510 AR9350 1x Passive PoE Ubiquiti EdgeRouter 6P CN7130 5x Passive PoE Ubiquiti EdgeRouter X MT7621AT1x Passive PoE Ubiquiti EdgeRouter X SFP MT7621AT5x Passive PoE Ubiquiti ToughSwitch TS-5-POE AR7240 5x Passive PoE Ubiquiti EdgePoint R6 MT7621AT5x Passive PoE ZyXEL GS1900-10HP RTL8380M8x 802.3af/at ZyXEL GS1900-8HPRTL8380M8x 802.3af/at ZyXEL GS1900-8HPRTL8380M 8x802.3af/at ZyXEL GS1900-24HP v2RTL8382M24x 802.3af/at I actually have the D-Link switch, 1 of the Netgear switches, 4 of the Ubiquiti devices and 2 of the ZyXEL switches. I also have additional realtek based PoE switches I plan on submitting support for when I get time. Ray > On Sep 25, 2021, at 6:01 PM, Bjørn Mork wrote: > > And then we had https://github.com/blocktrron/poemgr > > But without support for the MCU controlled broadcom PSE chips in the > realtek target, and without ubus support. > > Time to consolidate some of this code? Or is poemgr the result of that, > just not yet with those features implmented? > > > Bjørn > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: Message signed with OpenPGP --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
And then we had https://github.com/blocktrron/poemgr But without support for the MCU controlled broadcom PSE chips in the realtek target, and without ubus support. Time to consolidate some of this code? Or is poemgr the result of that, just not yet with those features implmented? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
Hello John,
Thank you for the rather useful tool. One comment below.
On Tue, May 11, 2021 at 05:22:43PM +0200, John Crispin wrote:
> +/* 0x17 - Set power management mode
> + * 0: None (No Power Management mode) (Default in Semi-Auto mode)
> + * 1: Static Power Management with Port Priority(Default in Automode)
> + * 2: Dynamic Power Management with Port Priority
> + * 3: Static Power Management without Port Priority
> + * 4: Dynamic Power Management without Port Priority
> + */
> +static int
> +poe_cmd_power_mgmt_mode(unsigned char mode)
> +{
> + unsigned char cmd[] = { 0x18, 0x00, mode };
Typo in command number here.
Because of it on D-Link DGS-1210-10P R1 with
"firmware": "v24.33",
"mcu": "Nuvoton M05xx LAN Microcontroller",
the power is never provided, the port status changes between "unknown"
(6):
RX -> 0x2a 0x63 0x00 0x11 0xb6 0x11 0x11 0x11 0x11 0x11 0x11 0xba
and "Searching" (1) when I plug and unplug the cable.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.2021 19:54, John Crispin wrote: On 11.05.21 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. lulz, why so aggravated ... its about the code not the person ... possibly I missed some of your feedback, will review tomorrow, keep the spirit mate and just chill a little ... Apparently I've used too strong words, I'm sorry for that, that was unintentional. I was trying to provide strong arguments and f*kup example in a good faith, but as I understand it, it sounded rude. I'd like to help adding PoE support in a clean way from the beginning, I'll come with some ideas and maybe a code later this week. Please hold on a bit with commiting this code, I hope we can refactor it a bit in a reasonable time. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
John Crispin [2021-05-11 19:43:09]: > that being said, I have a edgerouter-x(-sfp) on my desk. I already started a > PoC patch to support a more generic approach for PoE that is agnostic of > wheter the HW support is driven via GPIO or a ttyS attached MCU. Then you should consider renaming it to something generic as well, upoe(d) or such. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
John Crispin [2021-05-11 17:22:43]:
Hi,
> package/network/config/realtek-poe/src/main.c | 844 ++
I would prefer to have this as out of tree project, so we could add CI
pipeline to it for improved QA.
> +struct port_config {
> + char name[16];
It would be nice to get rid of all those magic numbers as well, there is a lot
of them.
Ideally the command bytes offsets should be defined (via some enum?) as well,
so it's easier to review the code otherwise one would need to keep in head,
that byte 11 is CRC etc.
> + fprintf(stderr, "%s ->", type);
> + for (i = 0; i < 12; i++)
> + fprintf(stderr, " 0x%02x", data[i]);
> + fprintf(stderr, "\n");
ULOG_DBG ?
> + config.port_count = reply[3];
this should be checked for > MAX_PORT
> + state.ports[reply[2]].poe_mode = GET_STR(reply[3], mode);
reply[2] should be checked for > MAX_PORT
> + for (i = 0; i < 8; i++)
i < MAX_PORT
> + state.ports[reply[2]].watt = watt;
reply[2] should be checked for > MAX_PORT
> + if (ret)
> + fprintf(stderr, "Failed to add object: %s\n",
> ubus_strerror(ret));
ULOG_ERR ?
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
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
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 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. lulz, why so aggravated ... its about the code not the person ... possibly I missed some of your feedback, will review tomorrow, keep the spirit mate and just chill a little ... John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
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. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.2021 19:38, John Crispin wrote: On 11.05.21 19:34, Rafał Miłecki wrote: I'm happy to see C code, but this implementation still doesn't address any of my comments I posted in the Re: [PATCH v2] rtl83xx-poe: add package https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 I strongly believe we need a more generic solution. A tiny framework with generic PoE imlementation and then rtl83xx support on top of that. agreed, but for now this makes PoE work for the community. the next step will be to move this into kernel space using the appropriate subsystems, however that will take time and effort. the aim of the patch is to get support functional out of the box for the community and then address the real solution afterwards. This never works. When we commit hacks like this to the repo they stay for years or for ever. Once you commit this we'll see uci defaults for PoE. Then LuCI module. Cleaning that up later will require a lot more planning to avoid breaking existing setups. Developing this as a tiny subsystem really won't take much more time. How much can it be? Two days? 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 19:38, John Crispin wrote: On 11.05.21 19:34, Rafał Miłecki wrote: I'm happy to see C code, but this implementation still doesn't address any of my comments I posted in the Re: [PATCH v2] rtl83xx-poe: add package https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 I strongly believe we need a more generic solution. A tiny framework with generic PoE imlementation and then rtl83xx support on top of that. agreed, but for now this makes PoE work for the community. the next step will be to move this into kernel space using the appropriate subsystems, however that will take time and effort. the aim of the patch is to get support functional out of the box for the community and then address the real solution afterwards. John that being said, I have a edgerouter-x(-sfp) on my desk. I already started a PoC patch to support a more generic approach for PoE that is agnostic of wheter the HW support is driven via GPIO or a ttyS attached MCU. but as I said, takes time and effort. for now, the RTL crowd will have PoE and 1-2 months down the line we will have a more generic approach... any other PoE capable HW around that we need to consider in the design phase ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 19:34, Rafał Miłecki wrote: I'm happy to see C code, but this implementation still doesn't address any of my comments I posted in the Re: [PATCH v2] rtl83xx-poe: add package https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 I strongly believe we need a more generic solution. A tiny framework with generic PoE imlementation and then rtl83xx support on top of that. agreed, but for now this makes PoE work for the community. the next step will be to move this into kernel space using the appropriate subsystems, however that will take time and effort. the aim of the patch is to get support functional out of the box for the community and then address the real solution afterwards. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.21 17:56, Bjørn Mork wrote: Tested-by: Bjørn Mork Running on a ZyXEL GS1900-10HP: thanks for testing. I just found 2 tiny issues that I already fixed locally and added a uci-defaults script s.T. we can setup a sane default uci for the various switches. If there are no further comments, I will merge this in the next couple of days John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
On 11.05.2021 17:22, John Crispin wrote:
This patch adds a C rewrite of the LUA tool previously posted. With this new
daemon we map the DSA port names to the PSE port id. Support for several now
features was added, such as setting the priority and at/af mode. In the next
iteration addition port/mcu states will be exposed, aswell as adding support
for 4 wire mode and fault handling.
A Sample config looks like this:
config global
option budget '65'
config port
option enable '1'
option id '1'
option name 'lan1'
option poe_plus '1'
option priority '2'
ubus call poe info
{
"firmware": "v48.2",
"mcu": "Nuvoton M05xx LAN Microcontroller",
"budget": 65.00,
"consumption": 2.40,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE",
"status": "Delivering power",
"consumption": 2.40
}
}
}
I'm happy to see C code, but this implementation still doesn't address
any of my comments I posted in the
Re: [PATCH v2] rtl83xx-poe: add package
https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485
I strongly believe we need a more generic solution. A tiny framework
with generic PoE imlementation and then rtl83xx support on top of that.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
John Crispin writes:
> This patch adds a C rewrite of the LUA tool previously posted. With this new
> daemon we map the DSA port names to the PSE port id. Support for several now
> features was added, such as setting the priority and at/af mode. In the next
> iteration addition port/mcu states will be exposed, aswell as adding support
> for 4 wire mode and fault handling.
>
> A Sample config looks like this:
>
> config global
> option budget '65'
>
> config port
> option enable '1'
> option id '1'
> option name 'lan1'
> option poe_plus '1'
> option priority '2'
>
> ubus call poe info
> {
> "firmware": "v48.2",
> "mcu": "Nuvoton M05xx LAN Microcontroller",
> "budget": 65.00,
> "consumption": 2.40,
> "ports": {
> "lan1": {
> "priority": 2,
> "mode": "PoE",
> "status": "Delivering power",
> "consumption": 2.40
> }
> }
> }
Tested-by: Bjørn Mork
Running on a ZyXEL GS1900-10HP:
root@gs1900-10hp:~# ubus call poe info
{
"firmware": "v22.4",
"mcu": "ST Micro ST32F100 Microcontroller",
"budget": 77.00,
"consumption": 7.70,
"ports": {
"lan1": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan2": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan3": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan4": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan5": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan6": {
"priority": 0,
"mode": "PoE+",
"status": "Searching"
},
"lan7": {
"priority": 0,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.90
},
"lan8": {
"priority": 0,
"mode": "PoE+",
"status": "Delivering power",
"consumption": 3.80
}
}
}
Really nice stuff!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
