* Re: How to write rules for mtd based devices
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
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2008-11-03 10:27 UTC (permalink / raw)
To: linux-hotplug
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".
For now you might need to live with the filesystem metadata
uuid/label, which work as usual for these devices, right?
Kay
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: How to write rules for mtd based devices
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
2008-11-03 13:18 ` Kay Sievers
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Juergen Beisert @ 2008-11-03 11:12 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: How to write rules for mtd based devices
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
@ 2008-11-03 13:18 ` Kay Sievers
2008-11-03 13:21 ` Kay Sievers
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2008-11-03 13:18 UTC (permalink / raw)
To: linux-hotplug
On Mon, Nov 3, 2008 at 12:12, Juergen Beisert <jbe@pengutronix.de> wrote:
> 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?
...
>> 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 these devices as parents, you can match on any property or device
name with usual udev rules.
Kay
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: How to write rules for mtd based devices
2008-11-03 10:12 How to write rules for mtd based devices Juergen Beisert
` (2 preceding siblings ...)
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
5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2008-11-03 13:21 UTC (permalink / raw)
To: linux-hotplug
On Mon, Nov 3, 2008 at 14:18, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Mon, Nov 3, 2008 at 12:12, Juergen Beisert <jbe@pengutronix.de> wrote:
>> 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?
>
> ...
>
>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: How to write rules for mtd based devices
2008-11-03 10:12 How to write rules for mtd based devices Juergen Beisert
` (3 preceding siblings ...)
2008-11-03 13:21 ` Kay Sievers
@ 2008-11-03 13:39 ` Juergen Beisert
2008-11-03 14:11 ` Kay Sievers
5 siblings, 0 replies; 7+ messages in thread
From: Juergen Beisert @ 2008-11-03 13:39 UTC (permalink / raw)
To: linux-hotplug
Kay,
On Montag, 3. November 2008, Kay Sievers wrote:
> On Mon, Nov 3, 2008 at 14:18, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > On Mon, Nov 3, 2008 at 12:12, Juergen Beisert <jbe@pengutronix.de> wrote:
> >> 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?
> >
> > ...
> >
> >>> 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?
Regards
Juergen
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: How to write rules for mtd based devices
2008-11-03 10:12 How to write rules for mtd based devices Juergen Beisert
` (4 preceding siblings ...)
2008-11-03 13:39 ` Juergen Beisert
@ 2008-11-03 14:11 ` Kay Sievers
5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2008-11-03 14:11 UTC (permalink / raw)
To: linux-hotplug
On Mon, Nov 3, 2008 at 14:39, Juergen Beisert <juergen127@kreuzholzen.de> wrote:
> On Montag, 3. November 2008, Kay Sievers wrote:
>> On Mon, Nov 3, 2008 at 14:18, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> > On Mon, Nov 3, 2008 at 12:12, Juergen Beisert <jbe@pengutronix.de> wrote:
>> >> 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?
>> >
>> > ...
>> >
>> >>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread