Add a skeleton module to perform a basic initialization on certain USB devices
cover Add a skeleton module to perform a basic initialization on certain USB devices
This mini series adds a simple skeleton module whose only purpose is to bring devices that at first appear as a generic USB device into another mode that can be handled by a more specific subsystem.
This patch was originally requested by Dmitry, reasoning that loading the entire xpad module just to switch a Logitech G920 wheel into HID mode is excessive and does not make much sense.
The module can be extended to handle any other USB device that might require such a switch.
Michal Malý (2):
Add usb_skelswitch skeleton module to do basic initialization of
devices that at first appear as a generic USB device.
Use usb_skelswitch module to switch Logitech G920 Racing Wheel to HID
mode.
drivers/usb/Kconfig | 2 + drivers/usb/common/Kconfig | 17 +++++ drivers/usb/common/Makefile | 2 + drivers/usb/common/usb-skelswitch.c | 141 ++++++++++++++++++++++++++++++++++++ 4 files changed, 162 insertions(+) create mode 100644 drivers/usb/common/Kconfig create mode 100644 drivers/usb/common/usb-skelswitch.c
Signature · 1 line
2.7.0
PATCH 1/2 Add usb_skelswitch skeleton module to do basic initialization of devices that at first appear as a generic USB device.
This gets rid of the need to handle such devices in more specific drivers that will be loaded for no purpose other than to do some basic initialization on the device.
--- drivers/usb/Kconfig | 2 + drivers/usb/common/Kconfig | 15 +++++++ drivers/usb/common/Makefile | 2 + drivers/usb/common/usb-skelswitch.c | 81 +++++++++++++++++++++++++++++++++++++ 4 files changed, 100 insertions(+) create mode 100644 drivers/usb/common/Kconfig create mode 100644 drivers/usb/common/usb-skelswitch.c
drivers/usb/Kconfig +2 -0
@@ -78,6 +78,8 @@ if USB source "drivers/usb/core/Kconfig" +source "drivers/usb/common/Kconfig" + source "drivers/usb/mon/Kconfig" source "drivers/usb/wusbcore/Kconfig"
drivers/usb/common/Kconfig new file +15 -0
@@ -0,0 +1,15 @@ +# +# USB common modules +# + +if USB_COMMON + +config USB_SKELSWITCH + tristate "Simple USB module for basic device initialization" + help + Simple module that performs basic initialization on devices that at first + appear as a generic USB device. + + Say Y if you intend to use a device that requires this initial switch. + +endif # USB_COMMON
drivers/usb/common/Makefile +2 -0
@@ -8,3 +8,5 @@ usb-common-$(CONFIG_USB_LED_TRIG) += led.o obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o + +obj-$(CONFIG_USB_SKELSWITCH) += usb-skelswitch.o
drivers/usb/common/usb-skelswitch.c new file +81 -0
81 lines not on this page · raw message
Signature · 1 line
2.7.0
PATCH 2/2 Use usb_skelswitch module to switch Logitech G920 Racing Wheel to HID mode.
In reply to Michal Malý--- drivers/usb/common/Kconfig | 2 ++ drivers/usb/common/usb-skelswitch.c | 60 +++++++++++++++++++++++++++++++++++++ 2 files changed, 62 insertions(+)
drivers/usb/common/Kconfig +2 -0
@@ -11,5 +11,7 @@ config USB_SKELSWITCH appear as a generic USB device. Say Y if you intend to use a device that requires this initial switch. + Devices that currently require this module: + - Logitech G920 Racing Wheel endif # USB_COMMON
drivers/usb/common/usb-skelswitch.c +60 -0
70 lines not on this page · raw message
Signature · 1 line
2.7.0
Quoted 10 lines · Michal Malý
This mini series adds a simple skeleton module whose only purpose is to bring devices that at first appear as a generic USB device into another mode that can be handled by a more specific subsystem.
This patch was originally requested by Dmitry, reasoning that loading the entire xpad module just to switch a Logitech G920 wheel into HID mode is excessive and does not make much sense.
The module can be extended to handle any other USB device that might require such a switch.
Can this switching be done in userspace? That's what we normally do, ref usb_modeswitch.
Bjørn
Quoted 9 lines · On sobota 23. ledna 2016 13:46:32 CET Bjørn Mork wrote:
Quoted 8 lines · Michal Malý
This mini series adds a simple skeleton module whose only purpose is to bring devices that at first appear as a generic USB device into another mode that can be handled by a more specific subsystem.
This patch was originally requested by Dmitry, reasoning that loading the entire xpad module just to switch a Logitech G920 wheel into HID mode is excessive and does not make much sense.
Quoted 5 lines
Quoted 2 lines
The module can be extended to handle any other USB device that might require such a switch.
Can this switching be done in userspace? That's what we normally do, ref
usb_modeswitch.
I briefly considered leaving the switch up to the userspace and handling the device in the kernel only once it's been switched. I am however uncertain how to advertise this to the users. Writing a tiny app that would currently handle just one device seems like an overkill, abusing usb_modeswitch seems counter- intuitive as it's purpose is to handle various USB modems. Having a tiny module in the kernel looks like the most straightforward thing to do as far as user experience is concerned.
I would not object to deferring the switch to userspace as long as there is an easy way how to communicate the need for a small switching tool to the users.
Michal
Greg KH
maintainerQuoted 13 lines · Michal Malý
Quoted 12 lines · On sobota 23. ledna 2016 13:46:32 CET Bjørn Mork wrote:
Quoted 10 lines · Michal Malý
This mini series adds a simple skeleton module whose only purpose is to bring devices that at first appear as a generic USB device into another mode that can be handled by a more specific subsystem.
This patch was originally requested by Dmitry, reasoning that loading the entire xpad module just to switch a Logitech G920 wheel into HID mode is excessive and does not make much sense.
The module can be extended to handle any other USB device that might require such a switch.
Quoted 7 lines
Quoted 2 lines
Can this switching be done in userspace? That's what we normally do, ref
usb_modeswitch.I briefly considered leaving the switch up to the userspace and handling the device in the kernel only once it's been switched. I am however uncertain how to advertise this to the users. Writing a tiny app that would currently handle just one device seems like an overkill,
Writing a kernel driver that can be done in userspace is also overkill :)
Quoted 7 lines
abusing
usb_modeswitchseems counter-
intuitive as it's purpose is to handle various USB modems. Having a tiny module in the kernel looks like the most straightforward thing to do as far as user experience is concerned.I would not object to deferring the switch to userspace as long as there is an easy way how to communicate the need for a small switching tool to the users.
Have your program install a udev rule to make it run automatically when the device is plugged in, and then just file a bug with the different distros to have them pick up your program and add it to their releases. With free services like Github to host the code, and OBS to build packages for every different distro out there, there has never been an easier time to get programs to distros.
So please just do this in userspace, we don't like to take kernel drivers for functions that can be done in userspace.
thanks,
greg k-h
Quoted 11 lines · Greg KH
Have your program install a udev rule to make it run automatically when
the device is plugged in, and then just file a bug with the different distros to have them pick up your program and add it to their releases.
With free services like Github to host the code, and OBS to build packages for every different distro out there, there has never been an easier time to get programs to distros.So please just do this in userspace, we don't like to take kernel drivers for functions that can be done in userspace.
That raises a point. If we wish to do port power switching as a form of runtime PM, we will need to do mode switching in kernel space. The notion that this can be done in user space is likely to become wrong as things develop.
Regards
Oliver
Greg KH
maintainerQuoted 10 lines · Oliver Neukum
Quoted 9 lines · Greg KH
Have your program install a udev rule to make it run automatically when
the device is plugged in, and then just file a bug with the different distros to have them pick up your program and add it to their releases.
With free services like Github to host the code, and OBS to build packages for every different distro out there, there has never been an easier time to get programs to distros.
Quoted 7 lines
Quoted 2 lines
So please just do this in userspace, we don't like to take kernel drivers for functions that can be done in userspace.
That raises a point. If we wish to do port power switching as a form of runtime PM, we will need to do mode switching in kernel space. The notion that this can be done in user space is likely to become wrong as things develop.
Maybe, if a device doesn't remember it's "mode" after sleeping, then it might get messy, it will be interesting to see how that works out over time...
Quoted 14 lines · Greg KH
Quoted 13 lines · Oliver Neukum
Quoted 11 lines · Greg KH
Have your program install a udev rule to make it run automatically when
the device is plugged in, and then just file a bug with the different distros to have them pick up your program and add it to their releases.
With free services like Github to host the code, and OBS to build packages for every different distro out there, there has never been an easier time to get programs to distros.So please just do this in userspace, we don't like to take kernel drivers for functions that can be done in userspace.
Quoted 8 lines
Quoted 4 lines
That raises a point. If we wish to do port power switching as a form of runtime PM, we will need to do mode switching in kernel space. The notion that this can be done in user space is likely to become wrong as things develop.
Maybe, if a device doesn't remember it's "mode" after sleeping, then it might get messy, it will be interesting to see how that works out over time...
We are cutting power. So unless they have a battery or are self powered, I don't see how they could retain their mode. But it is a mess.
Regards
Oliver
Quoted 5 lines · Michal Malý
I briefly considered leaving the switch up to the userspace and handling the device in the kernel only once it's been switched. I am however uncertain how to advertise this to the users. Writing a tiny app that would currently handle just one device seems like an overkill, abusing
usb_modeswitchseems counter- intuitive as it's purpose is to handle various USB modems.
Well, originally usb_modeswitch (beware, it's called "modeswitch", not "modemswitch" :) ) was purely for handling ZeroCD on USB 3G modems, and it's currently still by far the most common case, but there are other devices being handled by that package now; I for example recall some HP printers needing a magic USB command to be sent to it before they would start printing, and usb_modeswitch is handling those now AFAIK.
So if we do this in userspace, I think usb_modeswitch is not a bad choice.
Thanks,
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 23 lines · Jiri Kosina
Quoted 1 line · Michal Malý
I briefly considered leaving the switch up to the userspace and
handling the
Quoted 1 line
device in the kernel only once it's been switched. I am however
uncertain how
Quoted 1 line
to advertise this to the users. Writing a tiny app that would
currently handle
Quoted 1 line
just one device seems like an overkill, abusing
usb_modeswitchseems counter-
Quoted 1 line
intuitive as it's purpose is to handle various USB modems.
Well, originally
usb_modeswitch(beware, it's called "modeswitch", not
"modemswitch" :) ) was purely for handling ZeroCD on USB 3G modems, and
it's currently still by far the most common case, but there are other
devices being handled by that package now; I for example recall some HP printers needing a magic USB command to be sent to it before they would
start printing, andusb_modeswitchis handling those now AFAIK.
Quoted 2 lines
So if we do this in userspace, I think
usb_modeswitchis not a bad choice.
Ok, that's interesting... I tinkered with usb_modeswitch a bit and I made it switch the G920 just fine after a while. Consider the patches dropped then, letting usb_modeswitch take care of this sounds reasonable.
Michal