Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751860AbbLJVHD (ORCPT ); Thu, 10 Dec 2015 16:07:03 -0500 Received: from mail-pf0-f170.google.com ([209.85.192.170]:36584 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751160AbbLJVHA (ORCPT ); Thu, 10 Dec 2015 16:07:00 -0500 Date: Thu, 10 Dec 2015 13:06:56 -0800 From: Brian Norris To: Jonas Gorski Cc: MTD Maling List , "linux-kernel@vger.kernel.org" , Boris Brezillon , Linus Walleij , Geert Uytterhoeven , Simon Arlott , Jason Gunthorpe , "devicetree@vger.kernel.org" , devicetree-spec@vger.kernel.org, Rob Herring , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , Hauke Mehrtens , Arnd Bergmann , David Hendricks Subject: Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support Message-ID: <20151210210656.GM144338@google.com> References: <1449292763-129421-1-git-send-email-computersforpeace@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3990 Lines: 96 On Sat, Dec 05, 2015 at 12:35:42PM +0100, Jonas Gorski wrote: > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris > 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@10000 { > reg = <0x10000 0x3d0000>; > label = "firmware"; > compatible = "brcm,bcm6345-imagetag"; > }; > > partition@3e0000 { > reg = <0x3e0000 0x10000>; > label = "art"; > read-only; > }; > > partition@3f0000 { > 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. I had your (and others') prior attempts and suggestions in mind when planning this, and I agree that the binding looks extendible to cases like that. I haven't yet worked out what a good MTD infrastructure for that would look like, so I stuck with defining and implementing only what I know use :) > > 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. Not necessarily. One of my current use cases has a boot SPI NOR flash + an eMMC rootfs. Modules can be loaded from eMMC. BTW, I'm realizing that if partition parsers are forced to built-in only, then we'd have to do the same for the MTD core (or at least, the MTD core that handles partitioning). Not sure if that's a desirable trade-off. (Again, block support is 'bool' in Kconfig, if we're trying to compare.) Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/