[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230102174517.1ccb3654@xps-13>
Date: Mon, 2 Jan 2023 17:45:17 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Samuel Holland <samuel@...lland.org>
Cc: Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Boris Brezillon <bbrezillon@...nel.org>,
Brian Norris <computersforpeace@...il.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mtd@...ts.infradead.org, linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH 4/7] mtd: rawnand: sunxi: Fix ECC strength maximization
Hi Samuel,
samuel@...lland.org wrote on Mon, 2 Jan 2023 09:59:29 -0600:
> Hi Miquèl,
>
> On 1/2/23 03:11, Miquel Raynal wrote:
> > Hi Samuel,
> >
> > samuel@...lland.org wrote on Thu, 29 Dec 2022 12:15:23 -0600:
> >
> >> This is already accounted for in the subtraction for OOB, since the BBM
> >> overlaps the first OOB dword. With this change, the driver picks the
> >> same ECC strength as the vendor driver.
> >>
> >> Fixes: 4796d8655915 ("mtd: nand: sunxi: Support ECC maximization")
> >> Signed-off-by: Samuel Holland <samuel@...lland.org>
> >> ---
> >>
> >> drivers/mtd/nand/raw/sunxi_nand.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
> >> index 1bddeb1be66f..1ecf2cee343b 100644
> >> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> >> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> >> @@ -1643,8 +1643,7 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
> >> ecc->size = 1024;
> >> nsectors = mtd->writesize / ecc->size;
> >>
> >> - /* Reserve 2 bytes for the BBM */
> >> - bytes = (mtd->oobsize - 2) / nsectors;
> >> + bytes = mtd->oobsize / nsectors;
> >
> > I'm sorry but I don't think we can make this work. This change would
> > break all existing users...
>
> OK, it is not too much of an issue because I can manually specify the
> ECC parameters in the devicetree. Do you think it makes sense to fix
> this when adding new hardware variants/compatible strings?
Actually, looking at the code again, I don't get how the above diff
could be valid. The "maximize strength" logic (in which this diff is)
looks for the biggest region to store ECC bytes. These bytes cannot
be stored on the BBM, which "mtd->oobsize - 2" tries to avoid, so we
cannot get rid of this.
Thanks,
Miquèl
Powered by blists - more mailing lists