lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 28 Oct 2021 10:17:11 +0300
From:   Heikki Krogerus <>
To:     Greg KH <>
Cc:     Prashant Malani <>,
        Benson Leung <>,
        Adam Thomson <>,
        Guenter Roeck <>,
        Badhri Jagan Sridharan <>,
        Jack Pham <>,
        "Gopal, Saranya" <>,
        "Regupathy, Rajaram" <>,,
Subject: Re: [RFC PATCH 0/4] USB Power Delivery character device interface

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.




Powered by blists - more mailing lists