* Driver for something that's neither a device nor an interface driver?
@ 2019-09-27 17:29 Bastien Nocera
2019-09-27 17:38 ` Greg KH
2019-09-27 17:56 ` Alan Stern
0 siblings, 2 replies; 15+ messages in thread
From: Bastien Nocera @ 2019-09-27 17:29 UTC (permalink / raw)
To: linux-usb; +Cc: benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 17:29 Driver for something that's neither a device nor an interface driver? Bastien Nocera
@ 2019-09-27 17:38 ` Greg KH
2019-09-27 17:44 ` Bastien Nocera
2019-09-27 17:56 ` Alan Stern
1 sibling, 1 reply; 15+ messages in thread
From: Greg KH @ 2019-09-27 17:38 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 17:38 ` Greg KH
@ 2019-09-27 17:44 ` Bastien Nocera
2019-09-27 18:57 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Bastien Nocera @ 2019-09-27 17:44 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, benjamin.tissoires
[-- 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)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 17:29 Driver for something that's neither a device nor an interface driver? Bastien Nocera
2019-09-27 17:38 ` Greg KH
@ 2019-09-27 17:56 ` Alan Stern
2019-09-27 18:49 ` Bastien Nocera
1 sibling, 1 reply; 15+ messages in thread
From: Alan Stern @ 2019-09-27 17:56 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 17:56 ` Alan Stern
@ 2019-09-27 18:49 ` Bastien Nocera
2019-09-27 19:25 ` Greg KH
2019-09-27 20:21 ` Alan Stern
0 siblings, 2 replies; 15+ messages in thread
From: Bastien Nocera @ 2019-09-27 18:49 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, benjamin.tissoires
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 17:44 ` Bastien Nocera
@ 2019-09-27 18:57 ` Greg KH
2019-09-27 19:08 ` Bastien Nocera
0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2019-09-27 18:57 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 18:57 ` Greg KH
@ 2019-09-27 19:08 ` Bastien Nocera
0 siblings, 0 replies; 15+ messages in thread
From: Bastien Nocera @ 2019-09-27 19:08 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 18:49 ` Bastien Nocera
@ 2019-09-27 19:25 ` Greg KH
2019-09-27 20:12 ` Bastien Nocera
2019-09-27 20:21 ` Alan Stern
1 sibling, 1 reply; 15+ messages in thread
From: Greg KH @ 2019-09-27 19:25 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Alan Stern, linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 19:25 ` Greg KH
@ 2019-09-27 20:12 ` Bastien Nocera
2019-09-28 7:39 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Bastien Nocera @ 2019-09-27 20:12 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Stern, linux-usb, benjamin.tissoires
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 18:49 ` Bastien Nocera
2019-09-27 19:25 ` Greg KH
@ 2019-09-27 20:21 ` Alan Stern
1 sibling, 0 replies; 15+ messages in thread
From: Alan Stern @ 2019-09-27 20:21 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-27 20:12 ` Bastien Nocera
@ 2019-09-28 7:39 ` Greg KH
2019-09-28 10:42 ` Bastien Nocera
0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2019-09-28 7:39 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Alan Stern, linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-28 7:39 ` Greg KH
@ 2019-09-28 10:42 ` Bastien Nocera
2019-09-28 12:18 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Bastien Nocera @ 2019-09-28 10:42 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Stern, linux-usb, benjamin.tissoires
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-28 10:42 ` Bastien Nocera
@ 2019-09-28 12:18 ` Greg KH
2019-09-28 12:37 ` Bastien Nocera
0 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2019-09-28 12:18 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Alan Stern, linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-28 12:18 ` Greg KH
@ 2019-09-28 12:37 ` Bastien Nocera
2019-09-28 12:57 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Bastien Nocera @ 2019-09-28 12:37 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Stern, linux-usb, benjamin.tissoires
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Driver for something that's neither a device nor an interface driver?
2019-09-28 12:37 ` Bastien Nocera
@ 2019-09-28 12:57 ` Greg KH
0 siblings, 0 replies; 15+ messages in thread
From: Greg KH @ 2019-09-28 12:57 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Alan Stern, linux-usb, benjamin.tissoires
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-09-28 12:57 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-27 17:29 Driver for something that's neither a device nor an interface driver? Bastien Nocera
2019-09-27 17:38 ` Greg KH
2019-09-27 17:44 ` Bastien Nocera
2019-09-27 18:57 ` Greg KH
2019-09-27 19:08 ` Bastien Nocera
2019-09-27 17:56 ` Alan Stern
2019-09-27 18:49 ` Bastien Nocera
2019-09-27 19:25 ` Greg KH
2019-09-27 20:12 ` Bastien Nocera
2019-09-28 7:39 ` Greg KH
2019-09-28 10:42 ` Bastien Nocera
2019-09-28 12:18 ` Greg KH
2019-09-28 12:37 ` Bastien Nocera
2019-09-28 12:57 ` Greg KH
2019-09-27 20:21 ` Alan Stern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).