On Mon, Nov 3, 2008 at 14:18, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > On Mon, Nov 3, 2008 at 12:12, Juergen Beisert <jbe@xxxxxxxxxxxxxx> wrote: >> On Montag, 3. November 2008, Kay Sievers wrote: >>> On Mon, Nov 3, 2008 at 11:12, Juergen Beisert <jbe@xxxxxxxxxxxxxx> wrote: >>> > has anybody an idea how to write some rules to match devices from the mtd >>> > framework? > > ... > >>> 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. > > It is something that should be changed in mtd. NAND for example > registers the device in drivers/mtd/nand/mxc_nand.c. Before that, it > has handled the platform device *pdev. > > We would need to pass the pdev down to the mtd core and set "struct > gendisk->driverfs_dev" to &pdev->dev, and the NAND mtd devices would > show up with a device path like: > /sys/devices/platform/mxc_nand.0/blockmtdblock4 With a slash obviously: /sys/devices/platform/mxc_nand.0/block/mtdblock4 The "virtual" would go away, and it will actually start to export what's going on here. > With these devices as parents, you can match on any property or device > name with usual udev rules. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
