linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Beisert <jbe@pengutronix.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: How to write rules for mtd based devices
Date: Mon, 03 Nov 2008 11:12:10 +0000	[thread overview]
Message-ID: <200811031212.11156.jbe@pengutronix.de> (raw)
In-Reply-To: <200811031112.06061.jbe@pengutronix.de>

Kay,

On Montag, 3. November 2008, Kay Sievers wrote:
> On Mon, Nov 3, 2008 at 11:12, Juergen Beisert <jbe@pengutronix.de> wrote:
> > has anybody an idea how to write some rules to match devices from the mtd
> > framework?
> >
> > All I get is:
> > ------------------------------------------------------------------
> > $ udevadm info -a -p /sys/block/mtdblock5
> >
> > Udevinfo starts with the device specified by the devpath and then
> > walks up the chain of parent devices. It prints for every device
> > found, all possible attributes in the udev rules key format.
> > A rule to match, can be composed by the attributes of the device
> > and the attributes from one single parent device.
> >
> >  looking at device '/devices/virtual/block/mtdblock5':
> >    KERNEL="mtdblock5"
> >    SUBSYSTEM="block"
> >    DRIVER=""
> >    ATTR{range}="1"
> >    ATTR{removable}="0"
> >    ATTR{ro}="0"
> >    ATTR{size}="1024"
> >    ATTR{capability}="10"
> >    ATTR{stat}="       0        0        0        0        0        0    
> >    0        0        0        0        0"
> > ------------------------------------------------------------------
> >
> > And its mostly the same for all the other mtdblock devices.
> >
> > The other frameworks like SATA and USB providing much more information
> > about their bus controllers and connected devices to find adequate
> > matching rules. But mtd seems very uncommunicative, or do I query the
> > wrong path to search for usefull rules to match?
>
> Seems, there is not much you can do with the current information it
> exposes. What is the hardware behind these mtd devices? Are these
> devices show up somewhere in /sys/devices/, maybe as platform devices?
> Then we could try to make the kernel use these as parents for the
> block devices, so the block devices would not be "virtual".

MTDs are simple memory devices. Flash (NOR or NAND type) and SRAM for example. 
They are connected through a simple address/data bus, some also via SPI 
interface. About each of these devices the kernel knows at least the 
manufacturer and the device name (for flash memory this info can be 
autodetected). For the other types mostly a platform structure provides this 
information. On my ARM (i.MX27 CPU) tree types of memory is available:

SRAM:
/sys/bus/platform/devices/mtd-ram.0

NAND-flash:
/sys/bus/platform/devices/mxc_nand.0

NOR-flash:
/sys/bus/platform/devices/physmap-flash.0

Currently the NOR flash is using three partitions so I get:

$ ls -l /dev/mtd*
crw-rw----    1 root     root      90,   0 Jan  1 00:00 /dev/mtd0
crw-rw----    1 root     root      90,   1 Jan  1 00:00 /dev/mtd0ro
crw-rw----    1 root     root      90,   2 Jan  1 00:00 /dev/mtd1
crw-rw----    1 root     root      90,   3 Jan  1 00:00 /dev/mtd1ro
crw-rw----    1 root     root      90,   4 Jan  1 00:00 /dev/mtd2
crw-rw----    1 root     root      90,   5 Jan  1 00:00 /dev/mtd2ro
crw-rw----    1 root     root      90,   6 Jan  1 00:00 /dev/mtd3
crw-rw----    1 root     root      90,   7 Jan  1 00:00 /dev/mtd3ro
crw-rw----    1 root     root      90,   8 Jan  1 00:00 /dev/mtd4
crw-rw----    1 root     root      90,   9 Jan  1 00:00 /dev/mtd4ro
crw-rw----    1 root     root      90,  10 Jan  1 00:00 /dev/mtd5
crw-rw----    1 root     root      90,  11 Jan  1 00:00 /dev/mtd5ro
brw-rw----    1 root     root      31,   0 Jan  1 00:00 /dev/mtdblock0
brw-rw----    1 root     root      31,   1 Jan  1 00:00 /dev/mtdblock1
brw-rw----    1 root     root      31,   2 Jan  1 00:00 /dev/mtdblock2
brw-rw----    1 root     root      31,   3 Jan  1 00:00 /dev/mtdblock3
brw-rw----    1 root     root      31,   4 Jan  1 00:00 /dev/mtdblock4
brw-rw----    1 root     root      31,   5 Jan  1 00:00 /dev/mtdblock5

mtd*0 ... mtd*3 are the three partitions on the NOR flash (its also the memory 
to boot from), mtd*4 is the NAND memory, mtd*5 is the SRAM. All I want is to 
detect the NAND and the SRAM to create special links or node names for these 
devices to be independent from the partition count of the NOR memory and the 
changing device node numbers when this count changes.

> For now you might need to live with the filesystem metadata
> uuid/label, which work as usual for these devices, right?

Hmm, not sure, if JFFS2 provides a fs label.

Regards,
Juergen

-- 
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
         Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

  parent reply	other threads:[~2008-11-03 11:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-03 10:12 How to write rules for mtd based devices Juergen Beisert
2008-11-03 10:27 ` Kay Sievers
2008-11-03 11:12 ` Juergen Beisert [this message]
2008-11-03 13:18 ` Kay Sievers
2008-11-03 13:21 ` Kay Sievers
2008-11-03 13:39 ` Juergen Beisert
2008-11-03 14:11 ` Kay Sievers

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=200811031212.11156.jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --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).