5

Short background on the issue I'm facing. I'm working on implementing a simultaneous UART/I2C operation using a usb bridge, the FT260. The chip relies on HID reports to provide these functionalities. Plugged in, the hid-generic driver detects two interfaces, 0 and 1, the first is for I2C and the second is for UART. Currently, I have the FT260 driver supporting I2C only loaded as a module (i.e., hid-ft260) and it works fine. Then the latter takes over hid-generic and I think the usbhid is responsible for that. lsusb -t returns:

|__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M

dmesg shows the following during boot-up:

hid-generic 0003:0403:6030.0001: hidraw0: USB HID v1.11 Device [FTDI FT260] on usb-xhci-hcd.1.auto-1.2
hid-generic 0003:0403:6030.0002: hidraw1: USB HID v1.11 Device [FTDI FT260] on usb-xhci-hcd.1.auto-1.2
ft260 0003:0403:6030.0001: hidraw0: USB HID v1.11 Device [FTDI FT260] on usb-xhci-hcd.1.auto-1.2/input
ft260 0003:0403:6030.0002: hidraw1: USB HID v1.11 Device [FTDI FT260] on usb-xhci-hcd.1.auto-1.2/input

For UART, I had to use an application that works with the hid-generic. While the driver for I2C can be extended to support UART, maybe as virtual COM port, but it's not that trivial (at least I think) plus I have a working code that I'd like to use and carry on with the rest of the project.

When I try to unbind the interface UART using the following command:

echo -n 0003:0403:6030.0002 > /sys/bus/hid/drivers/ft260/unbind

I can see the binding is gone. However, when I try to bind the exact interface (if 1) to hid-generic

echo -n 0003:0403:6030.0002 > /sys/bus/hid/drivers/hid-generic/bind

I get:

-bash: echo: write error: No such device

hid-generic gets loaded automatically (hot-plug) though when I unload the module hid-ft260 using:

modprobe -r hid-ft260

It sounds like the usbhid locks to a single sub driver at a time based on PID and VID, but could be something else. If you have insights on bypassing this, that'll be very helpful. Thank you.

1 Answer 1

2

Alright, I add the answer that worked for me. So it turns out that hid-generic provides a callback function (kernel 5.4.70) namely hid_generic_matchthat accepts a second bool parameter ignore_special_driver. If this is set (ignore_special_driver=1), then the matching function returns true and the probing takes place. After this, the hid-generic allows to link with the ft260's uart interface. usbhid had nothing to do with it after all.

For my setup, the modules hid-generic and hid-ft260 start after rebooting with hid-ft260 controlling both interfaces. So to work around the issue posted above I do the following:

echo 1 > /sys/module/hid/parameters/ignore_special_drivers
echo -n "0003:0403:6030.0002" > /sys/bus/hid/drivers/ft260/unbind

Because of hotplug, hid-generic is probed successfully on the available HID-UART interface:

hid-generic 0003:0403:6030.0002: hidraw1: USB HID v1.11 Device [FTDI FT260] on usb-xhci-hcd.1.auto-1.2/input1

The binding can also be checked as:

root@root:~# ls /sys/bus/hid/drivers/ft260/
0003:0403:6030.0001  bind  module  new_id  uevent  unbind
root@root:~# ls /sys/bus/hid/drivers/hid-generic/
0003:0403:6030.0002  bind  module  new_id  uevent  unbind

A udev rule can be created to automate this.

Remark: If ignore_special_driver=1 before probing hid-ft260, the ft260 driver would not bind to either interface, despite the matching VID and PID.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .