Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752180AbbLJUy4 (ORCPT ); Thu, 10 Dec 2015 15:54:56 -0500 Received: from mail-pa0-f53.google.com ([209.85.220.53]:35000 "EHLO mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750715AbbLJUyx (ORCPT ); Thu, 10 Dec 2015 15:54:53 -0500 Date: Thu, 10 Dec 2015 12:54:49 -0800 From: Brian Norris To: Geert Uytterhoeven Cc: MTD Maling List , "linux-kernel@vger.kernel.org" , Boris Brezillon , Linus Walleij , Geert Uytterhoeven , Simon Arlott , Jason Gunthorpe , Jonas Gorski , "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: <20151210205449.GL144338@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: 2246 Lines: 44 On Sat, Dec 05, 2015 at 11:15:54AM +0100, Geert Uytterhoeven wrote: > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris > wrote: > > 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. > > I read the second reason, but would it be useful to (partially) merge > block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos > partitions > on an mtd device?? I kinda agree with Michal: is there a good use case? Really, MTD partitioning is not a highly-scalable design. Particularly, it's not typically that well-suited to large (read: unreliable) NAND flash, where fixing partitions at the raw flash level mostly serves to restrict UBI's ability to wear-level across the device. For that sort of case, it's best if people are using UBI volumes on a (mostly?) unpartitioned MTD, instead of using MTD partitions as the main separation mechanism. Also, most partition designs (either MTD or block) aren't very robust against bitflips, read disturb, etc. IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash, and so I don't plan to do that sort of work myself. If you can provide some better argument for it, and some nice maintainable code to go with it, then of course it could be considered :) Regards, 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/