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?" > > 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. > > 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.) > > 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? thanks, greg k-h
