gmane.linux.hotplug.devel

[ANNOUNCE] udev 135 release

Kay Sievers — 2008-12-02T01:49:47

Here comes a new udev version. Thanks to all who have contributed to this release. The tarball can be found here: ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/ The development repository can be found here: http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary The ChangeLog can be found here: http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog udev 135 ======== Bugfixes. Fix for a possible segfault while swapping network interface names in udev versions 131-134. -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: usb coldplug problem

Bernd Porr — 2008-12-01T18:27:30

Ok. I'll look into that. So, you mean that I create with the "request firmware" a new udev event which then could also call "comedi_config"? The problem just now is that I don't get any udev events during coldplug. Do you think this will also solve that issue? One practical thing: it's probably a good idea to work on the driver version which goes into the kernel and not the one in the comedi CVS. Where can I check out my module just now? Thanks! /Bernd Greg KH wrote:

Re: usb coldplug problem

Greg KH — 2008-12-01T15:29:20

Then do it like other USB devices do it: - usb probe function calls request firmware - after request firmware succeeds, then initialize the comedi interface That way the driver will work like all other Linux USB devices do :) udev is supported everywhere. It's in my daughter's cell phone (the number 1 selling phone in the USA this year) and if udev isn't there, than the "generic" way of having hotplug handle firmware events is still going to work properly for you. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: usb coldplug problem

Bernd Porr — 2008-12-01T15:21:56

Hi! It's not that easy. The actual udev event triggers comedi_config which does _also_ the firmware upload on the side. Even if I upload the firmware via sysfs I still need to run comedi_config to set up the comedi device. Therefore it's simpler to do it via comedi_config as this supports firmware upload anyway and people can also do it manually if udev is not supported, for example on embedded systems. You see I've put in some thought into that earlier. But I'm open for suggestions. ;-) /Bernd www: http://www.berndporr.me.uk/ http://www.linux-usb-daq.co.uk/ Mobile: +44 (0)7840 340069 Work: +44 (0)141 330 5237 University of Glasgow Department of Electronics & Electrical Engineering 72 Oakfield Avenue (for deliveries: Rankine Building) Glasgow, G12 8LT Greg KH wrote:

Re: usb coldplug problem

Greg KH — 2008-12-01T14:35:28

Why not just use the firmware functions in the kernel core for this? That way, when the device is seen by udev, the correct firmware request function will be called, your firmware will be loaded, and everything should be just fine. No need to reinvent the wheel here :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

usb coldplug problem

Bernd Porr — 2008-12-01T08:46:52

Hi! I'm the maintainter of the USBDUX board which connects via the USB to linux. In order to work properly the USBDUX needs firmware uploaded. So, I wrote a udev rule which uploads the firmware as soon as there's a udev event from the USB BUS (this is done via comedi_config). This works fine for hotplug but not for coldplug. So I need to pull the USB plug and back again to get the firmware loaded. I've checked with udevadm monitor and there are indeed no udev events during boot relating to the usbdux. Even a udevadm trigger produces no hotplug events for the USBDUX during boot time -- however later it does. It seems so that the usb subsystem is loading the usbdux module earlier on in the boot process so that no udev events are triggered later in the boot process. Any other ideas? It is really annoying that one has to pull out the plug and plug it back in again to trigger the firmware upload. I've been trying to solve the problem for a couple of weeks but without success. With the old hotplug m

Re: mtd and udev

Sven Fischer — 2008-12-01T09:14:38

Thanks a lot, such a stupid typo...;-) works like a charm now ! Sven On Friday 28 November 2008, Kay Sievers wrote: -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Udev rule for HSDPA modem

Kay Sievers — 2008-11-30T05:21:11

It might get pretty complicated to use D-Bus/HAL for simple setups, and rather static configurations like this. NetworkManager handles that, and we will even get modem-probing soon, but in cases like this it might be easier to have a simple - not very flexible - but working solution. Maybe we can have an "index" sysfs file at the serial device, which carries the instance number, per usb device? This would allow us to create persistent links which do not depend on the kernel device enumeration across multiple device. We did the same for v4l devices recently: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=539a7555b31e65e66fb84c881d07d2bf18c974d0 Greg, what do you think? Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Help to create a rule for UDEV

2008-11-29T23:25:54

Hi! I have 3 usb devices connected to my PC. All of them are identical. Lets call them device1, device2 and device3 They are beeing detected as ttyUSB0 (device1), ttyUSB1(device2) and ttyUSB2(device3), which is exactly what I want. The only problem is that when I restart, they often get mixed, and detected ttyUSB0(device2), ttyUSB1(device3) and ttyUSB2(device1) or any other order. I can't create rules for these device from serialnumber, or other details other than usb-connection port. This is what I get from udevinfo, hoping that someone can help me create a rule, for all 3. looking at device '/class/tty/ttyUSB0': KERNEL=="ttyUSB0" SUBSYSTEM=="tty" DRIVER=="" ATTR{dev}=="188:0" looking at parent device '/devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/ttyUSB0': KERNELS=="ttyUSB0" SUBSYSTEMS=="usb-serial" DRIVERS=="ftdi_sio" ATTRS{port_number}=="0" looking at parent device '/devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0': KERNELS=="4-2:1.0" SUBSYSTEMS=="usb" DRIVERS=="ftdi_sio" ATTRS{bInterfaceNu

Re: Udev rule for HSDPA modem

Greg KH — 2008-11-29T17:37:15

I do not think HAL requires X. Try asking on your distro mailing list for how they have incorporated HAL into the releases you are using. good luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Udev rule for HSDPA modem

Jar — 2008-11-29T08:00:59

Thanks for your reply! Does HAL require that I have desktop installed, this is my home "server" machine without X? Do you have any starting point or where to learn more how to do this with HAL.

Re: Udev rule for HSDPA modem

Greg KH — 2008-11-28T18:51:06

HAL contains a list of these modems and a mapping of each port to what it does based on the specific device. Try using that instead of udev specific rules for your accessed to the modem, it will work much better. good luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Udev rule for HSDPA modem

Jar — 2008-11-28T17:56:53

Hello I hope this is the correct list to ask this. I am not subscribed, so add me to cc. HSDPA modem (usb_serial+option modules) creates three ttyUSB devices. The first one is the modem interface used for ppp connection. How to write udev rule which will match to the first ttyUSB device? E.g. if the devices are ttyUSB1, ttyUSB2 and ttyUSB3, how to create e.g. symlinks modem0, modem1 and modem2, then it would be guaranteed that the modem0 device would be the first one. I tried the above rule, but it's problem is that it match only ttyUSB0 and that is not always the HSDPA modem device. ACTION=="add", \ KERNEL=="ttyUSB0", \ SUBSYSTEMS=="usb", \ ATTRS{idVendor}=="12d1", \ ATTRS{idProduct}=="1003", \ SYMLINK+="modem", \ RUN+="/tmp/udev_test.sh" Rule below will match all ttyUSB* devices and then the udev_test.sh will run several times. I would want to run it only once for the first ttyUSB of the modem. ACTION=="add", \ KERNEL=="ttyUSB*", \ ... ...

Re: mtd and udev

Kay Sievers — 2008-11-28T16:28:36

It should work fine with udev. But use SUBSYSTEM, not SUBSYSTEMS, you match on the event not a parent device. And there is probably no reason to swap around node and symlink names, just create the symlinks, if you want them, but don't needlessly change the device node name. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

mtd and udev

Sven Fischer — 2008-11-28T16:08:21

Hi, I'm trying to use udev to dynamically generate mtd devices like mtdblock0 or mtd0 etc. I'm using Linux Kernel 2.6.24 on an ARM board. I have setup two rules but to no avail: ACTION=="add", KERNEL=="mtdblock[0-9]", SUBSYSTEMS=="block", NAME="mtdblock/%n", SYMLINK+="%k" ACTION=="add", KERNEL=="mtd[0-9]", SUBSYSTEMS=="mtd", NAME="%k" I tried to check them with udevtest, but it doesn't work. strace shows that it runs through the /sys subtree but it doesn't match anything against the above rules. I have the impression mtd isn't meant to work together with udev at all. Am I right ? Or what can be the reason for this issue. Help appreciated. Best regards Sven -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: USB, Infiniband and X0R rules

Kay Sievers — 2008-11-28T01:06:02

I've added these. Seems like a rather half-baken idea though, to group random stuff in a directory named after the bus the devices are connected to. Looks like someone tried to survive the 20.000+ entries /dev we had years ago. :) I've added the infiniband.rules files to the packages/ directory. We can not put these into the default rules because distros already ship infiniband rules in their own package. Applied. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH]: USB, Infiniband and X0R rules

Piter PUNK — 2008-11-28T00:06:14

Hi, Those are the last custom slackware rules. They creates some devices in correct place (following devices.txt). USB devices are moved to /dev/usb/name and Infiniband to /dev/infiniband/name. The patch fixes X0R symlink, too. From devices.txt: --- /dev/X0R null symbolic Required by iBCS-2 Note: /dev/X0R is --. --- Well, the patch is below: ---patch here--- diff -Naur udev-134-orig/rules/rules.d/50-udev-default.rules udev-134/rules/rules.d/50-udev-default.rules --- udev-134-orig/rules/rules.d/50-udev-default.rules2008-11-19 18:46:39.000000000 -0200 +++ udev-134/rules/rules.d/50-udev-default.rules2008-11-27 21:36:51.000000000 -0200 < at >< at > -20,7 +20,7 < at >< at > # mem KERNEL=="null|zero|full|random|urandom", MODE="0666" -KERNEL=="null",SYMLINK+="XOR" +KERNEL=="null",SYMLINK+="X0R" KERNEL=="mem|kmem|port|nvram",GROUP="kmem", MODE="0640" KERNEL=="ram0",SYMLINK+="ramdisk" KERNEL=="ram1",SYMLINK+="ram" < at >< at > -59,6 +59,20 < at >< at > # firmware clas

Re: [ANNOUNCE] udev 134 release

Kay Sievers — 2008-11-27T17:18:51

Was in the wrong directory, sorry. Moved it over. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] udev 134 release

Piter PUNK — 2008-11-27T17:13:16

Kay, The tarball isn't in ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/ The last one there is udev-133. Piter PUNK

Re: [PATCH] Fix switch statement for video type

Kay Sievers — 2008-11-26T12:44:06

Ah, nice! Applied. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] Fix switch statement for video type

Marcel Holtmann — 2008-11-26T05:30:53

Introducing the video type, creating a fall-through case where other devices might now be declared as type video. diff --git a/extras/usb_id/usb_id.c b/extras/usb_id/usb_id.c index 91e3ecc..ce1eb0b 100644 --- a/extras/usb_id/usb_id.c +++ b/extras/usb_id/usb_id.c < at >< at > -70,6 +70,7 < at >< at > static void set_usb_iftype(char *to, int if_class_num, size_t case 0x0a: /* CDC-Data */ case 0x0b: /* Chip/Smart Card */ case 0x0d: /* Content Security */ + break; case 0x0e: type = "video"; break; -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html