From: Anthony Wright <anthony@communitymesh.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: The DRIVER rule doesn't seem to work
Date: Fri, 11 Aug 2006 21:59:20 +0000 [thread overview]
Message-ID: <44DCFE33.5010804@communitymesh.com> (raw)
In-Reply-To: <44CCAD5F.9010407@communitymesh.com>
Kay Sievers wrote:
> On Thu, 2006-08-03 at 10:45 +0100, Anthony Wright wrote:
>
>> I don't think they are class devices, but I can't be 100% sure as I'm
>> 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="?*" for each of these devices according to match_key
>> 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,
>> not the device itself. If DRIVER also matched against the device I
>> 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
>>
>
> Hmm, that seems to work for me, for the device we receive the event for:
> DRIVER="uhci_hcd", PROGRAM="/bin/true usb"
>
> $ ls -l /sys/devices/pci0000:00/0000:00:1d.1/driver
> /sys/devices/pci0000:00/0000:00:1d.1/driver -> ../../../bus/pci/drivers/uhci_hcd
>
> $ udevtest /devices/pci0000:00/0000:00:1d.1
> main: looking at device '/devices/pci0000:00/0000:00:1d.1' from subsystem 'pci'
> run_program: '/bin/true usb'
> ...
>
> Kay
>
I get the same result from udevtest, so I tried a variation on the rule
and changed it to the rule below.
DRIVER="uhci_hcd", PROGRAM="/bin/sh -c '/bin/echo %p >>/tmp/udev.log'"
If I udevtest on /devices/pci0000:00/0000:00:1d.1, as expected I get an
entry for it in the udev.log file. However if I remove udev.log, kill
udevd, restart it and then udevtrigger, I get a udev.log that looks like:
/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.2
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.1
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0
/devices/pci0000:00/0000:00:1d.3/usb5/5-0:1.0
/devices/pci0000:00/0000:00:1d.2/usb4/4-0:1.0
/devices/pci0000:00/0000:00:1d.1/usb3/3-0:1.0
/devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0
/devices/pci0000:00/0000:00:1d.2/usb4/4-1
/devices/pci0000:00/0000:00:1d.3/usb5
/devices/pci0000:00/0000:00:1d.1/usb3/3-1
/devices/pci0000:00/0000:00:1d.0/usb2
/devices/pci0000:00/0000:00:1d.2/usb4
/devices/pci0000:00/0000:00:1d.1/usb3
/class/usb_host/usb_host5
/class/usb_host/usb_host4
/class/usb_host/usb_host3
/class/usb_device/usbdev5.1
/class/usb_host/usb_host2
/class/usb_device/usbdev4.1
/class/usb_device/usbdev2.1
/class/input/input3/mouse2
/class/usb_device/usbdev4.2
/class/usb_device/usbdev3.1
/class/usb_device/usbdev3.2
/class/input/input3
I actually have 4 usb hubs which use the uhci_hcd driver
(0000:00:1d.[0-3]). Unlike under udevtest, with udevd none of these
match the rule, though all of their children do.
Tony.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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
next prev parent reply other threads:[~2006-08-11 21:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-30 12:58 The DRIVER rule doesn't seem to work Anthony Wright
2006-07-30 14:20 ` Kay Sievers
2006-08-03 8:40 ` Anthony Wright
2006-08-03 8:44 ` Kay Sievers
2006-08-03 9:45 ` Anthony Wright
2006-08-03 18:12 ` Kay Sievers
2006-08-11 21:59 ` Anthony Wright [this message]
2006-08-13 3:23 ` Kay Sievers
2006-08-14 7:29 ` Anthony Wright
2006-08-14 10:59 ` Kay Sievers
2006-08-23 0:05 ` Kay Sievers
2006-08-23 0:16 ` Kay Sievers
2006-08-24 14:34 ` Anthony Wright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44DCFE33.5010804@communitymesh.com \
--to=anthony@communitymesh.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).