Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To:     Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
CC:     Benson Leung <bleung@google.com>,
        Prashant Malani <pmalani@chromium.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "bleung@chromium.org" <bleung@chromium.org>,
        "badhri@google.com" <badhri@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Sebastian Reichel <sre@kernel.org>,
        Guenter Roeck <linux@roeck-us.net>
Subject: RE: [RFC PATCH 2/3] power: supply: Add support for PDOs props
Thread-Topic: [RFC PATCH 2/3] power: supply: Add support for PDOs props
Thread-Index: AQHXoEKRtU4w32eDxEeY6U4KQGzJs6uiBmsAgAAaumCAAUDQAIAC9NuAgAAyawCAAD1scIAHpq+AgAUCZYA=
Date:   Fri, 24 Sep 2021 15:38:23 +0000
Message-ID: <DB9PR10MB46524E3817FB4D836CDC13E180A49@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
References: <20210902213500.3795948-1-pmalani@chromium.org>
 <20210902213500.3795948-3-pmalani@chromium.org>
 <YT9SYMAnOCTWGi5P@kuha.fi.intel.com>
 <DB9PR10MB4652B4A6A2A2157018307AE380D99@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
 <YUB16up3JDwi3HfI@kuha.fi.intel.com> <YULwz8NsoA3+vrhA@google.com>
 <YUMbGp0aemx1HCHv@kuha.fi.intel.com>
 <DB9PR10MB46525E6CA4C6BB101059D93C80DC9@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
 <YUm5sdbceMcDTvYj@kuha.fi.intel.com>
In-Reply-To: <YUm5sdbceMcDTvYj@kuha.fi.intel.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 06c93788-c174-4647-5228-08d97f715852
x-ms-traffictypediagnostic: DB7PR10MB1931:
x-ms-exchange-sharedmailbox-routingagent-processed: True
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB7PR10MB19313970EA0109414815D01EA7A49@DB7PR10MB1931.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eHv7ys9cQt/3AQ+WLduec7AZRWOiQ6nKLY+ec6X9wMe3q+6Y0aofnM99pD4dg/pGac6xeUdJ/OTAAKReCRfPprM5LS/53+6OmXUbqNoYsad0mHPs1mXtgECF7IVbYbM1XlzjIBFGtjyUdx99hG7HlSjn/OOpqeWGePpYqDMNikqp4F0f6ayh0NhOD86+i/fV07pfoWc/fiua0z9UavaLch5XDCllpPlIHs4uA+Y/LG5WzPNH4i7GcifeHZfNYLkmO4rwL15Uf3f2jBZUIXpuc7ZHvDoi9JFAOOmYEY+nvmiULIv8ajuTBQQbvEZsWEF9wcXswP819vny06ODIp9Oj5Ca884AysIYj/LANGzzF2lnFPytHFGzn7ZWTH3D839Y0hvPDtQMNvc+6XjxBilU9NpKLBpbIfYim1Puy6KTYdjMZlmsW4xJ6pvUfE+WyJ+YSxE2mOee9U4vKq9wqt9v1D1VcKQ3toKPpRnJEX+eW4dpXdcWdZ5Dgp1HxpzSo6eGJCeFZQwMHqLJbfHDPD0/9kVN6aXVjBzt5HZ358vasc2THZ8Tg/nq3pWjef6jPWVGy77YeljyTJnmE9Xum9ks4VD3RlL44ex8paRNCwEZEOws5sYpd94olJy7Q5R0Zu71En783tCbizkSEh4LlxocFAVqOPZvnN4zgPyAgiiL2pFKiwG8fubmzIS3jwKLrvp8puf5BPdHkgY+IulNWQhm1g==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(4636009)(366004)(76116006)(66446008)(316002)(52536014)(2906002)(7696005)(83380400001)(66556008)(71200400001)(110136005)(55016002)(38070700005)(64756008)(66476007)(8936002)(7416002)(8676002)(66946007)(54906003)(26005)(5660300002)(6506007)(55236004)(4326008)(53546011)(508600001)(186003)(33656002)(86362001)(122000001)(9686003)(38100700002);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?dKp6kEJFBphsfoDJhOX+KaFnzMosxlzyyp4Xbtti/1OxhPXsAwSwov433W2H?=
 =?us-ascii?Q?q6GUAbMxKtCvZBBnKmiB7vAItSBpgkdJ86NbS9w9RQC86qdstf0XdbMaX43Y?=
 =?us-ascii?Q?0nSLdg+sHwpH+L02yIhKmHfCr1IlAhRdcDSXclxubzvgJt5U50QJPi9B82zR?=
 =?us-ascii?Q?TXg8JMyo4Q1cuYEsvYlkI55gUKZ5wJKuYJvrc2dakpcOtNmiCo6KRMx5XnzV?=
 =?us-ascii?Q?FgyjJC+hgWkf6JVXR/07zxi9TGgx8ph2o9G+KOvBqmn+NekzNAkHXFbZqBQ1?=
 =?us-ascii?Q?fi7ZxSArRwtAM+6hHG0fv/OWLLr8Uz2/jRDe8KAx9wV4hrV4r2hVzG208zRh?=
 =?us-ascii?Q?TADNBK+63ugXLWsbxlleOmTNZAi0jeIbs3tqilgjjoLoeFWIjYFnzHBFqnbb?=
 =?us-ascii?Q?pxZcM7q0BaWJQdzWZOblRN1cs5Xk61RUj+g8w4GOIznPgVFPpyfHZzkWGtku?=
 =?us-ascii?Q?E6aVNwHNrPuNpKhEnXr5zZ3ztoTeWIPCcx2GrQ+vYQop9bj9xMOVWuQ+yV5P?=
 =?us-ascii?Q?Iv/cyZPXmZw5IpD5p6zwTmiMQ3RptvF5ETYGPjk7ULPLTF5W/ihxjvbekArx?=
 =?us-ascii?Q?um+h502TRw+WiY38UD+AWn//c0XaRVPIrcElHupzwERnrTschVGc/ftJlmoj?=
 =?us-ascii?Q?E6h5nQrqw0rFRXRhfd7pG84FGzNWpMa6DPpLMhHyUXtkNiabSADQUmvTi/Zq?=
 =?us-ascii?Q?fF7ZefY/3BZYw+EjpxZoGdU6M5tspzNfiqoq6kRzcZc75vW4NKWPXJK+2F2A?=
 =?us-ascii?Q?UTG5SC7Wu12qW4iXMTo8Lb8Qp8U7sUtzWkFHyAo0K1w+x+m0jaSy7i6y0oGw?=
 =?us-ascii?Q?vs+bUqkE+DFwwnnTW/ODE+F9xlYjsOELHb8n6NKMEyBqU+Z0HWERguVz8kIY?=
 =?us-ascii?Q?f3Qn3TxA9Mny3JRKwZgakIaMsfnnNgbGLgJzqNC8Pq2IRFHEEy3oACj+w7Vh?=
 =?us-ascii?Q?sLQYfwnjUi1+Jkp4T8nDATTE1B8q4ThhV8e5SpouESEy/6mXEkRefB3zicon?=
 =?us-ascii?Q?lZ+NqjHsJB/6gOEHOAvaG2f3Q2fl5XTSiwUxYhr1+iqejJLeNBcJz+aZATSc?=
 =?us-ascii?Q?rtzCDbdLisHcCk/EuiSBOGJJwOXaclqHZuaVrJmH55XTZmA9a9JHVozSZIeQ?=
 =?us-ascii?Q?Qy4fKK3ENEkKUGpSfWY38O8qHWPtHV25sqEefNkk1xmzONTnPpnyPM2VkL/S?=
 =?us-ascii?Q?2OAqdGL5jdF3MNod8ICmOqh+R3E9BCMbE1Fd5ZClQBtSgoktDtk989ssuVPj?=
 =?us-ascii?Q?1SbUay4faeQM/Oobu6s32tAY4g/Nw0kTZHbV1++/CWNyerHyecHihostpm+Q?=
 =?us-ascii?Q?e3pLVmAqrCW8L9efw4YdLgaU?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: diasemi.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 06c93788-c174-4647-5228-08d97f715852
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2021 15:38:23.8999
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 511e3c0e-ee96-486e-a2ec-e272ffa37b7c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HblffOThtChO7JPt1LG184MpZCq1YG5r14emEWd8p/7AmpTIGGTP7zjM++y7mZvA2d9spJOjr3fP0YY7IrA4XaaQO/SYh25s1YNqss1c+jc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR10MB1931
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 sta=
ck,
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 a=
nd
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 pe=
r PDO
and I still don't feel that fits as your creating a whole class of resource=
s
to expose something that's pretty small. To me the PSY represents the sourc=
e as
whole, and the PDOs are simply options/configurations for that source. If w=
e'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 futur=
e.