| Message ID | 20210622141454.337948-1-hannu@hrtk.in (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 4897807753e078655a78de39ed76044d784f3e63 |
| Headers | show |
| Series | USB: cdc-acm: blacklist Heimann USB Appset device | expand |
On Tue, Jun 22, 2021 at 05:14:54PM +0300, Hannu Hartikainen wrote: > The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be > a CDC-ACM device in its descriptors but in fact is not. If it is run > with echo disabled it returns garbled data, probably due to something > that happens in the TTY layer. And when run with echo enabled (the > default), it will mess up the calibration data of the sensor the first > time any data is sent to the device. > > In short, I had a bad time after connecting the sensor and trying to get > it to work. I hope blacklisting it in the cdc-acm driver will save > someone else a bit of trouble. > > Signed-off-by: Hannu Hartikainen <hannu@hrtk.in> > --- > > This is my first time submitting a patch. I hope I'll be able to submit > a driver for this device later. The device is a microcontroller-based > USB implementation/converter for a thermal camera that communicates over > SPI. > > drivers/usb/class/cdc-acm.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c > index ca7a61190dd9..d50b606d09aa 100644 > --- a/drivers/usb/class/cdc-acm.c > +++ b/drivers/usb/class/cdc-acm.c > @@ -1959,6 +1959,11 @@ static const struct usb_device_id acm_ids[] = { > .driver_info = IGNORE_DEVICE, > }, > > + /* Exclude Heimann Sensor GmbH USB appset demo */ > + { USB_DEVICE(0x32a7, 0x0000), > + .driver_info = IGNORE_DEVICE, > + }, > + If it's blacklisted here, what driver does control this device? thanks, greg k-h
On Tue, 22 Jun 2021 21:54:31 +0200, Greg KH <gregkh@linuxfoundation.org> wrote:
> If it's blacklisted here, what driver does control this device?
On my machine, no other device driver takes control. The `usbcore`
driver loads the `cdc-acm` driver because the descriptors match but
after cdc-acm returns without claiming the interfaces, no other driver
is probed AFAICT.
I've written an incomplete driver myself; I'll see if I can publish it
later. But the traffic is just USB bulk messages and should be doable in
userspace without a driver. Sadly the devices are not very common and
the USB traffic is undocumented.
Best,
Hannu
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index ca7a61190dd9..d50b606d09aa 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1959,6 +1959,11 @@ static const struct usb_device_id acm_ids[] = { .driver_info = IGNORE_DEVICE, }, + /* Exclude Heimann Sensor GmbH USB appset demo */ + { USB_DEVICE(0x32a7, 0x0000), + .driver_info = IGNORE_DEVICE, + }, + /* control interfaces without any protocol set */ { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM, USB_CDC_PROTO_NONE) },
The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be a CDC-ACM device in its descriptors but in fact is not. If it is run with echo disabled it returns garbled data, probably due to something that happens in the TTY layer. And when run with echo enabled (the default), it will mess up the calibration data of the sensor the first time any data is sent to the device. In short, I had a bad time after connecting the sensor and trying to get it to work. I hope blacklisting it in the cdc-acm driver will save someone else a bit of trouble. Signed-off-by: Hannu Hartikainen <hannu@hrtk.in> --- This is my first time submitting a patch. I hope I'll be able to submit a driver for this device later. The device is a microcontroller-based USB implementation/converter for a thermal camera that communicates over SPI. drivers/usb/class/cdc-acm.c | 5 +++++ 1 file changed, 5 insertions(+)