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.

Sdig
  • 71
  • 4

1 Answers1

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.

Sdig
  • 71
  • 4