[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc5c393d-c495-8f0d-9cc8-4e195c25c237@huawei.com>
Date: Mon, 25 Sep 2023 22:22:12 +0800
From: ZhaoLong Wang <wangzhaolong1@...wei.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
CC: <richard@....at>, <vigneshr@...com>,
<linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
<chengzhihao1@...wei.com>, <yi.zhang@...wei.com>,
<yangerkun@...wei.com>
Subject: Re: [RFC] mtd: Fix error code loss in mtdchar_read() function.
> There is this comment right above, and I'm not sure it is still up to
> date because I believe many drivers just don't provide the data upon
> ECC error:
After observing the nand_base framework code, I think the current nand_base
framework can limit the length of retlen to 0 when an ECC error occurs. The
prerequisite is that the NAND driver development personnel can correctly
provide
the return value of the function according to the requirements of the
chip->ecc.read_page()
callback.
However, the read_page() callback comment does not notice the
particularity of the
following two error codes:
* -EUCLEAN - Returned by the MTD layer when maxbitflips greater then
bitflip_threshold
* -EBADMSG - Returned by NAND Generic Layer when the statistical ECC
error stats
changes and the number of retries is exhausted.
These two error codes are handled by the upper layer and should not be
returned by the
NAND driver developer. But some driver developers don't realize this.
So I don't think it's worth fixing right now, but is the description of
the return value of the
callback too simplistic? Is there any other more detailed description
document for reference?
Powered by blists - more mailing lists