Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754298AbbLKIol (ORCPT ); Fri, 11 Dec 2015 03:44:41 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:35456 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752557AbbLKIoj (ORCPT ); Fri, 11 Dec 2015 03:44:39 -0500 MIME-Version: 1.0 In-Reply-To: <20151210205449.GL144338@google.com> References: <1449292763-129421-1-git-send-email-computersforpeace@gmail.com> <20151210205449.GL144338@google.com> Date: Fri, 11 Dec 2015 09:44:37 +0100 X-Google-Sender-Auth: Rk3opFPfHpA_CLaAJgZjOoxppOE Message-ID: Subject: Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support From: Geert Uytterhoeven To: Brian Norris 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2887 Lines: 62 Hi Brian, On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris wrote: > 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? I don't have an immediate use case. Just looking at it from a high-level viewpoint. > 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 :) There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm working on have. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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/