On Mon, 7 Oct 2024 16:10:33 +0200 Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > > > > Currently the priority is managed by the PSE controller so the port is the > > only information needed. The user interface is ethtool, and I don't see why > > he would need such things like controller id or power domain id. Instead, > > it could be managed by the PSE core depending on the power domains > > described in the devicetree. The user only wants to know if he can allow a > > specific power budget on a Ethernet port and configure port priority in > > case of over power-budget event. > > Budget is important but different topic. If user do not know how much > the budget is, there is nothing usable user can configure. Imagine you > do not know how much money can spend and the only way to find it out is > by baying things. Yes I agree, but I thought this could be done at the driver level specified in the power limit ranges for now. I don't really know the Power Domain API but I don't think it can currently support what you are expecting for PSE. Maybe through the regulator API, or something specific to PSE API. Maybe we should define the power domain PSE concept as it seems something PSE specific. > But, budget is the secondary topic withing context of this patch set. > The primer topic here is the prioritization, so the information user > need to know it the context: do A has higher prio in relation to B? Do A > and B actually in the same domain? > > > > I don't have hardware with several PSE controllers. Is there already such > > hardware existing in the market? > > Please correct me if i'm wrong, but in case of pd692x0 based devices, > every manager (for example PD69208M) is own power domain. There are > following limiting factors: > PI 1 > L4 / > PD69208M - PI 2 > L3 // \ > L1 L2 // PI 3 > PSU ============' > \\ PI 4 > \\ / > PD69208M - PI 5 > \ > PI 6 > > L1 - limits defined by Power Supply Unit > L2 - Limits defined by main supply rail ob PCB > L3 - Limits defined by rail attached to one specific manager > L4 - Limits defined by manager. In case of PD69208M it is Max 0.627A > (for all or per port?) Should the rail really have an impact on power limit? I am not a hardware designer but having limit defined by the rails seems the best way to create magic smoke. Don't know how you find this 0.627A value but it seems a bit low. Port current limit is 1300mA according to the datasheet. I first though that hardware should support all ports being powered at the same time. Indeed this might not be the case be and there is a command to configure the power bank (PD69208M) power limit. > Assuming PSU provides enough budget to covert Max supported current for > every manager, then the limiting factor is actual manager. It means, > setting prio for PI 4 in relation to PI 1 makes no real sense, because > it is in different power domain. In fact it does for our case as the PD692x0 consider all the ports in the same power domain. There is no mention of port priority per PD69208M. We can only get PD69208M events and status. > User will not understand why devices fail to provide enough power by > attaching two device to one domain and not failing by attaching to > different domains. Except we provide this information to the user space. What you are explaining seems neat on the paper but I don't know the best way to implement it. It needs more brainstorming. Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
