Re: Driver for something that's neither a device nor an interface driver?

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, Sep 28, 2019 at 12:42:21PM +0200, Bastien Nocera wrote:
> On Sat, 2019-09-28 at 09:39 +0200, Greg KH wrote:
> > On Fri, Sep 27, 2019 at 10:12:14PM +0200, Bastien Nocera wrote:
> > > On Fri, 2019-09-27 at 21:25 +0200, Greg KH wrote:
> > > > On Fri, Sep 27, 2019 at 08:49:12PM +0200, Bastien Nocera wrote:
> > > > > On Fri, 2019-09-27 at 13:56 -0400, Alan Stern wrote:
> > > > > <snip>
> > > > > > Is there any reason this needs to be done in a kernel driver?
> > > > > 
> > > > > To offer a unified interface all the devices with similar
> > > > > needs.
> > > > 
> > > > What "other devices with similar needs?"
> > > 
> > > I would expect Android phones to be able to offer up a different
> > > charging method depending on policy, and wanting to be able to
> > > switch
> > > charging methods.
> > 
> > I doubt it, it "should" be automatic based on the USB hardware
> > configurations in the charger, not based on a random undocumented USB
> > command sent from the host.  The USB spec describes how to do all of
> > this properly without any commands at all, why not just rely on that?
> 
> That's not true, no. Until USB PD, there wasn't a way any ways for
> devices to know that they could draw more current without either being
> told so (as is done here), hardware modifications (with resistors being
> wired to GND/VCC), or violating the USB spec.

It is the resistor thing.  And other "tricks" that hardware could play.
My 3 year old phone could go into "high power" charging if it could
figure out if it was connected to the special charger that came with it.
All of that was done outside of the USB protocol stack, using hardware
tricks.

And all of that not USB PD.

> In this case, Apple worked around the problem by having their OS,
> running on their hardware, tell their peripherals to draw more power,
> because the spec didn't allow this.

And because Apple "knew" that their laptops could provide that kind of
power.  How do you know that a random USB hub can provide that properly?

> Those 2 articles should help understand the complexities of the
> problem:
> https://lwn.net/Articles/693027/
> https://lwn.net/Articles/694062/

Those are all from the viewpoint of Linux running on the device itself,
not Linux running on the host like you are talking about here.

> > > > > >   Can it 
> > > > > > be handled from userspace instead?
> > > > > 
> > > > > It could, at a great infrastructure cost, trying to get buy-in
> > > > > from
> > > > > various distributions, at the very least.
> > > > 
> > > > For USB devices that _can_ be handled in userspace, we ask that
> > > > they
> > > > be
> > > > done in userspace and not with a kernel driver.  Something that
> > > > only
> > > > does usb control messages with no other in-kernel api interfaces
> > > > is
> > > > ripe
> > > > for a tiny userspace program using libusb.  Not for an in-kernel
> > > > driver.
> > > 
> > > I don't quite understand why that would be when the kernel already
> > > offers the API to be able to control it.
> > 
> > Again, if it _can_ be done in userspace, it _should_ be done in
> > userspace when it comes to USB drivers/commands.
> 
> That's clear enough, although I still think it's wrong to try and move
> to user-space things that have an existing clearly defined API in
> kernel space. This would be akin to not allowing any new drivers for
> webcams or USB sound cards because "they can be done in user-space".
> Sure they can, but there's already an established API to handle them in
> the kernel.

Again, the power_supply api is for power going the other way in the
system.  That's not an "existing clearly defined API in kernel space".

> > > > > > You said this was for a "power supply" class driver.  It's
> > > > > > not
> > > > > > clear 
> > > > > > what that means -- the devices you want to communicate with
> > > > > > are 
> > > > > > iphones, ipads, etc., not power supplies.
> > > > > 
> > > > > There's tons of "device" scope "power_supply" devices in the
> > > > > kernel,
> > > > > which don't power the Linux machine they're running on. Grep
> > > > > for
> > > > > "POWER_SUPPLY_SCOPE_DEVICE" in the kernel, most wireless mice
> > > > > and
> > > > > keyboards implement this already.
> > > > 
> > > > Yes, but those are real devices that the "Host" uses for power or
> > > > something else.  wireless mice and keyboards already have kernel
> > > > drivers
> > > > so that's fine as well (but probably could be done from userspace
> > > > too.)
> > > 
> > > It probably couldn't when the pipes to get key presses and the
> > > battery
> > > info are the same.
> > 
> > Are you sure?  They are really part of the USB HID spec?  Do you have
> > pointers to that, for some reason I thought those were "out-of-band"
> > vendor specific commands.
> 
> They're not part of the HID spec, but they don't have to be out-of-
> band, or separate from the rest of the communication.

If they are not separate then they are not part of the HID driver bound
to that interface, so userspace can communicate just fine with the
endpoint that does require that custom command.

Have you looked at how that power setting is transfered to userspace
today?  Is it done in a kernel driver or just using libusb?

Anyway, we will be glad to review code if you submit it, but again,
remember that we might say it is better to just do this in userspace,
like we have done for many other submissions in the past.

Note, there is the "fun" idea of using eBPF to run userspace USB drivers
from a kernel module that I have had for a year or so, and want to get
around to trying to do.  But that's probably _way_ outside the scope of
what you are thinking of doing here...

thanks,

greg k-h