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
