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;
MIME-Version: 1.0
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>
 <CAPTae5Kxmp0L35KnkYaHARrBmysX9wkMYZhGhJsu6tX4bcHuAA@mail.gmail.com>
In-Reply-To: <CAPTae5Kxmp0L35KnkYaHARrBmysX9wkMYZhGhJsu6tX4bcHuAA@mail.gmail.com>
From:   Rajaram R <rajaram.officemail@gmail.com>
Date:   Mon, 20 Sep 2021 18:50:22 +0530
Message-ID: <CAOiXhaLpe7gHw6c8pCZDNeOC31WfxFum5G1RNiEbEG2Fn=6oeQ@mail.gmail.com>
Subject: Re: [RFC PATCH 2/3] power: supply: Add support for PDOs props
To:     Badhri Jagan Sridharan <badhri@google.com>
Cc:     Adam Thomson <Adam.Thomson.Opensource@diasemi.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        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>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Sebastian Reichel <sre@kernel.org>,
        Guenter Roeck <linux@roeck-us.net>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Sep 17, 2021 at 6:25 AM Badhri Jagan Sridharan
<badhri@google.com> wrote:
>
> On Thu, Sep 16, 2021 at 7:12 AM Adam Thomson
> <Adam.Thomson.Opensource@diasemi.com> wrote:
> >
> > On 16 September 2021 11:23, Heikki Krogerus wrote:
> >
> > > > Thanks for providing the clarification. So you're proposing a port-psy and a
> > > > port-partner-psy that are connected to each other (one supplying the other).
> > > > If PD is not present, those two will exist per port and partner, and there
> > > > will be information about Type-C current (and possibly BC 1.2 and other
> > > > methods?)
> > >
> > > Yes, exactly.


 As Benson mentioned PDOs contain more than power details like USB
Suspend indicator etc or Type-C only devices as Badhri mentioned here
may not integrate well with PSY class.  Additionally, it is also
important to consider cable properties here for power as they also
have a role to play in the power limits and necessitates change of
existing PDOs or power limits. ( Type-C Monitor charging a computing
system does not have captive cables)

Given too many possibilities, would an approach similar to
gadgetfs/configfs or cpu scaling say like "type-configfs" or "typec
scaling" ABI framework that allows USB=C port management under one
path /sys/class/typec that allows:

- Provision to manage USB-C port power (  Power supply class should
still represent power contract established, as remaining
characteristics are nested with functional aspects and relevant on a
power contract failure )
+ dynamically change Rp ( Rp(default) is required to enter USB suspend)
+ Set PDO Policy ( PPS, Fixed, etc)
+ Give back power
+ Expose complete PDO ( As we do for VDOs)
+ Change USB Suspend flag

- Provision for extended messages
+ Provides additional details regarding ports like Get Status etc.
This shall allow us to take system level decisions.

- Provision to manage USB-C modes
+ Provision to enter modes as provided by interface standards like UCSI

With this user tools like Chrome OS "typecd" be able to use a single
class and its ABIs to manage USB-C port power and mode. Kindly correct
me if I am missing something here.