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? Do you know of any Android device that requires a USB command like this? > > > > 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. > > > > 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. > > > > Under what circumstances would these messages need to get sent? > > > > > > User-space would control it by changing the device's > > > POWER_SUPPLY_PROP_CHARGE_TYPE to "Fast", if available. > > > > > > eg. > > > # echo "Fast" > /sys/devices/pci0000:00/0000:00:14.0/usb3/3- > > > 1/power_supply/apple_mfi_fastcharge/charge_type > > > > power_supply class is for the power supply that is charging the cpu > > you > > type that on. Not for the cpu of an attached device, right? > > Again, power_supply class has a scope attached to it, so having the > driver in the kernel would actually make it easier, with user-space not > having to care whether the device uses an "Apple" method or something > else. Again, power_supply is for the power being sent to the host computer, right? I don't think it is for power being sent from the host to another device, are you sure it is set up to control/monitor/handle that type of thing? I do know that there are some USB power control things that probably should be tied into the power_supply logic sometime soon, but I do not know if that plumbing has been put into place yet in the power_supply class code. Do you know if it has? thanks, greg k-h
