Kernel module is `hb_rf_usb_2` instead of `hb_rf_usb-2`

[agross]

I just tried to use a HB-RF-USB-2 for the first time on my host.

detect_hardware.inc was unable to find or use the device because the kernel module is called hb_rf_usb_2 instead of hb_rf_usb-2.

$ uname -a
Linux raspberrypi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux

$ lsmod | grep hb_rf
hb_rf_usb_2            24576  3

[alexreinert]

As the Kernel Module binary is named hb_rf_usb-2.so the kernel module will be loaded with the current code and it will be loaded by udev directly when the matching usb id is detected. So changing the mentioned code line will not solve your problem. There did you get the HB-RF-USB-2 from? Can you provide pictures of it? What USB cable do you use? What hardware platform do you use? How do you power the hardware? Please provide output of the command dmesg | grep "hb".

[agross]

$ dmesg | grep "hb"
                  24:   [    0.000000] CPU features: detected: Spectre-BHB
                 279:   [    3.369487] usb 1-1.1: Product: HB-RF-USB-2
                 454:   [    9.325255] usb 1-1.1: Found HB-RF-USB-2 with serial 00db28fe2ec1e8118dad6b713b0549ec at usb-0000:01:00.0-1.1
                 468:   [    9.517985] raw-uart raw-uart: Registered new raw-uart device using underlying device HB-RF-USB-2@usb-0000:01:00.0-1.1.
                 469:   [    9.522511] usbcore: registered new interface driver hb_rf_usb_2

I got the device from smartkram.de. Changing the code actually works.

The USB cable is used for data and power. The host is a Raspberry Pi 4 with Raspbian Bullseye 64-bits.

Here's a photograph of the module:

dmesg | grep "usb 1-1.1"
                 265:   [    3.233940] usb 1-1.1: new full-speed USB device number 3 using xhci_hcd
                 277:   [    3.349571] usb 1-1.1: New USB device found, idVendor=10c4, idProduct=8c07, bcdDevice= 1.01
                 278:   [    3.360019] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
                 279:   [    3.369487] usb 1-1.1: Product: HB-RF-USB-2
                 280:   [    3.374832] usb 1-1.1: Manufacturer: Alexander Reinert
                 281:   [    3.381132] usb 1-1.1: SerialNumber: 00db28fe2ec1e8118dad6b713b0549ec
                 447:   [    9.325130] usb 1-1.1: DKey: 6566383262643030 3131386531636532 3137623664616438 6365393435306233
                 448:   [    9.325163] usb 1-1.1: HKey: acf2da98871bed15 6ecec16a3abf4f98 60c647b63d6d544a e6973d53f235c1a3
                 449:   [    9.325179] usb 1-1.1: SKey: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
                 450:   [    9.325193] usb 1-1.1: SKey: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
                 451:   [    9.325208] usb 1-1.1: PKey: f50048a8d7cc3f44 ae8460d13cf61d60 2dc161f5272a5876 88c996b27737fbae
                 452:   [    9.325222] usb 1-1.1: PKey: dd24b0aced521e88 cc457acb4b7c49a4 6745032ab2079847 becfb9f3af25d41f
                 453:   [    9.325238] usb 1-1.1: Could not verify device signature
                 454:   [    9.325255] usb 1-1.1: Found HB-RF-USB-2 with serial 00db28fe2ec1e8118dad6b713b0549ec at usb-0000:01:00.0-1.1

[alexreinert]

Is that output produced with the code changes or without them?

[agross]

The code changes do not matter for the output since I only changed detect_hardware.inc which is executed by the service as far as I understand.

[alexreinert]

That code in detect_hardware.inc is just a backup to ensure, that the modules are loaded. As written, normally the modules are loaded automatically using the usb id and at that code place as backup using the .so file name. Detection of the radio module will be done using the devices /dev/raw-uart*, which will be created after successful loading of the modules. So if you say, the output is the same, the radio module should be detected as well.

[agross]

OK, it's starting to make sense now. Despite the fact that the "fallback" kmod loading in detect_hardware.inc would not work on this machine, I can successfully start pivccu. When I had a look at the file earlier I was in the process of migrating from HM-MOD-RPI-PCB to HB-RF-USB-2. I was trying to force it to use the USB-based module, while at that time there were two devices in /dev/raw-uart* with the USB one being the second (and hence being ignored).