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

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

[Bastien Nocera]

Hey,

I'm trying to write a "power supply" class driver for Apple MFi
devices, and struggling a little with the USB drivers.

To ask many Apple devices to draw more power, we need to make a call to
the device using a vendor command. It doesn't go to an interface, but
to the device itself.

The call done in the kernel would look something like:
usb_control_msg(mfi->udev, usb_sndctrlpipe(mfi->udev, 0), 
                0x40, /* Vendor-defined USB get enabled capabilities request. */
                USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
                current_ma, /* wValue, current offset */
                current_ma, /* wIndex, current offset */
                NULL, 0, USB_CTRL_GET_TIMEOUT);

But I can't figure out what type of driver I'd need to just be able to
export that power_supply interface.

Trying to use a "struct usb_device_driver" didn't work as probe
functions were never called, and a "struct usb_driver" gets unbound
after user-space and the ipheth drivers comes around.

This is my "struct usb_driver" attempt:
https://github.com/hadess/apple-mfi-fastcharge

Any ideas what type of driver, or what trick I should be using here?

Cheers

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

[Greg KH]

On Fri, Sep 27, 2019 at 07:29:52PM +0200, Bastien Nocera wrote:
> Hey,
> 
> I'm trying to write a "power supply" class driver for Apple MFi
> devices, and struggling a little with the USB drivers.
> 
> To ask many Apple devices to draw more power, we need to make a call to
> the device using a vendor command. It doesn't go to an interface, but
> to the device itself.
> 
> The call done in the kernel would look something like:
> usb_control_msg(mfi->udev, usb_sndctrlpipe(mfi->udev, 0), 
>                 0x40, /* Vendor-defined USB get enabled capabilities request. */
>                 USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
>                 current_ma, /* wValue, current offset */
>                 current_ma, /* wIndex, current offset */
>                 NULL, 0, USB_CTRL_GET_TIMEOUT);
> 
> But I can't figure out what type of driver I'd need to just be able to
> export that power_supply interface.
> 
> Trying to use a "struct usb_device_driver" didn't work as probe
> functions were never called, and a "struct usb_driver" gets unbound
> after user-space and the ipheth drivers comes around.

What does the usb descriptors for the device look like?  Is it only the
"default" control endpoint and no interfaces?  What does the output of
'usbdevices' show for the device?

Normally you just bind to the "default" interface for the device, and
all is good, there should be a few other drivers in the tree that do
this, but I can't think of one off the top of my head at the moment.

thanks,

greg k-h

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

[Bastien Nocera]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Fri, 2019-09-27 at 19:38 +0200, Greg KH wrote:
> What does the usb descriptors for the device look like?  Is it only
> the
> "default" control endpoint and no interfaces?  What does the output
> of
> 'usbdevices' show for the device?

The device in question can be an iPhone, an iPod Classic/Nano, or an
iPad, amongst others, and they usually have useful interfaces, such as
mass storage for the older ones, or ethernet, PTP, etc.

> Normally you just bind to the "default" interface for the device, and
> all is good, there should be a few other drivers in the tree that do
> this, but I can't think of one off the top of my head at the moment.

All the interfaces (in the different configurations) are used for
something in the case of the iPhone 6S I'm trying to use.

I've attached the output of "lsusb -v" for the device below.

[-- Attachment #2: iphone6s.txt --]
[-- Type: text/plain, Size: 16227 bytes --]


Bus 003 Device 010: ID 05ac:12a8 Apple, Inc. iPhone5/5C/5S/6
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x05ac Apple, Inc.
  idProduct          0x12a8 iPhone5/5C/5S/6
  bcdDevice            8.01
  iManufacturer           1 Apple Inc.
  iProduct                2 iPhone
  iSerial                 3
  bNumConfigurations      4
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          5 PTP
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         6 Imaging
      bInterfaceSubClass      1 Still Image Capture
      bInterfaceProtocol      1 Picture Transfer Protocol (PIMA 15470)
      iInterface             18 PTP
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              10
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0095
    bNumInterfaces          3
    bConfigurationValue     2
    iConfiguration          6 iPod USB Interface
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x001e
        bInCollection           1
        baInterfaceNr(0)        1
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             1
        wTerminalType      0x0201 Microphone
        bAssocTerminal          2
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             2
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          1
        bSourceID               1
        iTerminal               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           2
        bDelay                  1 frames
        wFormatTag         0x0001 PCM
      AudioStreaming Interface Descriptor:
        bLength                35
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            9 Discrete
        tSamFreq[ 0]         8000
        tSamFreq[ 1]        11025
        tSamFreq[ 2]        12000
        tSamFreq[ 3]        16000
        tSamFreq[ 4]        22050
        tSamFreq[ 5]        24000
        tSamFreq[ 6]        32000
        tSamFreq[ 7]        44100
        tSamFreq[ 8]        48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00c0  1x 192 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioStreaming Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x01
            Sampling Frequency
          bLockDelayUnits         0 Undefined
          wLockDelay         0x0000
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     208
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x003e
    bNumInterfaces          2
    bConfigurationValue     3
    iConfiguration          7 PTP + Apple Mobile Device
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         6 Imaging
      bInterfaceSubClass      1 Still Image Capture
      bInterfaceProtocol      1 Picture Transfer Protocol (PIMA 15470)
      iInterface             18 PTP
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    254 
      bInterfaceProtocol      2 
      iInterface             13 Apple USB Multiplexor
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0075
    bNumInterfaces          3
    bConfigurationValue     4
    iConfiguration          8 PTP + Apple Mobile Device + Apple USB Ethernet
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         6 Imaging
      bInterfaceSubClass      1 Still Image Capture
      bInterfaceProtocol      1 Picture Transfer Protocol (PIMA 15470)
      iInterface             18 PTP
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    254 
      bInterfaceProtocol      2 
      iInterface             13 Apple USB Multiplexor
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    253 
      bInterfaceProtocol      1 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    253 
      bInterfaceProtocol      1 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       2
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    253 
      bInterfaceProtocol      1 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      4
Device Status:     0x0000
  (Bus Powered)

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

[Greg KH]

On Fri, Sep 27, 2019 at 07:44:08PM +0200, Bastien Nocera wrote:
> On Fri, 2019-09-27 at 19:38 +0200, Greg KH wrote:
> > What does the usb descriptors for the device look like?  Is it only
> > the
> > "default" control endpoint and no interfaces?  What does the output
> > of
> > 'usbdevices' show for the device?
> 
> The device in question can be an iPhone, an iPod Classic/Nano, or an
> iPad, amongst others, and they usually have useful interfaces, such as
> mass storage for the older ones, or ethernet, PTP, etc.

Ah.  Then why do you have to do this from a kernel driver?  Why can't
you do this from userspace?

> > Normally you just bind to the "default" interface for the device, and
> > all is good, there should be a few other drivers in the tree that do
> > this, but I can't think of one off the top of my head at the moment.
> 
> All the interfaces (in the different configurations) are used for
> something in the case of the iPhone 6S I'm trying to use.
> 
> I've attached the output of "lsusb -v" for the device below.

What about interface "9", the "Apple USB Multiplexor"?  What driver
binds to that thing?  It's a vendor-specific protocol, so there
shouldn't be any class driver assigned to it, unlike most of the other
interfaces.

thanks,

greg k-h

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

[Bastien Nocera]

On Fri, 2019-09-27 at 20:57 +0200, Greg KH wrote:
> On Fri, Sep 27, 2019 at 07:44:08PM +0200, Bastien Nocera wrote:
> > On Fri, 2019-09-27 at 19:38 +0200, Greg KH wrote:
> > > What does the usb descriptors for the device look like?  Is it
> > > only
> > > the
> > > "default" control endpoint and no interfaces?  What does the
> > > output
> > > of
> > > 'usbdevices' show for the device?
> > 
> > The device in question can be an iPhone, an iPod Classic/Nano, or
> > an
> > iPad, amongst others, and they usually have useful interfaces, such
> > as
> > mass storage for the older ones, or ethernet, PTP, etc.
> 
> Ah.  Then why do you have to do this from a kernel driver?  Why can't
> you do this from userspace?

Because the kernel has a well-defined API for doing this sort of thing,
and I'd like device drivers to live in the kernel if they can live in
the kernel, making it easier to point at them when writing a policy
daemon, rather than getting told "I won't be using this daemon because
it uses the wrong language, or the wrong library".

I can imagine other implementation for other vendors once the ball
starts rolling.

> > > Normally you just bind to the "default" interface for the device,
> > > and
> > > all is good, there should be a few other drivers in the tree that
> > > do
> > > this, but I can't think of one off the top of my head at the
> > > moment.
> > 
> > All the interfaces (in the different configurations) are used for
> > something in the case of the iPhone 6S I'm trying to use.
> > 
> > I've attached the output of "lsusb -v" for the device below.
> 
> What about interface "9", the "Apple USB Multiplexor"?  What driver
> binds to that thing?  It's a vendor-specific protocol, so there
> shouldn't be any class driver assigned to it, unlike most of the
> other
> interfaces.

There's a user-space daemon called "usbmuxd" that will unbind it and
claim it. This daemon has the exact same API as this daemon under
macOS, and is a drop-in replacement too.

Finds the right configuration:
https://github.com/libimobiledevice/usbmuxd/blob/master/src/usb.h#L28
https://github.com/libimobiledevice/usbmuxd/blob/master/src/usb.c#L448
and claims it:
https://github.com/libimobiledevice/usbmuxd/blob/master/src/usb.c#L485

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

[Alan Stern]

On Fri, 27 Sep 2019, Bastien Nocera wrote:

> Hey,
> 
> I'm trying to write a "power supply" class driver for Apple MFi
> devices, and struggling a little with the USB drivers.
> 
> To ask many Apple devices to draw more power, we need to make a call to
> the device using a vendor command. It doesn't go to an interface, but
> to the device itself.
> 
> The call done in the kernel would look something like:
> usb_control_msg(mfi->udev, usb_sndctrlpipe(mfi->udev, 0), 
>                 0x40, /* Vendor-defined USB get enabled capabilities request. */
>                 USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
>                 current_ma, /* wValue, current offset */
>                 current_ma, /* wIndex, current offset */
>                 NULL, 0, USB_CTRL_GET_TIMEOUT);
> 
> But I can't figure out what type of driver I'd need to just be able to
> export that power_supply interface.
> 
> Trying to use a "struct usb_device_driver" didn't work as probe
> functions were never called, and a "struct usb_driver" gets unbound
> after user-space and the ipheth drivers comes around.
> 
> This is my "struct usb_driver" attempt:
> https://github.com/hadess/apple-mfi-fastcharge
> 
> Any ideas what type of driver, or what trick I should be using here?

Is there any reason this needs to be done in a kernel driver?  Can it 
be handled from userspace instead?

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.

Under what circumstances would these messages need to get sent?  What 
piece of code is responsible for them?

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.

Alan Stern

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

[Bastien Nocera]

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?

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

[Greg KH]

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

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

[Bastien Nocera]

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.

> > >   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.

> > > 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.

> > > 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.

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

[Greg KH]

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

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

[Bastien Nocera]

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.

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.

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

> Do you know of any Android device that requires a USB command like
> this?

Not that I could find, the Blackberry Q10 did though.

> > > > >   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.

> > > > > 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.

> > > > > 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?

Yes I'm absolutely certain that user-space and the kernel can already
handle devices being powered by the . UPower has had support for
"device" power supply scope since 2012, which means that the kernel
support came before that.

> 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?

I don't know about the state of USB PD support I'm afraid.

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

[Greg KH]

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

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

[Bastien Nocera]

On Sat, 2019-09-28 at 14:18 +0200, Greg KH wrote:
> 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".

No it isn't, not since 2011.

commit 25a0bc2dfc2ea732f40af2dae52426ead66ae76e
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Wed Dec 7 11:24:20 2011 -0800

    power_supply: add SCOPE attribute to power supplies
    
    This adds a "scope" attribute to a power_supply, which indicates how
    much of the system it powers.  It appears in sysfs as "scope" or in
    the uevent file as POWER_SUPPLY_SCOPE=.  There are presently three
    possible values:
            Unknown - unknown power topology
            System - the power supply powers the whole system
            Device - it powers a specific device, or tree of devices
    
    A power supply which doesn't have a "scope" attribute should be assumed to
    have "System" scope.
    
    In general, usermode should assume that loss of all System-scoped power
    supplies will power off the whole system, but any single one is sufficient
    to power the system.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
    Cc: Richard Hughes <richard@hughsie.com>

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

[Greg KH]

On Sat, Sep 28, 2019 at 02:37:21PM +0200, Bastien Nocera wrote:
> On Sat, 2019-09-28 at 14:18 +0200, Greg KH wrote:
> > 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".
> 
> No it isn't, not since 2011.
> 
> commit 25a0bc2dfc2ea732f40af2dae52426ead66ae76e
> Author: Jeremy Fitzhardinge <jeremy@goop.org>
> Date:   Wed Dec 7 11:24:20 2011 -0800
> 
>     power_supply: add SCOPE attribute to power supplies
>     
>     This adds a "scope" attribute to a power_supply, which indicates how
>     much of the system it powers.  It appears in sysfs as "scope" or in
>     the uevent file as POWER_SUPPLY_SCOPE=.  There are presently three
>     possible values:
>             Unknown - unknown power topology
>             System - the power supply powers the whole system
>             Device - it powers a specific device, or tree of devices
>     
>     A power supply which doesn't have a "scope" attribute should be assumed to
>     have "System" scope.
>     
>     In general, usermode should assume that loss of all System-scoped power
>     supplies will power off the whole system, but any single one is sufficient
>     to power the system.
>     
>     Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
>     Cc: Richard Hughes <richard@hughsie.com>
> 

Ah, ok, my fault, then ok, let's see how your kernel driver ties into
this then.

thanks,

greg k-h

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

[Alan Stern]

On Fri, 27 Sep 2019, 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.
> 
> >   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.

As Greg said, we generally prefer it if people do things that way
(assuming it's possible).  As for buy-in from distributions, other
programs such as usb_modeswitch have been widely accepted.  There's no
reason to think yours wouldn't be just as popular.

> > 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.

I actually meant in the kernel.  But you'll probably say that's what 
we're trying to settle in this discussion.

> > 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?

The two don't have to be mutually exclusive.  That is, no, it was never
intended for other drivers to inherit from generic.c (although it was
originally intended that other drivers might _replace_ it in some
situations -- that hasn't worked out in practice).  But in theory you
could modify generic.c in a way that would make inheritance possible.

Or you could allow generic.c to attach "subdrivers" based on matching a
device's VID/PID, and one such subdriver could be your power-supply
manager.

Alan Stern