Linux Hotplug development
 help / color / mirror / Atom feed
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



             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