On Mon, Nov 3, 2008 at 14:39, Juergen Beisert <juergen127@xxxxxxxxxxxxxx> wrote: > On Montag, 3. November 2008, Kay Sievers wrote: >> 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. > > What does it mean? Should we forward this to the mdt mail list? I we are lucky, someone would pick that up, but I wouldn't expect something to happen without a patch that seems to work. :) Unfortunately, I don't have any system with such a platform device, where I ever built a kernel for. Otherwise I would give it a try, it should only be a few things needed. 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
