* 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: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 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 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 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
* 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
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).