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

[Bastien Nocera <hadess@hadess.net>]

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?