[PATCH] MTD OneNAND OMAP2/3: allow giving partition layout as module parameter

[Adrian Hunter]

Korhonen Mika.2 (EXT-Ardites/Oulu) wrote:
> Artem Bityutskiy wrote:
>> On Thu, 2009-09-03 at 14:15 +0300, Mika Korhonen wrote:
>>   
>>> Add module parameter "parts" to omap2-onenand driver. Parameter format is
>>> the same as for cmdlinepart except mtd-id must not be specified - it
>>> gets prepended by the driver, i.e.: parts=<partdef>[,<partdef>]*
>>>
>>> This allows one to repartition the OneNAND chip and is useful for flashing
>>> applications that do the partitioning from scratch or want to backup and
>>> update the partitioning.
>>>
>>> Signed-off-by: Mika Korhonen <ext-mika.2.korhonen at nokia.com>
>>> ---
>>>  drivers/mtd/cmdlinepart.c   |   35 +++++++++++++++++++++++++++++------
>>>  drivers/mtd/onenand/omap2.c |   29 +++++++++++++++++++++++++++++
>>>  2 files changed, 58 insertions(+), 6 deletions(-)
>>>     
>> This should not be onenand module parameters actually. This
>> re-partitioning should be done via an mtd device ioctl instead.
>>
>> Could you try to introduce a new mtd ioctl?
>>
>> I know the partitioning in mtd is ugly, so you may hit some challenges.
>> E.g., all these special cases like
>>
>> #ifdef CONFIG_MTD_PARTITIONS
>>         /* Deregister partitions */
>>         del_mtd_partitions (mtd);
>> #endif
>>         /* Deregister the device */
>>         del_mtd_device (mtd);
>>
>> make no sense and should die. We should always have partitioning support
>> instead. So the mtdpart module should also die and partitioning support
>> should become part of mtdcore.
>>
>>   
> I agree, actually my first intention to was to make it more generic but 
> the framework indeed would have needed non-minor rework, so I took the 
> easy route to get started.

Could we just have the cmdlinepart change for now and make re-partitioning
a separate issue?