Re: [PATCH] mtd: rawnand: ams-delta: Drop board specific partition info

From: Janusz Krzysztofik
Date: Sun Mar 24 2019 - 16:40:42 EST


Hi,

On Sunday, March 24, 2019 8:24:48 PM CET H. Nikolaus Schaller wrote:
> Hi,
>
> > Am 24.03.2019 um 19:59 schrieb Aaro Koskinen <aaro.koskinen@xxxxxx>:
> >
> > Hi,
> >
> > On Sun, Mar 24, 2019 at 05:48:22PM +0100, Janusz Krzysztofik wrote:
> >> Hi Aaro,
> >>
> >> Thanks for your review.
> >>
> >> On Wednesday, March 20, 2019 2:16:30 AM CET Aaro Koskinen wrote:
> >>> On Tue, Mar 19, 2019 at 11:37:18PM +0100, Janusz Krzysztofik wrote:
> >>>> After recent modifications, only a hardcoded partition info makes
> >>>> the driver device specific. Other than that, the driver uses GPIO
> >>>> exclusively and can be used on any hardware.
> >>>>
> >>>> Drop the partition info and use MTD partition parser with default
> >>>> list of partition types instead.
> >>>>
> >>>> Amstrad Delta users should append the followig partition info to their
> >>> ^^^^^^^^
> >>> Should be "following".
> >>>
> >>>> kernel command line, possibly by embedding it in CONFIG_CMDLINE:
> >>>> mtdparts=ams-delta-nand:3584k(Kernel),256k(u-boot),256k(u-boot_params),
\
> >>>> 256k(Amstrad_LDR),27m(File_system),768k(PBL_reserved). For their
> >>>> convenience, select CONFIG_MTD_CMDLINE_PARTS symbol from that board
> >>>> Kconfig automatically if this NAND driver is also selected.
> >>>>
> >>>> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@xxxxxxxxx>
> >>>> Cc: Tony Lindgren <tony@xxxxxxxxxxx>
> >>>
> >>> Could we move the fixed partition setup to the board file
> >>> instead? Otherwise this kind of change is not really nice for the users,
> >>> as it will likely break existing setups. The default partition layout
> >>> should remain the same.
> >>
> >> I'm wondering if it would be acceptable to pass partition info from a
.dts
> >> file. I think that would be a better, more modern approach than adding a
new
> >> header under include/linux/platform_data.
> >
> > Hmm, I thought there was some generic way to define partitions without
> > adding any new headers. But if that is not possible, then I guess your
> > CMDLINE proposal is the preferred one..
>
> I am not sure what you exactly need, but partitions can be defined in
> the DTS as children of some NAND drivers. Example:
> arch/arm/boot/dts/omap3-beagle.dts
> So this design pattern could be copied instead of using CMDLINE.

The problem is, OMAP1 has no device tree support. Other than that, your
proposed approach already works for me locally with some basic support for
device tree added to the board file.

Thanks,
Janusz