I recently installed JLink_Linux_V614f_x86_64.deb in Debian Debian GNU/Linux 8.7 (jessie), and discovered that the udev rules never take effect. After some tweaking I have found the following:

• The file has quite a few Windows newlines in it, which makes those rules be ignored
  
• A lot of rules have e.g. ATTR{idProduct}=="0x1001", while the correct format is ATTR{idProduct}=="1001", without the "0x"
• SUBSYSTEM!="usb_device" should probably be changed to either SUBSYSTEM!="usb" or DEVTYPE!="usb_device"

After making those changes my devices get the correct permissions. I have attached a version of the file which works for me: 99-jlink.rules.txt.

If anyone is testing this at home, a good way of verifying your changes is to run udevadm test --action=add $(udevadm info -q path -n /dev/bus/usb/001/010), where /dev/bus/usb/001/010 is the device name of your J-Link. As soon as the output starts mentioning MODE 0666 you can reload your udev rules using udevadm control --reload.

Let's go over these one by one and I'll explain my reasoning.

A lot of rules have e.g. ATTR{idProduct}=="0x1001", while the correct format is ATTR{idProduct}=="1001", without the "0x"

Its not unlikely that this one is version dependent, and that the "0x" worked at the time it was originally written. I get this output with the 0x format:


If I remove the "0x", I get this:



You'll notice that these are almost identical, but the latter says "MODE 0666 /etc/udev/rules.d/99-jlink.rules:128" while the former does not. What this tells me is that ATTR{idProduct}=="1015" successfully matched my J-Link and set the permissions to 0666, while ATTR{idProduct}=="0x1015" did not.

We appear to be using the same version of udev. However, looking at your output, the device you are testing with has ID_MODEL_ID=0105. This model ID is not affected by my proposed change, since the block of "old format" model IDs didn't have 0x in them in the original file either. My change only affects debuggers using the new format for the model ID, like the one included on the nRF52-DK I am currently playing with.

SUBSYSTEM!="usb_device" should probably be changed to either SUBSYSTEM!="usb" or DEVTYPE!="usb_devic

This one wouldn't show any visible difference during this test, since it is only used in this code:

What this presumably attempts to do is to skip all the rules in the file if this is not an "add" action and this is not USB. However, since the match for whether it is USB is using either the wrong variable or the wrong value (depending on what was the desired behavior), the rules are never skipped. This gives no visible difference in this particular test-case (since the action is "add", making the first part of the test not match). It is unclear to me why one would need to skip the rules (I would expect MODE="666" to be a no-op if the file is removed anyway, and merely redundant if the file permissions were already set to that during add), but I assume this was added for a reason. In its current form, it will never match and may as well be deleted if it doesn't add value.

Admittedly, even if you do change this to one of my proposed changes, the logic is still very odd. Since it is an "and" match, the rules would still not be skipped if you were adding a non-USB device, or if you were removing a USB device. It would make more sense to me these were checks for equality and included on each line, like this:

However, I have to reiterate that I do not know the intended purpose of the original code.

At first I suspected that the 0x was for an earlier version of udev, but since jdcso reports that it used to work, I took a look at JLink_Linux_V614e_x86_64.deb (the version before the one I had issues with). There I found a shorter list without the 0x:


I suspect the person who expanded the list did so by regenerating it completely using a Windows computer (hence the Windows newlines), and didn't notice that he/she also added an extra "0x" in the ATTR{idProduct}.