linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* device attributes not propogating all of the time
@ 2009-11-18  9:13 Daniel Drake
  2009-11-18 16:14 ` Andrey Borzenkov
  2009-11-18 16:24 ` Daniel Drake
  0 siblings, 2 replies; 3+ messages in thread
From: Daniel Drake @ 2009-11-18  9:13 UTC (permalink / raw)
  To: linux-hotplug

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: device attributes not propogating all of the time
  2009-11-18  9:13 device attributes not propogating all of the time Daniel Drake
@ 2009-11-18 16:14 ` Andrey Borzenkov
  2009-11-18 16:24 ` Daniel Drake
  1 sibling, 0 replies; 3+ messages in thread
From: Andrey Borzenkov @ 2009-11-18 16:14 UTC (permalink / raw)
  To: linux-hotplug

[-- Attachment #1: Type: Text/Plain, Size: 596 bytes --]

On Wednesday 18 of November 2009 12:13:06 Daniel Drake wrote:
> 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}"

I do not know whether behaviour you describe is a bug, but you should be 
able to get the same simpler

SUBSYSTEMS=="mmc_host", KERNEL=="mmcblk*", SYMLINK+="disk/mmc/%b"

I guess you should be able to also stick SUBSYSTEM=="block" in it.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: device attributes not propogating all of the time
  2009-11-18  9:13 device attributes not propogating all of the time Daniel Drake
  2009-11-18 16:14 ` Andrey Borzenkov
@ 2009-11-18 16:24 ` Daniel Drake
  1 sibling, 0 replies; 3+ messages in thread
From: Daniel Drake @ 2009-11-18 16:24 UTC (permalink / raw)
  To: linux-hotplug

On Wed, 2009-11-18 at 19:14 +0300, Andrey Borzenkov wrote:
> I do not know whether behaviour you describe is a bug, but you should be 
> able to get the same simpler
> 
> SUBSYSTEMS="mmc_host", KERNEL="mmcblk*", SYMLINK+="disk/mmc/%b"
> 
> I guess you should be able to also stick SUBSYSTEM="block" in it.

Nice and simple - thanks for pointing that out!

Daniel



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-11-18 16:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-18  9:13 device attributes not propogating all of the time Daniel Drake
2009-11-18 16:14 ` Andrey Borzenkov
2009-11-18 16:24 ` Daniel Drake

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).