lkml.org 
[lkml]   [2021]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFC PATCH 2/3] power: supply: Add support for PDOs props
    Date
    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.

    \
     
     \ /
      Last update: 2021-09-24 17:41    [W:4.003 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site