From: Boris Brezillon <boris.brezillon@bootlin.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "David Woodhouse" <dwmw2@infradead.org>,
"Brian Norris" <computersforpeace@gmail.com>,
"Boris Brezillon" <boris.brezillon@free-electrons.com>,
"Marek Vasut" <marek.vasut@gmail.com>,
"Richard Weinberger" <richard@nod.at>,
linux-mtd@lists.infradead.org, "Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH RFC API ONLY] mtd: get parsers from lookup table
Date: Mon, 16 Jul 2018 18:23:12 +0200 [thread overview]
Message-ID: <20180716182312.74fc55a9@bbrezillon> (raw)
In-Reply-To: <20180716111712.7636-1-zajec5@gmail.com>
Hi Rafal,
On Mon, 16 Jul 2018 13:17:12 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Existing implementation of specifying flash device parsers became a bit
> hacky and needs a cleanup. Currently it requires:
> 1) Passing parsers in a custom platform data by arch code
> or
> 2) Hardcoding parsers table in a flash driver
>
> The purpose of the new implementation is to:
> 1) Clean up flash drivers
> 2) Have a generic solution
> 3) Avoid code duplication
>
> That new implementation assigns table of parsers to a MTD's parent
> device. That way flash driver doesn't have to take care of passing
> parsers. It's inspired by GPIO lookup table.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> It's obviously a RFC patch only. It doesn't really implement anything.
> It DOESN'T COMPILE.
>
> I'd like to know if you like this idea and if it's worth for me to
> actually spend time implementing it.
I love the idea. Actually, I'd like to extend that to fixed partition
definitions (those passed to mtd_device_register()) so that they can be
parsed by the fixed-partition parser (the one already taking care of
compatible = "fixed-partitions").
One comment below.
> ---
> arch/arm/mach-pxa/corgi.c | 21 +++++++++++++--------
> drivers/mtd/mtdpart.c | 4 ++++
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
> index 9a5a35e90769..0ff77e078d2b 100644
> --- a/arch/arm/mach-pxa/corgi.c
> +++ b/arch/arm/mach-pxa/corgi.c
> @@ -615,16 +615,8 @@ static struct nand_bbt_descr sharpsl_bbt = {
> .pattern = scan_ff_pattern
> };
>
> -static const char * const probes[] = {
> - "cmdlinepart",
> - "ofpart",
> - "sharpslpart",
> - NULL,
> -};
> -
> static struct sharpsl_nand_platform_data sharpsl_nand_platform_data = {
> .badblock_pattern = &sharpsl_bbt,
> - .part_parsers = probes,
> };
>
> static struct resource sharpsl_nand_resources[] = {
> @@ -688,6 +680,16 @@ static struct i2c_board_info __initdata corgi_i2c_devices[] = {
> { I2C_BOARD_INFO("wm8731", 0x1b) },
> };
>
> +static struct mtd_parser_lookup_table corgi_mtd_parser_lookup_table = {
> + .dev_name = NULL, /* Set with registered name */
Can't you guess the device name? It's really weird that you have to
register the lookup table after the device has been registered. I
already had a similar discussion on GPIO lookup tables registration on
ams-delta here [1], and I think my comments apply to this case as well.
> + .table = {
> + { .parser = "cmdlinepart" },
> + { .parser = "ofpart" },
> + { .parser = "sharpslpart" },
> + { },
> + },
> +};
> +
> static void corgi_poweroff(void)
> {
> if (!machine_is_corgi())
> @@ -740,6 +742,9 @@ static void __init corgi_init(void)
>
> platform_add_devices(devices, ARRAY_SIZE(devices));
>
> + corgi_mtd_parser_lookup_table.dev_name = dev_name(&sharpsl_nand_device.dev);
> + mtd_parsers_add_lookup_table(corgi_mtd_parser_lookup_table);
> +
> regulator_has_full_constraints();
> }
>
> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> index 52e2cb35fc79..0d96857a57d0 100644
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
> @@ -936,6 +936,10 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
> struct mtd_part_parser *parser;
> int ret, err = 0;
>
> + if (!types) {
> + types = mtd_parsers_get(master->dev.parent);
> + }
> +
> if (!types)
> types = mtd_is_partition(master) ? default_subpartition_types :
> default_mtd_part_types;
Regards,
Boris
[1]https://patchwork.ozlabs.org/patch/920798/
next prev parent reply other threads:[~2018-07-16 16:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-16 11:17 [PATCH RFC API ONLY] mtd: get parsers from lookup table Rafał Miłecki
2018-07-16 16:23 ` Boris Brezillon [this message]
2018-07-16 20:58 ` Rafał Miłecki
2018-07-16 21:11 ` Boris Brezillon
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=20180716182312.74fc55a9@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=zajec5@gmail.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.