On Thu, 27 Feb 2025 17:40:42 +0100 Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > On Thu, Feb 27, 2025 at 03:57:27PM +0100, Kory Maincent wrote: > > On Thu, 27 Feb 2025 08:40:25 +0100 > > Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > > > > > On Wed, Feb 26, 2025 at 06:42:57PM -0800, Jakub Kicinski wrote: > [...] > [...] > [...] > > > > > > Ok, I see. @Köry, can you please provide regulator_summary with some > > > inlined comments to regulators related to the PSE components and PSE > > > related outputs of ethtool (or what ever tool you are using). > > > > > > I wont to use this examples to answer. > > > > On my side, I am not close to using sysfs. As we do all configurations > > through ethtool I have assumed we should continue with ethtool. > > Yes, I agree. But it won't be possible to do it for all components. > > > I think we should set the port priority through ethtool. > > ack > > > but indeed the PSE power domain method get and set could be moved to > > sysfs as it is not something relative to the port but to a group of > > ports. > > I would prefer to have it in the for of devlink or use regulator netlink > interface. But, we do not need to do this discussion right now. If we want to report the method we should discuss it now. We shouldn't add BUDGET_EVAL_STRAT uAPI to ethtool if we use another way to get and set the method later. We could also not report the method for now and assume the user knows it for the two controllers currently supported. > > Ethtool should still report the PSE power domain ID of a port to know > > which domain the port is. > > Exactly. > > @Jakub, at current implementation stage, user need to know the domain > id, because ports (and priorities) are grouped by the top level > regulators (pse-regX in the regulator_summary), they are our top-level > bottlenecks. > > HP and Cisco switch either use different PSE controllers, or just didn't > exposed this nuance to the user. Let's assume, they have only one > global power domain. > > So, in current patch set I would expect (not force :) ) implementation for > following fields: > - per port: > - priority (valid within the power domain) > - power reservation/allocation methods. First of all, because all > already supported controllers have different implemented/default > methods: microchip - dynamic, TI - static, regulator-pse - fixed (no > classification is supported). > At same time, in the future, we will need be able switch between > (static or dynamic) and fixed for LLPD or manual configuration. > Yes, at this point all ports show the same information and it seems > to be duplicated. > - power domain ID. > > @Jakub, did I answered you question, or missed the point? :) > > > @Oleksij here it is: > > Thank you! > > I do not expect it to be the primer user interface, but it can provide > additional diagnostic information. I wonted to see how it is aligns > with current ethtool UAPI implementation and if it possible to combine > it for diagnostics. > > > # cat /sys/kernel/debug/regulator/regulator_summary > > regulator use open bypass opmode voltage current > > min max > > --------------------------------------------------------------------------------------- > > regulator-dummy 5 4 0 unknown 0mV 0mA > > 0mV 0mV d00e0000.sata-target 1 > > 0mA 0mV 0mV d00e0000.sata-phy 1 > > 0mA 0mV 0mV d00e0000.sata-ahci 1 > > 0mA 0mV 0mV spi0.0-vcc 1 > > 0mA 0mV 0mV pse-reg > > 1 4 0 unknown 0mV 0mA 0mV 0mV > > pse-regX should be attached to the main supply regulator for better full > picture. And use different name to be better identified as PSE power domains > with ID? This is the regulator name set in the devicetree description so we can set whatever we want. Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
