[colug-432] blacklist usb device

[Rick Hornsby]

Giving an old 2011 Macbook air new life and a new purpose sans the case, 
keyboard, and trackpad. Basically, I tore the whole thing apart and I'm 
only using the motherboard and the display.

Linux (debian 12, specifically but any distro+GUI will do) installs and 
runs perfectly fine. The problem I'm having is that I cannot seem to 
properly blacklist the missing keyboard/trackpad. Something in the 
motherboard(?) logic is connecting this ghost HID via the USB bus, 
discovers it's not present, and disconnecting it. This repeats about 
every 1/2 second:


[   37.116765] usb 1-1.2: new full-speed USB device number 43 using ehci-pci
[   37.232243] usb 1-1.2: New USB device found, idVendor=05ac, 
idProduct=0252, bcdDevice= 1.18
[   37.232263] usb 1-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   37.232271] usb 1-1.2: Product: Apple Internal Keyboard / Trackpad
[   37.232277] usb 1-1.2: Manufacturer: Apple Inc.
[   37.239254] input: Apple Inc. Apple Internal Keyboard / Trackpad as 
/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:0252.0044/input/input51
[   37.297629] apple 0003:05AC:0252.0044: input,hidraw1: USB HID v1.11 
Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on 
usb-0000:00:1a.7-1.2/input0
[   37.300103] apple 0003:05AC:0252.0045: hidraw3: USB HID v1.11 Device 
[Apple Inc. Apple Internal Keyboard / Trackpad] on 
usb-0000:00:1a.7-1.2/input1
[   37.407369] usb 1-1.2: USB disconnect, device number 43


I've tried various udev rules without much luck, examples:

SUBSYSTEM=="usb", ATTRS{idVendor}=="05ac",ATTR{authorized}="0"

ACTION=="add", ATTR{idVendor}=="05ac", RUN="/bin/sh -c 'echo 0 > 
/sys/\$devpath/authorized'"

ACTION=="add", ATTR{idVendor}=="05ac", RUN="/bin/sh -c 'echo 1 > 
/sys/\$devpath/remove'"

I've also blacklisted the bcm5974 kernel module.

The dmesg spamming I could probably pretend to ignore, but the cycling 
is also making udev-worker chew up CPU cycles (more or less a full cpu 
core) that I need.

This is where I'm going to veer out of my lane - I'm guessing the 
cycling is happening because of a hardware interrupt of some kind? Is it 
possible to somehow get the kernel to ignore that specific interrupt 
(while not killing off other USB devices)?

thanks!