mbox series

[RFC,0/4] USB Power Delivery character device interface

Message ID 20211026143352.78387-1-heikki.krogerus@linux.intel.com (mailing list archive)
Headers show
Series USB Power Delivery character device interface | expand

Message

Heikki Krogerus Oct. 26, 2021, 2:33 p.m. UTC 
Hi,

This is the proposal for USB PD character devices that we could use to
communicate USB PD messages directly with the USB PD capable partners,
ports and cable plugs from user space. Originally I proposed this idea
here as a better way to get the PDOs from the partners (and ports and
plugs): https://lkml.org/lkml/2021/10/8/331

Initially you could read the PDOs with this, but it of course is not
only limited to PDOs - any messages should potentetially be suported.

This is in any case really just a draft, and most likely does not work
if you try it, but it should give an idea about what I'm proposing
(hopefully).

In this proposal I'm placing each device that you can have
behind a single USB PD capable Type-C port (so port, partner
and plugs) under its own folder, so you would end up with
something like this if also both plugs are supported:

	/dev/pd0/port
	/dev/pd0/plug0
	/dev/pd0/plug1
	/dev/pd0/partner

I'm also including an ugly test tool that you can try out to dump the
PDOs depending on the role of the device - tools/usb/pd-test.c. This
is what I got from a charger (and the port at the same time):

	% pd-test /dev/pd0/port
	Sink Capabilities:
	  PDO1: 0x3601912c
	  PDO2: 0x000640e1
	  PDO3: 0x9901912c

	% pd-test /dev/pd0/partner
	Source Capabilities:
	  PDO1: 0x0801912c
	  PDO2: 0x0003c12c

But please note that this whole series is really just meant to be PoC!
Don't assume it will work!

The core code that adds the character devices is here:

	drivers/usb/typec/pd-dev.c.

It's actually really simple, and I don't think it would ever need to
be much more complicated than that.

Example driver support I added to UCSI:

	drivers/usb/typec/ucsi/pd-dev.c

thanks,

Heikki Krogerus (4):
  usb: pd: uapi header split
  usb: typec: Character device for USB Power Delivery devices
  usb: typec: ucsi: Add support for PD cdev
  tools: usb: Hideous test tool for USB PD char device

 .../userspace-api/ioctl/ioctl-number.rst      |   1 +
 drivers/usb/typec/Makefile                    |   2 +-
 drivers/usb/typec/class.c                     |  42 ++
 drivers/usb/typec/class.h                     |   4 +
 drivers/usb/typec/pd-dev.c                    | 210 ++++++++
 drivers/usb/typec/pd-dev.h                    |  15 +
 drivers/usb/typec/ucsi/Makefile               |   2 +-
 drivers/usb/typec/ucsi/pd-dev.c               | 125 +++++
 drivers/usb/typec/ucsi/ucsi.c                 |  37 +-
 drivers/usb/typec/ucsi/ucsi.h                 |   7 +
 include/linux/usb/pd.h                        | 487 +----------------
 include/linux/usb/pd_dev.h                    |  22 +
 include/linux/usb/typec.h                     |   8 +
 include/uapi/linux/usb/pd.h                   | 496 ++++++++++++++++++
 include/uapi/linux/usb/pd_dev.h               |  55 ++
 tools/usb/Build                               |   1 +
 tools/usb/Makefile                            |   8 +-
 tools/usb/pd-test.c                           | 123 +++++
 18 files changed, 1147 insertions(+), 498 deletions(-)
 create mode 100644 drivers/usb/typec/pd-dev.c
 create mode 100644 drivers/usb/typec/pd-dev.h
 create mode 100644 drivers/usb/typec/ucsi/pd-dev.c
 create mode 100644 include/linux/usb/pd_dev.h
 create mode 100644 include/uapi/linux/usb/pd.h
 create mode 100644 include/uapi/linux/usb/pd_dev.h
 create mode 100644 tools/usb/pd-test.c

Comments

Greg KH Oct. 26, 2021, 3:06 p.m. UTC | #1 
On Tue, Oct 26, 2021 at 05:33:48PM +0300, Heikki Krogerus wrote:
> Hi,
> 
> This is the proposal for USB PD character devices that we could use to
> communicate USB PD messages directly with the USB PD capable partners,
> ports and cable plugs from user space. Originally I proposed this idea
> here as a better way to get the PDOs from the partners (and ports and
> plugs): https://lkml.org/lkml/2021/10/8/331

You should put the info there (and please use lore.kernel.org in the
future, not lkml.org as we have no control over that site), into this
0/X message as I have no idea _why_ you need a char device and why the
sysfs interface will not work.

So, why not sysfs?  :)

thanks,

greg k-h
Heikki Krogerus Oct. 27, 2021, 11:02 a.m. UTC | #2 
Hi Greg,

On Tue, Oct 26, 2021 at 05:06:28PM +0200, Greg KH wrote:
> So, why not sysfs?  :)

This is about allowing the user space to take over the USB Power
Delivery communication and policy decisions in some cases. The user
space needs to be able to send and receive raw USB Power Delivery
messages one way or the other. I don't care about what's the interface
that we use.

Here we are talking about the PDOs, so basically the power contract.
Even if we figured out a way how to expose all the information from
the Capability, Status, Alert and what ever messages you need to the
user space via sysfs, and then allow the user to separately send the
Request Message, we would have only covered the power contract. That
does not cover everything, but it would also be unnecessarily
complicated to handle with separate sysfs files IMO.

Even with the power contract it would make more sense to me to just
allow the user space to simply read and write the raw messages, but
when we go the other things like Vendor Specific Messages, I don't
think there is any other way.

So we really do need to be able to tap into the USB Power Delivery
protocol layer directly from user space. I don't care about how we do
that - character device is just a suggestion, although, it does still
feel correct to me. Is there some other way we could do this?


thanks,
Greg KH Oct. 27, 2021, 12:53 p.m. UTC | #3 
On Wed, Oct 27, 2021 at 02:02:42PM +0300, Heikki Krogerus wrote:
> Hi Greg,
> 
> On Tue, Oct 26, 2021 at 05:06:28PM +0200, Greg KH wrote:
> > So, why not sysfs?  :)
> 
> This is about allowing the user space to take over the USB Power
> Delivery communication and policy decisions in some cases. The user
> space needs to be able to send and receive raw USB Power Delivery
> messages one way or the other. I don't care about what's the interface
> that we use.
> 
> Here we are talking about the PDOs, so basically the power contract.
> Even if we figured out a way how to expose all the information from
> the Capability, Status, Alert and what ever messages you need to the
> user space via sysfs, and then allow the user to separately send the
> Request Message, we would have only covered the power contract. That
> does not cover everything, but it would also be unnecessarily
> complicated to handle with separate sysfs files IMO.
> 
> Even with the power contract it would make more sense to me to just
> allow the user space to simply read and write the raw messages, but
> when we go the other things like Vendor Specific Messages, I don't
> think there is any other way.
> 
> So we really do need to be able to tap into the USB Power Delivery
> protocol layer directly from user space. I don't care about how we do
> that - character device is just a suggestion, although, it does still
> feel correct to me. Is there some other way we could do this?

Ok, a char device sounds fine, but _what_ userspace code is going to be
using this interface?  We need to have a working version of that as well
before we could take this new interface, otherwise it wouldn't make much
sense.

And why does userspace have to do this, what is wrong with the kernel
doing it as it does today?  I.e. what is broken that adding a new api to
the kernel is going to fix?

That needs to be documented really really well.

thanks,

greg k-h
Heikki Krogerus Oct. 28, 2021, 7:17 a.m. UTC | #4 
On Wed, Oct 27, 2021 at 02:53:57PM +0200, Greg KH wrote:
> On Wed, Oct 27, 2021 at 02:02:42PM +0300, Heikki Krogerus wrote:
> > Hi Greg,
> > 
> > On Tue, Oct 26, 2021 at 05:06:28PM +0200, Greg KH wrote:
> > > So, why not sysfs?  :)
> > 
> > This is about allowing the user space to take over the USB Power
> > Delivery communication and policy decisions in some cases. The user
> > space needs to be able to send and receive raw USB Power Delivery
> > messages one way or the other. I don't care about what's the interface
> > that we use.
> > 
> > Here we are talking about the PDOs, so basically the power contract.
> > Even if we figured out a way how to expose all the information from
> > the Capability, Status, Alert and what ever messages you need to the
> > user space via sysfs, and then allow the user to separately send the
> > Request Message, we would have only covered the power contract. That
> > does not cover everything, but it would also be unnecessarily
> > complicated to handle with separate sysfs files IMO.
> > 
> > Even with the power contract it would make more sense to me to just
> > allow the user space to simply read and write the raw messages, but
> > when we go the other things like Vendor Specific Messages, I don't
> > think there is any other way.
> > 
> > So we really do need to be able to tap into the USB Power Delivery
> > protocol layer directly from user space. I don't care about how we do
> > that - character device is just a suggestion, although, it does still
> > feel correct to me. Is there some other way we could do this?
> 
> Ok, a char device sounds fine, but _what_ userspace code is going to be
> using this interface?  We need to have a working version of that as well
> before we could take this new interface, otherwise it wouldn't make much
> sense.
> 
> And why does userspace have to do this, what is wrong with the kernel
> doing it as it does today?  I.e. what is broken that adding a new api to
> the kernel is going to fix?
> 
> That needs to be documented really really well.

Sure.

thanks,