mbox series

[v2,0/3] usb: typec: Separate sysfs directory for all USB PD objects

Message ID 20220412130023.83927-1-heikki.krogerus@linux.intel.com (mailing list archive)
Headers show
Series usb: typec: Separate sysfs directory for all USB PD objects | expand

Message

Heikki Krogerus April 12, 2022, 1 p.m. UTC
Hi,

In this version the USB Power Delivery support is now completely
separated into its own little subsystem. The USB Power Delivery
objects are not devices, but they are also no longer tied to any
device by default. This change makes it possible to share the USB PD
objects between multiple devices on top of being able to select the
objects that we want the device to use.

The USB Power Delivery objects are now placed under
/sys/kernel/usb_power_delivery directory. As an example:

	/sys/kernel/usb_power_delivery/pd0

So now that pd0 can be linked to a device, or devices, that want (or
can) use it to negotiate the USB PD contract with. An example where
two devices share the PD:

	/sys/class/typec/port0/usb_power_delivery -> ../../../../../../../kernel/usb_power_delivery/pd0
	/sys/class/typec/port1/usb_power_delivery -> ../../../../../../../kernel/usb_power_delivery/pd0

I did not change the directory hierarchy at all, because I'm assuming
that it is not a problem anymore:

	pd0/<message>/<object>/<field>

On top of that change, I also switched to tcpm.c from ucsi.c as
the first user of this thing.


v1 cover letter:

Ideally after this there should be no need to add any new USB Power
Delivery specific attribute files directly to the USB Type-C devices
in sysfs. They now have their own directory.

The idea of the series is that any device (so not just USB Type-C
connectors and the partners attached to them) that supports USB Power
Delivery can have this separate sub-directory "usb_power_delivery" in
sysfs, and that sub-directory will have all the USB Power Delivery
objects and all the other USB Power Delivery details.

There are already ways that allow us to read the USB Power Delivery
capabilities from potentially any USB PD capable USB device attached
to the bus - one way is defined in the USB Type-C Bridge
Specification.

Initially the Capability Messages (i.e. PDOs) are exposed.

This is an example (tree view) of the capabilities that the ports on a
normal x86 system advertise to the partner. First you have the message
directory (source_capabilities and sink_capabilities), and that will
have a sub-directory for each PDO that capability message has. The PDO
sub-directories are named by their type. The number in front of the
name is the object position of the PDO:

/sys/class/typec/port0/usb_power_delivery
|-- revision
|-- sink_capabilities/
|   |-- 1:fixed_supply/
|   |   |-- dual_role_data
|   |   |-- dual_role_power
|   |   |-- fast_role_swap_current
|   |   |-- operational_current
|   |   |-- unchunked_extended_messages_supported
|   |   |-- unconstrained_power
|   |   |-- usb_communication_capable
|   |   |-- usb_suspend_supported
|   |   `-- voltage
|   |-- 2:variable_supply/
|   |   |-- maximum_voltage
|   |   |-- minimum_voltage
|   |   `-- operational_current
|   `-- 3:battery/
|       |-- maximum_voltage
|       |-- minimum_voltage
|       `-- operational_power
`-- source_capabilities/
    `-- 1:fixed_supply/
        |-- dual_role_data
        |-- dual_role_power
        |-- maximum_current
        |-- unchunked_extended_messages_supported
        |-- unconstrained_power
        |-- usb_communication_capable
        |-- usb_suspend_supported
        `-- voltage

And these are the capabilities of my Thunderbolt3 dock:

/sys/class/typec/port0-partner/usb_power_delivery
|-- revision
|-- sink_capabilities/
|   `-- 1:fixed_supply/
|       |-- dual_role_data
|       |-- dual_role_power
|       |-- fast_role_swap_current
|       |-- operational_current
|       |-- unchunked_extended_messages_supported
|       |-- unconstrained_power
|       |-- usb_communication_capable
|       |-- usb_suspend_supported
|       `-- voltage
`-- source_capabilities/
    |-- 1:fixed_supply/
    |   |-- dual_role_data
    |   |-- dual_role_power
    |   |-- maximum_current
    |   |-- unchunked_extended_messages_supported
    |   |-- unconstrained_power
    |   |-- usb_communication_capable
    |   |-- usb_suspend_supported
    |   `-- voltage
    |-- 2:fixed_supply/
    |   |-- maximum_current
    |   `-- voltage
    |-- 3:fixed_supply/
    |   |-- maximum_current
    |   `-- voltage
    |-- 4:fixed_supply/
    |   |-- maximum_current
    |   `-- voltage
    `-- 5:fixed_supply/
        |-- maximum_current
        `-- voltage

Heikki Krogerus (3):
  usb: typec: Separate USB Power Delivery from USB Type-C
  usb: typec: USB Power Deliver helpers for ports and partners
  usb: typec: tcpm: Register USB Power Delivery Capabilities

 Documentation/ABI/testing/sysfs-class-typec   |   8 +
 .../testing/sysfs-kernel-usb_power_delivery   | 255 ++++++
 drivers/usb/typec/Makefile                    |   2 +-
 drivers/usb/typec/class.c                     | 153 ++++
 drivers/usb/typec/class.h                     |   4 +
 drivers/usb/typec/pd.c                        | 741 ++++++++++++++++++
 drivers/usb/typec/pd.h                        |  31 +
 drivers/usb/typec/tcpm/tcpm.c                 | 142 +++-
 include/linux/usb/pd.h                        |  33 +
 include/linux/usb/typec.h                     |  22 +
 10 files changed, 1389 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-usb_power_delivery
 create mode 100644 drivers/usb/typec/pd.c
 create mode 100644 drivers/usb/typec/pd.h

Comments

Greg Kroah-Hartman April 12, 2022, 2:38 p.m. UTC | #1
On Tue, Apr 12, 2022 at 04:00:20PM +0300, Heikki Krogerus wrote:
> Hi,
> 
> In this version the USB Power Delivery support is now completely
> separated into its own little subsystem. The USB Power Delivery
> objects are not devices, but they are also no longer tied to any
> device by default. This change makes it possible to share the USB PD
> objects between multiple devices on top of being able to select the
> objects that we want the device to use.
> 
> The USB Power Delivery objects are now placed under
> /sys/kernel/usb_power_delivery directory. As an example:
> 
> 	/sys/kernel/usb_power_delivery/pd0

No, sorry, this is a device, it does NOT belong in /sys/kernel/

And this really should be a real device, as I mentioned before, not a
kobject.

> So now that pd0 can be linked to a device, or devices, that want (or
> can) use it to negotiate the USB PD contract with. An example where
> two devices share the PD:
> 
> 	/sys/class/typec/port0/usb_power_delivery -> ../../../../../../../kernel/usb_power_delivery/pd0
> 	/sys/class/typec/port1/usb_power_delivery -> ../../../../../../../kernel/usb_power_delivery/pd0

Point to the pd device, not the kobject.

> I did not change the directory hierarchy at all, because I'm assuming
> that it is not a problem anymore:
> 
> 	pd0/<message>/<object>/<field>

Let's get back to devices first, worry about crazy depth second.

thanks,

greg k-h
Heikki Krogerus April 13, 2022, 7:19 a.m. UTC | #2
Hi Greg,

On Tue, Apr 12, 2022 at 04:38:33PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 12, 2022 at 04:00:20PM +0300, Heikki Krogerus wrote:
> > Hi,
> > 
> > In this version the USB Power Delivery support is now completely
> > separated into its own little subsystem. The USB Power Delivery
> > objects are not devices, but they are also no longer tied to any
> > device by default. This change makes it possible to share the USB PD
> > objects between multiple devices on top of being able to select the
> > objects that we want the device to use.
> > 
> > The USB Power Delivery objects are now placed under
> > /sys/kernel/usb_power_delivery directory. As an example:
> > 
> > 	/sys/kernel/usb_power_delivery/pd0
> 
> No, sorry, this is a device, it does NOT belong in /sys/kernel/
> 
> And this really should be a real device, as I mentioned before, not a
> kobject.

Okay. I had to do this proposal to be sure (nobody answered my
question in v1). Sorry.

I'll make these into devices. USB Power Delivery shall be the device
class for them.

> > So now that pd0 can be linked to a device, or devices, that want (or
> > can) use it to negotiate the USB PD contract with. An example where
> > two devices share the PD:
> > 
> > 	/sys/class/typec/port0/usb_power_delivery -> ../../../../../../../kernel/usb_power_delivery/pd0
> > 	/sys/class/typec/port1/usb_power_delivery -> ../../../../../../../kernel/usb_power_delivery/pd0
> 
> Point to the pd device, not the kobject.
> 
> > I did not change the directory hierarchy at all, because I'm assuming
> > that it is not a problem anymore:
> > 
> > 	pd0/<message>/<object>/<field>
> 
> Let's get back to devices first, worry about crazy depth second.

Thanks,