From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Wright Date: Thu, 03 Aug 2006 09:45:01 +0000 Subject: Re: The DRIVER rule doesn't seem to work Message-Id: <44D1C59D.205@communitymesh.com> List-Id: References: <44CCAD5F.9010407@communitymesh.com> In-Reply-To: <44CCAD5F.9010407@communitymesh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org Kay Sievers wrote: >>>> What I believe is happening is that DRIVER is looking at the device's = >>>> ancestor's drivers (parent, grandparent etc, but not the device itself= ),=20 >>>> and returning their driver if they have one. >>>> =20 >>> Sure, it looks a the device itself, but also walks up the parents and >>> finds a DRIVER value there. >>> =20 >> I had a good look at this, and from what I can tell it only looks at the= =20 >> device's parents, not the device itself. I compiled and ran udev with=20 >> debug to see what was going on (and have lots of logs if you're=20 >> interested), but the short version is that while udev makes a DRIVER=20 >> test for the device, it looks like the driver field hasn't been loaded=20 >> for the device, only for the device's parents. From my logs, it seems=20 >> that to load values for the device the function=20 >> sysfs_device_set_values() is called in isolation, while for the parents = >> sysfs_device_get() is called which calls sysfs_device_set_values(), but = >> also sets the driver field. >> =20 > If you ask for a class device, it will never be set, cause class devices > don't have a driver, only parent devices which are created by a bus I don't think they are class devices, but I can't be 100% sure as I'm=20 still learning how all the device handling works. The path to the devices and their driver symbolic links are: Path Driver Symlink a) /sys/devices/pci0000:00/0000:00:1d.1 uhci_hcd b) /sys/devices/pci0000:00/0000:00:1d.1/usb2 usb c) /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0 hub d) /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1 usb e) /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0 NONE f) /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.1 NONE g) /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.2 NONE and there are a lot of references to the bus sub-directories in the logs. The rule DRIVER=3D"?*" for each of these devices according to match_key=20 matches the following matching values: Matching value a) MATCHING FAILS b) uhci_hcd c) usb d) usb e) usb f) usb g) usb This is consistant with DRIVER matching against a device's parents only,=20 not the device itself. If DRIVER also matched against the device I=20 believe the matching values should be as follows. Matching value a) uhci_hcd b) usb c) hub d) usb e) usb f) usb g) usb Cheers, Tony. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=DEVD= EV _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel