[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <814a343e-e4c4-3ef2-29e2-d6c56f3d5bbb@allwinnertech.com>
Date: Tue, 25 Jun 2019 19:56:10 +0800
From: liaoweixiong <liaoweixiong@...winnertech.com>
To: Schrempf Frieder <frieder.schrempf@...tron.de>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Vignesh Raghavendra <vigneshr@...com>,
Boris Brezillon <bbrezillon@...nel.org>,
Richard Weinberger <richard@....at>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Chuanhong Guo <gch981213@...il.com>,
Marek Vasut <marek.vasut@...il.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
Miquel Raynal <miquel.raynal@...tlin.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Brian Norris <computersforpeace@...il.com>,
David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RESEND PATCH v2] mtd: spinand: read return badly if the last
page has bitflips
Oh, i am sorry that i had misunderstanded your letter.
Thank you for your document and guidance.
On 2019/6/25 PM 3:04, Schrempf Frieder wrote:
> Hi liaoweixiong,
>
> On 25.06.19 05:08, Greg KH wrote:
>> On Tue, Jun 25, 2019 at 09:02:29AM +0800, liaoweixiong wrote:
>>> In case of the last page containing bitflips (ret > 0),
>>> spinand_mtd_read() will return that number of bitflips for the last
>>> page. But to me it looks like it should instead return max_bitflips like
>>> it does when the last page read returns with 0.
>>>
>>> Signed-off-by: liaoweixiong <liaoweixiong@...winnertech.com>
>>> Reviewed-by: Boris Brezillon <boris.brezillon@...labora.com>
>>> Reviewed-by: Frieder Schrempf <frieder.schrempf@...tron.de>
>>> Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
>>> ---
>>> drivers/mtd/nand/spi/core.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> <formletter>
>>
>> This is not the correct way to submit patches for inclusion in the
>> stable kernel tree. Please read:
>> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>> for how to do this properly.
>>
>> </formletter>
>
> FYI, you should not send the patch to stable@...r.kernel.org, but
> instead, as I said in my other reply, add the tag "Cc:
> stable@...r.kernel.org". See "Option 1" in the document Greg referred to.
>
> Thanks,
> Frieder
>
--
liaoweixiong
Powered by blists - more mailing lists