From: Daniel Drake <dsd@laptop.org>
To: linux-hotplug@vger.kernel.org
Subject: device attributes not propogating all of the time
Date: Wed, 18 Nov 2009 09:13:06 +0000 [thread overview]
Message-ID: <1258535586.2761.21.camel@localhost.localdomain> (raw)
Hi,
Using udev-141 from Fedora 11.
The problem that I'm attacking: we need to identify MMC disks based on
the bus number of the MMC bus that they are attached to. In other words,
after figuring out that we're booting from MMC bus #1, I need to know
which mmcblk device node corresponds to that MMC card.
Unfortunately the default mmcblkXpY nodes do not reflect this (X simply
starts from 0 and increments)
I figured the easiest way to do this would be to write some udev rules
that create symlinks based on the MMC bus number. So I'm looking to
create /dev/disk/mmc/mmc2 which would correspond to the disk on the 2nd
MMC card slot. (The actual disk node might be called /dev/mmcblk0 so
thats not useful)
Here is the udevadm info output for 1 of the block devices that we want
to apply such a symlink to:
looking at device '/devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1/mmc1:aaaa/block/mmcblk1':
KERNEL="mmcblk1"
SUBSYSTEM="block"
DRIVER=""
ATTR{range}="8"
ATTR{ext_range}="8"
ATTR{removable}="0"
ATTR{ro}="0"
ATTR{size}="7744512"
ATTR{alignment_offset}="0"
ATTR{capability}="10"
ATTR{stat}=" 38 213 2008 170 0 0 0 0 0 70 170"
looking at parent device '/devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1/mmc1:aaaa':
KERNELS="mmc1:aaaa"
SUBSYSTEMS="mmc"
DRIVERS="mmcblk"
ATTRS{cid}="03534453553034478000ffe24c009800"
ATTRS{csd}="400e00325b5900001d8a7f800a404000"
ATTRS{scr}="0235800000000000"
ATTRS{date}="08/2009"
ATTRS{fwrev}="0x0"
ATTRS{hwrev}="0x8"
ATTRS{manfid}="0x000003"
ATTRS{name}="SU04G"
ATTRS{oemid}="0x5344"
ATTRS{serial}="0x00ffe24c"
ATTRS{type}="SD"
looking at parent device '/devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1':
KERNELS="mmc1"
SUBSYSTEMS="mmc_host"
DRIVERS=""
You can see above that you have to go up 2 levels in the tree before you
reach the main MMC parent device, where the number is pretty obvious and
can be retrieved by udev's %n
So I came up with these rules:
SUBSYSTEM="mmc_host", KERNEL="mmc[0-9]", ENV{MMC_BUSNO}="%n"
SUBSYSTEM="mmc", KERNEL="mmc[0-9]:*", IMPORT{parent}="MMC_BUSNO"
SUBSYSTEM="block", KERNEL="mmcblk?", IMPORT{parent}="MMC_BUSNO", SYMLINK+="disk/mmc/mmc$env{MMC_BUSNO}"
SUBSYSTEM="block", KERNEL="mmcblk?p?", IMPORT{parent}="MMC_BUSNO", SYMLINK+="disk/mmc/mmc$env{MMC_BUSNO}p%n"
They assign a MMC_BUSNO variable to the 2nd-level parent and bubble it
up all the way to the block device, where it is then used to generate a
symlink.
While the above rules work fine most of the time, unfortunately they are
not reliable.
I am often seeing that the MMC_BUSNO variable does not reach
the /devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1/mmc1:aaaa device, and
hence does not bubble up to the disk. It is definitely set OK on the
main bus device.
P: /devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1
E: MMC_BUSNO=1
P: /devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1/mmc1:aaaa
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1/mmc1:aaaa
E: DRIVER=mmcblk
E: MMC_TYPE=SD
E: MMC_NAME=SU04G
E: MODALIAS=mmc:block
The MMC_BUSNO attribute is missing from the 2nd device above.
If I manually run
"udevtest /devices/pci0000:00/0000:00:0c.0/mmc_host/mmc1/mmc1:aaaa" when
this happens, then the variable gets correctly assigned.
Does this seem like a udev bug, or am I missing something subtle?
Thanks,
Daniel
next reply other threads:[~2009-11-18 9:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 9:13 Daniel Drake [this message]
2009-11-18 16:14 ` device attributes not propogating all of the time Andrey Borzenkov
2009-11-18 16:24 ` Daniel Drake
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=1258535586.2761.21.camel@localhost.localdomain \
--to=dsd@laptop.org \
--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