linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-pm@vger.kernel.org, bleung@chromium.org, badhri@google.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sebastian Reichel <sre@kernel.org>,
	Adam Thomson <Adam.Thomson.Opensource@diasemi.com>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [RFC PATCH 2/3] power: supply: Add support for PDOs props
Date: Mon, 13 Sep 2021 16:30:08 +0300	[thread overview]
Message-ID: <YT9SYMAnOCTWGi5P@kuha.fi.intel.com> (raw)
In-Reply-To: <20210902213500.3795948-3-pmalani@chromium.org>

Hi Prashant,

On Thu, Sep 02, 2021 at 02:35:00PM -0700, Prashant Malani wrote:
> Add support for reporting Source and Sink Capabilities
> Power Data Object (PDO) property. These are reported by USB
> Power Delivery (PD) capable power sources.
> 
> Signed-off-by: Prashant Malani <pmalani@chromium.org>
> ---
>  Documentation/ABI/testing/sysfs-class-power | 30 +++++++++++++++++++++
>  drivers/power/supply/power_supply_sysfs.c   | 18 ++++++++++++-
>  include/linux/power_supply.h                |  5 ++++
>  3 files changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
> index ca830c6cd809..90d4198e6dfb 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -562,6 +562,36 @@ Description:
>  			      "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
>  			      "PD_DRP", "PD_PPS", "BrickID"
>  
> +What:		/sys/class/power_supply/<supply_name>/source_cap_pdos
> +Date:		September 2021
> +Contact:	linux-pm@vger.kernel.org
> +Description:
> +		Reports the Source Capabilities Power Data Objects (PDO) reported by the USB
> +		PD-capable power source. 13 PDOs are listed. PDOs 1-7 represent the Source Caps
> +		for devices which only support Standard Power Range (SPR), whereas PDOs 8-13
> +		are for Extended Power Range (EPR) capable sources.
> +		NOTE: The EPR Source Caps message is a superset of the Source Cap message, so on
> +		SPR-only sources, PDOs 8-13 will be 0.
> +
> +		Access: Read-Only
> +
> +		Valid values: Represented as a list of 13 32-bit PDO objects in hexadecimal format.
> +
> +What:		/sys/class/power_supply/<supply_name>/sink_cap_pdos
> +Date:		September 2021
> +Contact:	linux-pm@vger.kernel.org
> +Description:
> +		Reports the Sink Capabilities Power Data Objects (PDO) reported by the USB
> +		PD-capable power source. 13 PDOs are listed. PDOs 1-7 represent the Sink Caps
> +		for devices which only support Standard Power Range (SPR), whereas PDOs 8-13
> +		are for Extended Power Range (EPR) capable sinks.
> +		NOTE: The EPR Sink Caps message is a superset of the Sink Cap message, so on
> +		SPR-only sinks, PDOs 8-13 will be 0.
> +
> +		Access: Read-Only
> +
> +		Valid values: Represented as a list of 13 32-bit PDO objects in hexadecimal format.

My plan is to register a separate power supply for each PDO. So for
every source PDO and every sink PDO a port has in its capabilities,
you'll have a separate power supply registered, and the same for the
partner when it's connected. With every connection there should always
be one active (online) source psy and active sink psy (if the port is
source, one of the port's source psys will be active and the partner
will have the active sink psy, or vise versa - depending on the role).

Each PDO represents a "Power Supply" so to me that approach just
makes the most sense. It will require a bit of work in kernel, however
in user space it should mean that we only have a single new attribute
file for the power supplies named "pdo" that returns a single PDO.

Let me know if you guys see any obvious problems with the idea.
Otherwise, that is how we really need to do this. That will make
things much more clear in user space. I have a feeling it will make
things easier in kernel as well in the long run.

Adding Adam and Guenter. It would be good if you guys could comment
the idea as well.

thanks,

-- 
heikki

  reply	other threads:[~2021-09-13 13:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 21:34 [RFC PATCH 0/3] Type C partner power supply and PDO support Prashant Malani
2021-09-02 21:34 ` [RFC PATCH 1/3] usb: pd: Increase max PDO objects to 13 Prashant Malani
2021-09-03  6:47   ` Jack Pham
2021-09-03 18:05     ` Jack Pham
2021-09-07 21:36       ` Prashant Malani
2021-09-07 23:28     ` Benson Leung
2021-09-09 17:37       ` Jack Pham
2021-09-02 21:35 ` [RFC PATCH 2/3] power: supply: Add support for PDOs props Prashant Malani
2021-09-13 13:30   ` Heikki Krogerus [this message]
2021-09-13 15:15     ` Adam Thomson
2021-09-13 19:30       ` Benson Leung
2021-09-14 10:28         ` Heikki Krogerus
2021-09-14 10:14       ` Heikki Krogerus
2021-09-16  7:22         ` Benson Leung
2021-09-16 10:23           ` Heikki Krogerus
2021-09-16 14:12             ` Adam Thomson
2021-09-16 16:16               ` Badhri Jagan Sridharan
2021-09-20 13:20                 ` Rajaram R
2021-09-22 10:40                   ` Heikki Krogerus
2021-09-21 10:53               ` Heikki Krogerus
2021-09-24 15:38                 ` Adam Thomson
2021-10-07 22:32                   ` Prashant Malani
2021-10-08 11:09                     ` Heikki Krogerus
2021-10-11 23:05                       ` Prashant Malani
2021-10-12 10:42                       ` Adam Thomson
2021-09-13 17:40     ` Benson Leung
2021-09-14 11:04       ` Heikki Krogerus
2021-09-02 21:35 ` [RFC PATCH 3/3] usb: typec: Add partner power registration call Prashant Malani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YT9SYMAnOCTWGi5P@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=Adam.Thomson.Opensource@diasemi.com \
    --cc=badhri@google.com \
    --cc=bleung@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pmalani@chromium.org \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).