[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOiHx==8TFK9t4h2C0Q+j==nuRP3EbyVa+nuYuSEj_LCDa820Q@mail.gmail.com>
Date: Sat, 5 Dec 2015 12:35:42 +0100
From: Jonas Gorski <jogo@...nwrt.org>
To: Brian Norris <computersforpeace@...il.com>
Cc: MTD Maling List <linux-mtd@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
Linus Walleij <linus.walleij@...aro.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Simon Arlott <simon@...e.lp0.eu>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
devicetree-spec@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
Rafał Miłecki <zajec5@...il.com>,
Hauke Mehrtens <hauke@...ke-m.de>,
Arnd Bergmann <arnd@...db.de>,
David Hendricks <dhendrix@...omium.org>
Subject: Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support
Hi,
On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
<computersforpeace@...il.com> wrote:
> Hi,
>
> There have been several discussions [1] about adding a device tree binding for
> associating flash devices with the partition parser(s) that are used on the
> flash. There are a few reasons:
>
> (1) drivers shouldn't have to be encoding platform knowledge by listing what
> parsers might be used on a given system (this is the currently all that's
> supported)
> (2) we can't just scan for all supported parsers (like the block system does), since
> there is a wide diversity of "formats" (no standardization), and it is not
> always safe or efficient to attempt to do so, particularly since many of
> them allow their data structures to be placed anywhere on the flash, and
> so require scanning the entire flash device to find them.
>
> So instead, let's support a new binding so that a device tree can specify what
> partition formats might be used. This seems like a reasonable choice (even
> though it's not strictly a hardware description) because the flash layout /
> partitioning is often very closely tied with the bootloader/firmware, at
> production time.
On a first glance this looks good to me, and looks easily extensible
for application of non-complete partition parsers.
E.g. for the "brcm,bcm6345-imagetag" we would want to actually do something like
partitions {
....
partition@0 {
reg = <0x0 0x10000>;
label = "cfe";
read-only;
};
partition@...00 {
reg = <0x10000 0x3d0000>;
label = "firmware";
compatible = "brcm,bcm6345-imagetag";
};
partition@...000 {
reg = <0x3e0000 0x10000>;
label = "art";
read-only;
};
partition@...000 {
reg = <0x3f0000 0x10000>;
label = "nvram";
read-only;
};
};
as the image tag can only specify the offsets and sizes of the rootfs
and kernel parts, but not of any other parts.
>
> Also, as an example first-use of this mechanism, I support Google's FMAP flash
> structure, used on Chrome OS devices.
>
> Note that this is an RFC, mainly for the reason noted in patch 6 ("RFC: mtd:
> partitions: enable of_match_table matching"): the of_match_table support won't
> yet autoload a partition parser that is built as a module. I'm not quite sure
> if there's a lot of value in supporting MTD parsers as modules (block partition
> support can't be), but that is supported for "by-name" parser lookups in MTD
> already, so I don't feel like dropping that feature yet. Tips or thoughts are
> particularly welcome on this aspect!
I would assume a lot of the cases these would be a chicken-egg
problem, you need the parser to be able to find and mount the rootfs,
but you you need mount the rootfs to load the parser.
> Also note that there's an existing undocumented binding for a
> "linux,part-probe" property, but it is only usable on the physmap_of.c driver
> at the moment, and it is IMO not a good binding. I posted my thoughts on that
> previously here [2], and since no one else cared to make a better one...I did
> it myself.
>
> I'd love it if we could kill the unreviewed binding off in favor of something
> more like this...
I agree fully that this is a bad binding, as it exposes internal names
that aren't supposed to be fixed.
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists