[colug-432] blacklist usb device

[Jeff Frontz]

I suspect it's the keyboard/trackpad coming up, finding that macos
isn't there (because it didn't get the right secret handshake or
whatever), and disconnecting -- only to try it all again in hopes that
the right OS finally boots.

Can you disable that particular bus?

On Mon, Jul 31, 2023 at 6:28 PM Rick Hornsby <rhornsby at ktzr.net> wrote:
>
> 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!
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432