Comment 2 for bug 392144

The second hunk is irrelevant, but this change seems to have triggered it:

-KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
+ATTR{bInterfaceProtocol}=="02", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
     RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"

I guess what happens it that hid2hci is now called on this device.

First, my USB input devices:

  keyboard: /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.1/1-8.1.2/1-8.1.2:1.1/input/input8/event8
  mouse: /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.1/1-8.1.3/1-8.1.3:1.0/input/input9/event9

So let's check what this rule is called on:

$ udevadm trigger --dry-run --subsystem-match=usb --attr-match=bInterfaceProtocol=02 --verbose
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.1/1-8.1.3/1-8.1.3:1.0
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0

/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0 is apparently the docking station's USB hub, in attached UdevDb.txt you see that the USB mouse/keyboard are attached to this.

/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.1/1-8.1.3/1-8.1.3:1.0 is the mouse (which is connected to the keyboard's builtin USB hub).

ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0" matches on a far-out parent device:

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-8':
    KERNELS=="1-8"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="100mA"
    ATTRS{urbnum}=="71"
    ATTRS{idVendor}=="413c"
    ATTRS{idProduct}=="0058"
    ATTRS{bcdDevice}=="0000"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="02"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="3"
    ATTRS{version}==" 2.00"
    ATTRS{maxchild}=="4"
    ATTRS{quirks}=="0x0"
    ATTRS{authorized}=="1"

so just because I have a Dell USB hub somewhere, all devices attached to it with bInterfaceProtocol==02 get treated by this hid2hci program. Apparently this rule is way too wide.

You need to check ATTR{bInterfaceClass} and ATTR{bInterfaceSubClass}, to make sure that bInterfaceProtocol=="02" actually has some meaning. E. g., as http://www.usb.org/developers/defined_class shows, interface class 09, subclass 00, interface protocol 02 is a hi-speed USB. I don't think these are intended to match here. You probably want class E0, subclass 01 or 02 (I don't know what these rules are actually supposed to do), but these are bluetooth devices.