Re: [RFC PATCH 0/4] USB Power Delivery character device interface

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

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,

-- 
heikki