On 21 September 2021 11:54, Heikki Krogerus wrote: > If we can leave the decision about the selection to TCPM, that would > be great! I'm not against that at all. As I said, I have not though > through the control aspect. Right now I'm mostly concerned about how > we expose the information to the user. The only reason why I have > considered the control part at all is because how ever we decide to > expose the information to the user, it has to work with control as > well. Well part of the discussion has to be about the role that the user plays in the control. What does and doesn't need to be controlled further up the stack, and what will be taken care of by, for example, TCPM? Surely that dictates to some degree what and how we expose all of this? Right now we have a simple means to read and control voltages and currents through a PSY class, without the need for the user to know any details of what a PDO/APDO is. Do we continue with abstracting away to the user or instead let the user decipher this itself and decide? Am just trying to understand the needs going forward. > The final PSYs and the supply chains they create as well as the > individual properties I'm more than happy to talk about, but having a > separate object for the smallest thing that we can see (PDO) is the > right thing to do here IMO. Trying to concatenate things into single > objects especially in sysfs, despite how nice it always would seem, > has taken me to the brink of disaster in the past far too many times. > > In this case we don't need to take the risk of having to duplicated > information or in worst case deprecate something that is also exposed > to the sysfs in the future. > > So the question is not why should we registers every individual PDO > separately. The question is, why shouldn't we do that? And saying that > it's "heavyweight" I'm afraid is not good enough. :-) That was my initial feeling on the suggestion based on the idea of a PSY per PDO and I still don't feel that fits as your creating a whole class of resources to expose something that's pretty small. To me the PSY represents the source as whole, and the PDOs are simply options/configurations for that source. If we're needing to expose PDOs then I don't disagree with separating them out individually and I certainly wouldn't want that all concatenated as one property. However I think something like dynamically generated properties might be a nicer solution to expose each PDO, or even groups of properties if you wanted to split PDOs even further into constituent parts to the user. Honestly though I'm not really against anything right now. I'm still trying to build a better view for myself as to how this needs to be used in the future.
