From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support Date: Fri, 11 Dec 2015 17:00:28 +0100 Message-ID: References: <1449292763-129421-1-git-send-email-computersforpeace@gmail.com> <20151210205449.GL144338@google.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=he+GF4h4GPnFvDJT4jw2nNhP0ake/+1szkfm62B6h3M=; b=AqzxMt2Iz3r9upKTAcq4yQ+wL7z1O0lgKmNsuODsW7vXMmy/2Y4cU/6NIDsK/5EErh kuqWz4kCvRSoJoO2f7CD0RIQEJga8OeIzl/twm2xaHHx8OkEfjdl6Auaqxuo4pYdUO4n 9fxySq3Vys4sitD2hdorzHOaOwC855OTTfV40UY17W9CZkCz8Sb36jRKWgCf+h/YbI4K HSPCHE4gmow86Wqu3zk+3KPJDPQnvrP0V36betKPYh5zQT1zsxRf8yqC+2rTysAe5y/U P3ByS41SxOOi+ZG8NfFI2FwyKQyAplim/z9qIYqfMXM9JJIxrMXUVDCY8O6JF6ATgcK/ 0I9w== In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Suchanek Cc: Brian Norris , Boris Brezillon , Arnd Bergmann , Geert Uytterhoeven , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Simon Arlott , Linus Walleij , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Jason Gunthorpe , David Hendricks , Jonas Gorski , Rob Herring , MTD Maling List , Hauke Mehrtens Hi Michal, On Fri, Dec 11, 2015 at 4:34 PM, Michal Suchanek wrote: > On 11 December 2015 at 09:44, Geert Uytterhoeven wrote: >> 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. >> > > Yes, you can dump the content of a NOR flash to a file, attach a loop > device to it, and if block devices had the ability to use flash > partitioning access the different partitions. > > Maybe it would be more useful to use some kind of mtdloop, though. > There might even be one already. I never needed it. That's the inverse, which looks like a solid use case to me ;-) E.g. for investigation or virtualization. You can do this already in userspace with kpartx, though. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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 devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html