> Indeed, but regulator API already provide such events, which will even be sent > when we enable or disable the PSE. Should we write a second event management. > Using regulator event API allows to report over current internal events to the > parents regulator the power supply of the PSE which could also do something to > avoid smoke. > > Or maybe we should add another wrapper which will send PSE ethtool netlink > notification alongside the regulator notifications supported by this patch. > > > Also, how do regulator events work in combination with network > > namespaces? If you move the interface into a different network > > namespace, do the regulator events get delivered to the root namespace > > or the namespace the interface is in? > > regulator events are sent in root namespace. I think we will need two event, the base regulator event, and a networking event. Since it is a regulator, sending a normal regulator event makes a lot of sense. But mapping that regulator event to a netns:ifnam is going to be hard. Anything wanting to take an action is probably going to want to use ethtool, and so needs to be in the correct netns, etc. But it does get messy if there is some sort of software driven prioritisation going on, some daemon needs to pick a victim to reduce power to, and the interfaces are spread over multiple network namespaces. What i don't know is if we can use an existing event, or we should add a new one. Often rtnetlink_event() is used: https://elixir.bootlin.com/linux/v6.12-rc1/source/net/core/rtnetlink.c#L6679 but without some PSE information in it, it would be hard to know why it was sent. So we probably either want a generic ethtool event, or a PSE event. Andrew
