From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from b.ns.miles-group.at ([95.130.255.144] helo=radon.swed.at) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bF5Km-0007Xq-Sk for linux-mtd@lists.infradead.org; Mon, 20 Jun 2016 19:58:14 +0000 Subject: Re: [PATCH 1/2] ubi: mount partitions specified in device tree To: Arnd Bergmann References: <20160619130514.GB820@makrotopia.org> <6411961.soYuJ4Ixfs@wuerfel> <5767A8A3.4030004@nod.at> <4012191.NTCe8d2REM@wuerfel> Cc: Hauke Mehrtens , Daniel Golle , Boris Brezillon , mark.rutland@arm.com, devicetree@vger.kernel.org, dedekind1@gmail.com, robh+dt@kernel.org, linux-mtd@lists.infradead.org, computersforpeace@gmail.com, dwmw2@infradead.org From: Richard Weinberger Message-ID: <57684AB9.5040607@nod.at> Date: Mon, 20 Jun 2016 21:57:45 +0200 MIME-Version: 1.0 In-Reply-To: <4012191.NTCe8d2REM@wuerfel> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Am 20.06.2016 um 17:08 schrieb Arnd Bergmann: >> Since blocks on a MTD can render bad you'd lose the table sooner or later. >> That's why we cannot store it on the MTD directly. >> Defining the table in DT is at least less ugly than using the mtdparts= >> kernel parameter. > > Right, there would be no benefit in using the kernel command line, > it just moves the information to another place inside of the same DT > (the /chosen property). > > I think you can normally rely on the first block being readable > on flash, in particular if you write it very rarely (when updating > the partition information), so it would be technically possible to > have a partition table in there, but in practice that's not how > things are done, so the argument is useless. Speaking of NAND, only SLC (and also here not all) chips guarantee that the first block is better than the other ones. Thanks, //richard From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Weinberger Subject: Re: [PATCH 1/2] ubi: mount partitions specified in device tree Date: Mon, 20 Jun 2016 21:57:45 +0200 Message-ID: <57684AB9.5040607@nod.at> References: <20160619130514.GB820@makrotopia.org> <6411961.soYuJ4Ixfs@wuerfel> <5767A8A3.4030004@nod.at> <4012191.NTCe8d2REM@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4012191.NTCe8d2REM@wuerfel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org To: Arnd Bergmann Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, dedekind1@gmail.com, Hauke Mehrtens , Daniel Golle , robh+dt@kernel.org, Boris Brezillon , linux-mtd@lists.infradead.org, computersforpeace@gmail.com, dwmw2@infradead.org List-Id: devicetree@vger.kernel.org Am 20.06.2016 um 17:08 schrieb Arnd Bergmann: >> Since blocks on a MTD can render bad you'd lose the table sooner or later. >> That's why we cannot store it on the MTD directly. >> Defining the table in DT is at least less ugly than using the mtdparts= >> kernel parameter. > > Right, there would be no benefit in using the kernel command line, > it just moves the information to another place inside of the same DT > (the /chosen property). > > I think you can normally rely on the first block being readable > on flash, in particular if you write it very rarely (when updating > the partition information), so it would be technically possible to > have a partition table in there, but in practice that's not how > things are done, so the argument is useless. Speaking of NAND, only SLC (and also here not all) chips guarantee that the first block is better than the other ones. Thanks, //richard ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/