package: add new poe-common package

[howels]

Appeared in a post by @svanheule on the mailing list in January after a thorough discussion in Hurricos/realtek-poe#31 (comment) but was not actioned. I believe this is still a valid concern and should be addressed. Currently PoE devices do not honour configuration in board.json and this should rectify that.

Note - this code is purely the work of Sander and I am merely reproducing the code here for discussion. I feel this merits discussion as we currently lack appropriate PoE config files for targets using realtek-poe; the same static file is used for all switches.

Original explanation from Sander's post on the mailing list:

Create a new package to generate configuration files for devices capable of delivering power via PoE. The configuration file at /etc/config/poe can be used by PoE daemons to configure the hardware in an implementation specific way.

This is part of the core packages because it needs to be in sync with the format of board.json, from which the config file is generated. The config file structure is based on the current config file of the realtek-poe package, but should be (and remain) implementation independent. With a common basis, a common (LuCI) configuration interface also becomes possible in the future.

For a device with a power budget of 130W and ports lan1-lan8 mapping to PSE outputs 8-1, /etc/config/poe could look like (lan1-lan6 omitted):

	config global
		option budget '130'

	config port
		option name 'lan8'
		option id '1'
		option enable '1'

	config port
		option name 'lan7'
		option id '2'
		option enable '1'

	[...]

• Based entirely on the work of Sander Vanheule [email protected]
  Signed-off-by: Stephen Howell [email protected]

[svanheule]

This is a verbatim copy of my patch, with '@' replaced by ' at ' (breaking the uci_defaults script). Normally you would keep authorship in that case and call it a resubmission.

There are some reasons I seemingly abandoned this patch. Most of which relate to the config format being too optimized for realtek-poe setups.

First off is the "id" property, which is too ambiguous in it's current form. Perhaps "pse_output_id" would be better. With the in-kernel PSE framework, I don't think this is even required anymore, since the driver receives this mapping via the devicetree. Port management then goes ethtool, using the ethernet port name. See for example https://bootlin.com/blog/power-over-ethernet-poe-support-into-the-official-linux-kernel/
If "pse_output_id" (or equivalent) is no longer required in the config format, it could still be made optional, of course. Power limits could still be placed in a config file, so the kernel support doesn't necessarily obsolete the need for a PoE daemon or config format.

Secondly, the proposed format did not allow for multiple independent PSE managers. For example the Hasivo S1100WP-8GT-SE has two PSE chips without a management MCU. This device is not supported yet, nor are the PSE chips, but the Hasivo devices appear to be quite popular, so it's not unlikely this will at some point pop up.

Of course, these issues are mostly theoretical at this point. If we really want a poe-common package to generate base config though, I think it should start from the kernel interface, as that's the way forward for me. Any support for alternative handling (e.g. realtek-poe) should rather be a pure addition to that syntax.

[howels]

This is a verbatim copy of my patch, with '@' replaced by ' at ' (breaking the uci_defaults script). Normally you would keep authorship in that case and call it a resubmission.

There are some reasons I seemingly abandoned this patch. Most of which relate to the config format being too optimized for realtek-poe setups.

First off is the "id" property, which is too ambiguous in it's current form. Perhaps "pse_output_id" would be better. With the in-kernel PSE framework, I don't think this is even required anymore, since the driver receives this mapping via the devicetree. Port management then goes ethtool, using the ethernet port name. See for example https://bootlin.com/blog/power-over-ethernet-poe-support-into-the-official-linux-kernel/ If "pse_output_id" (or equivalent) is no longer required in the config format, it could still be made optional, of course. Power limits could still be placed in a config file, so the kernel support doesn't necessarily obsolete the need for a PoE daemon or config format.

Secondly, the proposed format did not allow for multiple independent PSE managers. For example the Hasivo S1100WP-8GT-SE has two PSE chips without a management MCU. This device is not supported yet, nor are the PSE chips, but the Hasivo devices appear to be quite popular, so it's not unlikely this will at some point pop up.

Of course, these issues are mostly theoretical at this point. If we really want a poe-common package to generate base config though, I think it should start from the kernel interface, as that's the way forward for me. Any support for alternative handling (e.g. realtek-poe) should rather be a pure addition to that syntax.

Thanks for replying, yes this is entirely your work as I have stated above. I initially tried to discuss this code on the forums but wasn't able to gather feedback so I started this PR to try and gather more comments from yourself and others.
I did not intend to imply that I was the author - please let me know the correct syntax to preserve your authorship. I have to use my own sign-off to keep the OpenWRT submission guidelines but want to keep your ownership of the code.
If you abandoned the approach due to shortcomings in the format I will close this PR. I was merely trying to generate appropriate PoE config files for the realtek switches, which represent most of the PoE usage in OpenWRT.

[svanheule]

Using

curl https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/mbox/ \
    | git am

should work to import the patch as intended (without translating '@'). Then you should be able to simply add your own Signed-off-by. That way you can indicate that, while you didn't author the patch, you are willing to take responsibility for the changes it contains.

I'm open for discussion on how to approach the issues I listed. @mrnuke and @Hurricos might have some opinions.

[howels]

curl https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/mbox/
| git am

Uploaded the patch with my own signoff added. Hope we can discuss with the realtek-poe authors and find a solution to provide correct PoE configuration for supported switches.
My perspective is that we should implement a solution dealing with the existing landscape, then update it when that landscape shifts with new kernel features in 6.12 or beyond. This package is a small set of scripts, and should remain such, being used to glue the common config file format to the PoE implementations used by various back-ends. That may mean that we need to include other data such as adding a "controller" key to port definitions to allow multiple PoE chips to co-exist in the same switch.

[Neustradamus]

Hope that will be backported when it will be good ^^

[blogic]

@svanheule is this package being actively used ? not clear to me if this should be merged or not.

[howels]

@svanheule is this package being actively used ? not clear to me if this should be merged or not.

I would be interested to see this get merged, it's really glue code but it's important if we want to actually use the PoE functionality on the growing number of Realtek targets with PoE.

Otherwise we have a default PoE config which enables PoE on the first port and no others, irrespective of the data in board.json.

[blogic]

@howels is the actual POE tool already inside main branch ? and if so the PR should include patches to select enable the code on supported devices via DEFAULT_PACKAGES.

[evs93]

I can test on JG922A, JG926A, JG928A at some point. I'll try to find time. There was a call for testers on the realtek switch thread?

[howels]

@howels is the actual POE tool already inside main branch ? and if so the PR should include patches to select enable the code on supported devices via DEFAULT_PACKAGES.

The Poe tool is an external repo and they refuse to add OpenWRT integration to generate the board configuration in that repo. This is therefore intended to act as handler for board configuration and cater for realtek-poe as well as other backends when they appear.

[blogic]

which repo is that and is the actual tool packaged ?

[howels]

which repo is that and is the actual tool packaged ?

See Hurricos/realtek-poe#31 (comment) for more information on why we are looking at this option.

[blogic]

@howels ok, so please change this PR to just import what is in that repo + the uci-defaults script s.T. it is self contained without needing the upstream GIT. and then make sure going fwd to update our packet if the upstream repo gets updated.

[blogic]

no pressure, but ideally this happens soonish, s.T. we can backport the commit to the 24.10 release branch before it is final

[howels]

@howels ok, so please change this PR to just import what is in that repo + the uci-defaults script s.T. it is self contained without needing the upstream GIT. and then make sure going fwd to update our packet if the upstream repo gets updated.

There is no upstream git in this PR, it is already self-contained. This PR adds an integration script for an existing package where the package maintainers refused to add that OpenWRT integration script into their own repo. Please see the comment and thread that I posted above relating to the discussion on https://github.com/Hurricos/realtek-poe which necessitated this PR.

[howels]

no pressure, but ideally this happens soonish, s.T. we can backport the commit to the 24.10 release branch before it is final

Please go ahead, this package is self-contained and consists of only a single script.

[blogic]

@howels what I mean ... import the code from https://github.com/Hurricos/realtek-poe, as-in upstream the code + the uci-defaults script. it is GPL so we can happily fork it.

packages/network/utils/realtek-poe should contain all src/files without a dependency on an external git/feed

[howels]

@howels what I mean ... import the code from https://github.com/Hurricos/realtek-poe, as-in upstream the code + the uci-defaults script. it is GPL so we can happily fork it.

packages/network/utils/realtek-poe should contain all src/files without a dependency on an external git/feed

Forking the repo introduces other problems such as the need for a new maintainer, while I can handle the uci integration I am unable to support the upstream code myself as it deals with details of PoE hardware controllers that I am not familiar with.
Such a fork would also alienate the original author; we are trying to respect their efforts and such a move is liable to create unnecessary tension and worsen the situation in the longer term.

[Hurricos]

To be totally clear, the only reason we haven't integrated PoE configuration setup is because there are multiple platforms that can provide PoE that may be ported to OpenWrt in the future, and may want to concurrently handle /etc/config/poe. We wanted instead to have a DTS-parsing initialization program -- we made the assumption that all OpenWrt platforms would either be OF-only or manually configured per device strings as with x86 -- that would collect the right starting values and allow users to (edited) consume the results with whatever implementation they like.

Then, if a successor e.g. to realtek-poe came along -- for example, a kernel module -- we'd be able to totally chuck realtek-poe, use the kernel module, and never have to worry about gutting the "package which provides a userspace-daemon to manage PoE" to leave only the config bits.

[Hurricos]

@svanheule et. al were also involved in the decision to break apart into multiple packages. @blogic -- If you'd really, really, really prefer we not break them apart, despite the feelings of a couple of people, I will set aside an hour in the next 6 hours to dig up the original realtek-poe PR and merge that.

It's just that we want to keep hoping for a world where /etc/config/poe starts correct no matter what the implementation that consumes it is.

[blogic]

@Hurricos tl;dr dont care about details and politics, right now owrt users have no functional PoE within main branch

packages/network/utils/realtek-poe shall contain all code within incl. the uci-defaults script, end of story

[Hurricos]

As a similarly affected OpenWrt user ... yeah. It's annoying copying config onto a stack of 48-port HP PoE switches, especially when I'm too pig-headed to connect them to the network first.

packages/network/utils/realtek-poe shall contain all code within incl. the uci-defaults script, end of story

Then so it shall be. Give me a bit.

[blogic]

As a similarly affected OpenWrt user ... yeah. It's annoying copying config onto a stack of 48-port HP PoE switches, especially when I'm too pig-headed to connect them to the network first.

packages/network/utils/realtek-poe shall contain all code within incl. the uci-defaults script, end of story

Then so it shall be. Give me a bit.

kindly include the uci-defaults script

[Hurricos]

A PR to openwrt/packages.git was outstanding, but the main realtek-poe author disagreed with the principle and I have reverted the commit.

[Hurricos]

I think the sword to cut the Gordian Knot here is probably to hardcode the inclusion in openwrt/packages.

In any case, openwrt/openwrt is not the right place to put any package changes to fix the issue.

@howels, please see openwrt/packages#25551 instead.

[ynezz]

right now owrt users have no functional PoE within main branch
packages/network/utils/realtek-poe shall contain all code within incl. the uci-defaults script, end of story

I agree, this is going on for several years, so lets be pragmatic here and make the PoE working out of the box:

1. move realtek-poe from packages.git feed here
2. make it working out of the box via DEFAULT_PACKAGES on devices which need it

no pressure, but ideally this happens soonish, s.T. we can backport the commit to the 24.10 release branch before it is final

+1