Had I read about your Prolific trouble earlier I could have told you about the lack of serial number. Please let me know if you find a solution, I would find it useful too.
This is my current /etc/udev/rules.d/40-usb-serial-adapters.rules. At the end you can see my attempt at solving the Prolific problem, giving unique names to adapters but they are not persistent over time. I do not spend a lot of time or energy trying to solve this, it is no major problem for me.
(I made some changes in my usb-serial-adapters rules file, in order to get the symlinks to point to the ttyUSB* devices, and found that it needs a number of 40 or higher in order to work. I found the number using grep ttyUSB /lib/udev/rules.d/*, the first rule mentioning ttyUSB was numbered 40.)
# udevadm info --attribute-walk --path=/sys/bus/usb-serial/devices/ttyUSB0
KERNEL!="ttyUSB*", GOTO="local_usb__rules_end"
ATTRS{idVendor}=="0403", GOTO="local_usb__process_ftdi"
ATTRS{idVendor}=="067b", GOTO="local_usb__process_prolific"
LABEL="local_usb__process_ftdi"
# Modern Device BUB
ATTRS{serial}=="A6007NVf", SYMLINK+="ftdi-md-bub-1"
ATTRS{serial}=="A6007ntk", SYMLINK+="ftdi-md-bub-2"
ATTRS{serial}=="A6007NEG", SYMLINK+="ftdi-md-bub-3"
# SparkFun: 5V FTDI Basic/FT232R Breakout Board
ATTRS{serial}=="A6007Cp2", SYMLINK+="ftdi-sf-b5v-1"
ATTRS{serial}=="A6007CId", SYMLINK+="ftdi-sf-b5v-2"
ATTRS{serial}=="A6007DtI", SYMLINK+="ftdi-sf-bob-1"
ATTRS{serial}=="A6007Dtw", SYMLINK+="ftdi-sf-bob-2"
# FTDI cable (original from FTDI)
ATTRS{serial}=="FTE3HIKO", SYMLINK+="ftdi-cable"
# Arduino
ATTRS{serial}=="A7006QLL", SYMLINK+="ftdi-arduino-2k9"
ATTRS{serial}=="A6007AgC", SYMLINK+="ftdi-arduino-mega"
ATTRS{serial}=="A6009aKI", SYMLINK+="ftdi-emcs-mega-1"
ATTRS{serial}=="A6009aKL", SYMLINK+="ftdi-emcs-mega-2"
ATTRS{serial}=="A7004IkW", SYMLINK+="ftdi-seeed-mega-1"
ATTRS{serial}=="A7004I2Q", SYMLINK+="ftdi-seeed-mega-2"
ATTRS{serial}=="A7004HYi", SYMLINK+="ftdi-seeed-mega-3"
# Digi USB dev board
ATTRS{idProduct}=="ee18", ATTRS{product}=="MaxStream PKG-U", SYMLINK+="ftdi-digi-xbib"
GOTO="local_usb__rules_end"
LABEL="local_usb__process_prolific"
# GlobalSat (PS/2 adapter cable, USB GPS)
ATTRS{idProduct}=="2303", ATTRS{bcdDevice}=="0300", ATTRS{product}=="USB-Serial Controller", SYMLINK+="pl2303-globalsat-%M-%m-%n"
# Other Prolific adapters, all lacking serial number
ATTRS{idProduct}=="2303", ATTRS{bcdDevice}=="0202", SYMLINK+="pl2303-%M-%m-%n"
LABEL="local_usb__rules_end"
wayoda: Thanks for the information about ls /dev/serial/by-id
For the AVRisp MkII, I have experimented with simplifying the rules, and for me it still works. The file is still numbered 39, and on my system the permissions are the intended, and I can use the programmer without sudo. The full path and name in my case is /etc/udev/rules.d/39-mcu-programmers.rules
# udev rules file for some usb connected mcu programmers
# Atmel devices
#
ATTR{idVendor}=="03eb", ATTR{idProduct}=="2104", MODE="0660", GROUP="plugdev", SYMLINK+="avrispmkII"
#ATTR{idVendor}=="03eb", ATTR{idProduct}=="2103", MODE="0660", GROUP="plugdev", SYMLINK+="avrunknown-%n"
#ATTR{idVendor}=="03eb", ATTR{idProduct}=="2107", MODE="0660", GROUP="plugdev", SYMLINK+="avrdragon-%n"
# Microchip devices
#
ATTR{idVendor}=="04d8", ATTR{idProduct}=="0033", MODE="0660", GROUP="plugdev", SYMLINK+="pickit2"
After plugging it in:
jadler@server:~$ ls -l /dev/avrispmkII /dev/bus/usb/002/116
lrwxrwxrwx 1 root root 15 2009-10-24 16:36 /dev/avrispmkII -> bus/usb/002/116
crw-rw-r-- 1 root plugdev 189, 243 2009-10-24 16:36 /dev/bus/usb/002/116
wayoda:
Sounds reasonable. Since I'm the only user my machine I don't need an extra users-group for my USB-hardware.
No, you may not, but some devices will be assigned to the plugdev group, with root still being the owner. Since normal users are members of this group, a device/file owned by this group and having appropriate group permissions will be useable by normal users. I think that this is the proper way of solving this kind of problem with access permissions to this kind of hardware.
I just made another experiment, the relevant line in the rules file is now:
ATTR{idVendor}=="03eb", ATTR{idProduct}=="2104", GROUP="plugdev"
That is, no attempts at modifying permissions, only group membership. I have also disabled the Virtualbox rules that also modifies these devices (and any other USB devices) to make sure that nothing else affects the outcome. The results (for me):
jadler@server:~$ lsusb|grep Atmel
Bus 002 Device 117: ID 03eb:2104 Atmel Corp. AVR ISP mkII
jadler@server:~$ ls -l /dev/bus/usb/002/117
crw-rw-r-- 1 root plugdev 189, 244 2009-10-24 16:45 /dev/bus/usb/002/117
jadler@server:~$ avrdude -P usb -p atmega1280
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9703
avrdude: safemode: Fuses OK
avrdude done. Thank you.
If I disable the AVRisp rule, the result is:
jadler@server:~$ lsusb|grep Atmel
Bus 002 Device 120: ID 03eb:2104 Atmel Corp. AVR ISP mkII
jadler@server:~$ ls -l /dev/bus/usb/002/120
crw-rw-r-- 1 root root 189, 247 2009-10-24 16:57 /dev/bus/usb/002/120
jadler@server:~$ avrdude -P usb -p atmega1280
avrdude: usb_open(): cannot read serial number "error sending control message: Operation not permitted"
avrdude: usb_open(): cannot read product name "error sending control message: Operation not permitted"
avrdude: usbdev_open(): error setting configuration 1: could not set config 1: Operation not permitted
avrdude: usbdev_open(): did not find any USB device "usb"
My conclusion is that it is the group membership is the solution, not the permissions. (Thank you, both of you, for motivating me to find this out! Now my rules will be even better.) And on my system, this still works just fine with the rule numbered 39 as before, or even numbered 00.
The file /lib/udev/rules.d/60-persistent-serial.rules is the one that assigns the /dev/serial/* symlinks and it contains some nice examples of udev rules.
/lib/udev/rules.d/40-avarice.rules contains rules for AVR Dragon and JTAG ICE mkII and could probably be used as a template for handling other µC programmers/interfaces. On my system it is this simple:
SUBSYSTEM!="usb_device", ACTION!="add", GOTO="avarice_end"
# Atmel Corp. JTAG ICE mkII
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2103", MODE="660", GROUP="dialout"
# Atmel Corp. AVR Dragon
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2107", MODE="660", GROUP="dialout"
LABEL="avarice_end"
wayoda: The dialout group is another one of the groups used for giving different non-root users access to different kinds of hardware, as you probably know.
