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. > 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. > 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. > 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 > What > piece of code is responsible for them? In user-space? Hasn't been decided yet, but I can imagine a policy daemon that cares about what devices charge from which other device, and how fast. For example, a laptop in "low power mode" wouldn't want to fast charge a phone, if the only reason the phone was plugged in was to fetch some data off of it, for example. > If necessary, you can modify the core/generic.c driver. However > that > might not be the right approach, considering that this is meant only > for devices manufactured by Apple. It's also used by at least one Blackberry device, and I can imagine other vendors having similar "APIs" to work-around USB 1.x charging current limits. I take it that by saying "modify core/generic.c" driver you mean that it's not possible to inherit from it, right?
