All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: linux-omap@vger.kernel.org,
	Boris Brezillon <bbrezillon@kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Richard Weinberger <richard@nod.at>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] mtd: rawnand: ams-delta: Drop board specific partition info
Date: Sun, 24 Mar 2019 17:48:22 +0100	[thread overview]
Message-ID: <2631901.52Nzq63B5o@z50> (raw)
In-Reply-To: <20190320011630.GB7872@darkstar.musicnaut.iki.fi>

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@gmail.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> 
> 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.

The problem with a device tree based implementation is, I know of no u-boot 
version supporting both Amstrad Delta and FDT.  However, I've already tested 
two solutions that work for me.

One uses CONFIG_ARM_APPENDED_DTB and requires a user to manually append the 
blob to zImage and (re)generate uImage.  I'm not sure how much more user-
friendly it looks for you, compared to the command line version I proposed 
initially.

If the above is not acceptable. I can propose still another approach. The blob 
is automagically built and embedded into the kernel with some assembler glue, 
then unflattened from the board init_machine(), somehow similar to the way 
drivers/of/unittest.c does it.

Please advise which approach sounds best to you (platform_data, 
CONFIG_ARM_APPENDED_DTB or unittest like).

Thanks,
Janusz


> 
> A.
> 





______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Boris Brezillon <bbrezillon@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>
Subject: Re: [PATCH] mtd: rawnand: ams-delta: Drop board specific partition info
Date: Sun, 24 Mar 2019 17:48:22 +0100	[thread overview]
Message-ID: <2631901.52Nzq63B5o@z50> (raw)
In-Reply-To: <20190320011630.GB7872@darkstar.musicnaut.iki.fi>

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@gmail.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> 
> 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.

The problem with a device tree based implementation is, I know of no u-boot 
version supporting both Amstrad Delta and FDT.  However, I've already tested 
two solutions that work for me.

One uses CONFIG_ARM_APPENDED_DTB and requires a user to manually append the 
blob to zImage and (re)generate uImage.  I'm not sure how much more user-
friendly it looks for you, compared to the command line version I proposed 
initially.

If the above is not acceptable. I can propose still another approach. The blob 
is automagically built and embedded into the kernel with some assembler glue, 
then unflattened from the board init_machine(), somehow similar to the way 
drivers/of/unittest.c does it.

Please advise which approach sounds best to you (platform_data, 
CONFIG_ARM_APPENDED_DTB or unittest like).

Thanks,
Janusz


> 
> A.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Janusz Krzysztofik <jmkrzyszt@gmail.com>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: linux-omap@vger.kernel.org,
	Boris Brezillon <bbrezillon@kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Richard Weinberger <richard@nod.at>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
	linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] mtd: rawnand: ams-delta: Drop board specific partition info
Date: Sun, 24 Mar 2019 17:48:22 +0100	[thread overview]
Message-ID: <2631901.52Nzq63B5o@z50> (raw)
In-Reply-To: <20190320011630.GB7872@darkstar.musicnaut.iki.fi>

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@gmail.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> 
> 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.

The problem with a device tree based implementation is, I know of no u-boot 
version supporting both Amstrad Delta and FDT.  However, I've already tested 
two solutions that work for me.

One uses CONFIG_ARM_APPENDED_DTB and requires a user to manually append the 
blob to zImage and (re)generate uImage.  I'm not sure how much more user-
friendly it looks for you, compared to the command line version I proposed 
initially.

If the above is not acceptable. I can propose still another approach. The blob 
is automagically built and embedded into the kernel with some assembler glue, 
then unflattened from the board init_machine(), somehow similar to the way 
drivers/of/unittest.c does it.

Please advise which approach sounds best to you (platform_data, 
CONFIG_ARM_APPENDED_DTB or unittest like).

Thanks,
Janusz


> 
> A.
> 





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-24 16:48 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19 22:37 [PATCH] mtd: rawnand: ams-delta: Drop board specific partition info Janusz Krzysztofik
2019-03-19 22:37 ` Janusz Krzysztofik
2019-03-19 22:37 ` Janusz Krzysztofik
2019-03-20  1:16 ` Aaro Koskinen
2019-03-20  1:16   ` Aaro Koskinen
2019-03-20  1:16   ` Aaro Koskinen
2019-03-24 16:48   ` Janusz Krzysztofik [this message]
2019-03-24 16:48     ` Janusz Krzysztofik
2019-03-24 16:48     ` Janusz Krzysztofik
2019-03-24 18:59     ` Aaro Koskinen
2019-03-24 18:59       ` Aaro Koskinen
2019-03-24 18:59       ` Aaro Koskinen
2019-03-24 19:24       ` H. Nikolaus Schaller
2019-03-24 19:24         ` H. Nikolaus Schaller
2019-03-24 19:24         ` H. Nikolaus Schaller
2019-03-24 20:40         ` Janusz Krzysztofik
2019-03-24 20:40           ` Janusz Krzysztofik
2019-03-24 20:40           ` Janusz Krzysztofik
2019-03-24 20:30       ` Janusz Krzysztofik
2019-03-24 20:30         ` Janusz Krzysztofik
2019-03-24 20:30         ` Janusz Krzysztofik
2019-03-24 20:30         ` Janusz Krzysztofik
2019-03-24 22:33 ` [PATCH v2] " Janusz Krzysztofik
2019-03-24 22:33   ` Janusz Krzysztofik
2019-03-24 22:33   ` Janusz Krzysztofik
2019-04-17  9:40   ` Miquel Raynal
2019-04-17  9:40     ` Miquel Raynal
2019-04-17  9:40     ` Miquel Raynal
2019-04-17 23:09     ` Janusz Krzysztofik
2019-04-17 23:09       ` Janusz Krzysztofik
2019-04-17 23:09       ` Janusz Krzysztofik
2019-04-18  6:49       ` Miquel Raynal
2019-04-18  6:49         ` Miquel Raynal
2019-04-18  6:49         ` Miquel Raynal
2019-04-18 19:11         ` Janusz Krzysztofik
2019-04-18 19:11           ` Janusz Krzysztofik
2019-04-18 19:11           ` Janusz Krzysztofik
2019-04-24 18:02   ` [PATCH v3] " Janusz Krzysztofik
2019-04-24 18:02     ` Janusz Krzysztofik
2019-04-24 18:02     ` Janusz Krzysztofik
2019-04-24 22:14     ` Ladislav Michl
2019-04-24 22:14       ` Ladislav Michl
2019-04-24 22:14       ` Ladislav Michl
2019-04-25 18:42       ` Janusz Krzysztofik
2019-04-25 18:42         ` Janusz Krzysztofik
2019-04-25 18:42         ` Janusz Krzysztofik
2019-04-27  9:18         ` Ladislav Michl
2019-04-27  9:18           ` Ladislav Michl
2019-04-27  9:18           ` Ladislav Michl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2631901.52Nzq63B5o@z50 \
    --to=jmkrzyszt@gmail.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.