All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Md Sadre Alam <quic_mdalam@quicinc.com>
Cc: Gabor Juhos <j4g8y7@gmail.com>,  Mark Brown <broonie@kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	 Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	"Varadarajan Narayanan" <quic_varada@quicinc.com>,
	 Sricharan Ramabadhran <quic_srichara@quicinc.com>,
	 <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	 <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH next 2/2] spi: spi-qpic-snand: add support for 8 bits ECC strength
Date: Wed, 21 May 2025 09:52:31 +0200	[thread overview]
Message-ID: <87h61e8kow.fsf@bootlin.com> (raw)
In-Reply-To: <e9f460c3-a575-1014-cca7-27f1d79024e2@quicinc.com> (Md Sadre Alam's message of "Wed, 21 May 2025 11:08:02 +0530")

On 21/05/2025 at 11:08:02 +0530, Md Sadre Alam <quic_mdalam@quicinc.com> wrote:

> Hi,
>
> On 5/16/2025 7:44 PM, Miquel Raynal wrote:
>> 
>>>>> Interestingly enough, it reports the correct number of bit errors now.
>>>>> For me it seems, that the hardware reports the number of the corrected
>>>>> *bytes* instead of the corrected *bits*.
>>>> I doubt that, nobody counts bytes of errors.
>>>> You results are surprising. I initially though in favour of a software
>>>> bug, but then it looks even weirder than that. Alam?
>>> I have checked with HW team , the QPIC ECC HW engine reports the bit
>>> error byte wise not bit wise.
>>>
>>> e.g
>>>      Byte0 --> 2-bitflips --> QPIC ECC counts 1 only
>>>      Byte1 --> 3-bitflips --> QPIC ECC counts 1 only
>>>      Byte2 --> 1-bitflips --> QPIC ECC counts 1 only
>>>      Byte3 --> 4-bitflips --> QPIC ECC counts 1 only (in 8-bit ecc)
>>>      Byte4 --> 6-bitflips --> QPIC ECC counts 1 only (in 8-bit ecc)
>>>
>>> Hope this can clearify the things now.
>> o_O ????
>> How is that even useful? This basically means UBI will never refresh
>> the
>> data because we will constantly underestimate the number of bitflips! We
>> need to know the actual number, this averaging does not make any sense
>> for Linux. Is there another way to get the raw number of bitflips?
> I have re-checked with HW team, unfortunately currently there is no
> register fields available to get the raw number of bit flips. But
> for newer chipset they have fixed this issue. But currently the QPIC
> QPIC_NANDC_BUFFER_STATUS | 0x79B0018 register bit-8 will get set if
> there is uncorrectable bitflips happened.
>
> For 4-bit ECC if 5-bit raw bit flips happened then bit-8 will get set in
> QPIC_NANDC_BUFFER_STATUS.
>
> similar for 8-bit ECC if 9-bit raw bit flips happened then bit-8 will
> get set in QPIC_NANDC_BUFFER_STATUS.

I believe the unrecoverable situation is handled correctly. What is not
is the fact that we care about the number of bitflips before having a
failure because if it reaches a certain threshold (typically 2/3 of the
strength) the upper layer is responsible of moving the data around to
avoid loosing it.

You need to identify the hardware revision that fixed it and provide a
warning otherwise, or at least a comment in the code...

Thanks,
Miquèl

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Md Sadre Alam <quic_mdalam@quicinc.com>
Cc: Gabor Juhos <j4g8y7@gmail.com>,  Mark Brown <broonie@kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	 Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	"Varadarajan Narayanan" <quic_varada@quicinc.com>,
	 Sricharan Ramabadhran <quic_srichara@quicinc.com>,
	 <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	 <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH next 2/2] spi: spi-qpic-snand: add support for 8 bits ECC strength
Date: Wed, 21 May 2025 09:52:31 +0200	[thread overview]
Message-ID: <87h61e8kow.fsf@bootlin.com> (raw)
In-Reply-To: <e9f460c3-a575-1014-cca7-27f1d79024e2@quicinc.com> (Md Sadre Alam's message of "Wed, 21 May 2025 11:08:02 +0530")

On 21/05/2025 at 11:08:02 +0530, Md Sadre Alam <quic_mdalam@quicinc.com> wrote:

> Hi,
>
> On 5/16/2025 7:44 PM, Miquel Raynal wrote:
>> 
>>>>> Interestingly enough, it reports the correct number of bit errors now.
>>>>> For me it seems, that the hardware reports the number of the corrected
>>>>> *bytes* instead of the corrected *bits*.
>>>> I doubt that, nobody counts bytes of errors.
>>>> You results are surprising. I initially though in favour of a software
>>>> bug, but then it looks even weirder than that. Alam?
>>> I have checked with HW team , the QPIC ECC HW engine reports the bit
>>> error byte wise not bit wise.
>>>
>>> e.g
>>>      Byte0 --> 2-bitflips --> QPIC ECC counts 1 only
>>>      Byte1 --> 3-bitflips --> QPIC ECC counts 1 only
>>>      Byte2 --> 1-bitflips --> QPIC ECC counts 1 only
>>>      Byte3 --> 4-bitflips --> QPIC ECC counts 1 only (in 8-bit ecc)
>>>      Byte4 --> 6-bitflips --> QPIC ECC counts 1 only (in 8-bit ecc)
>>>
>>> Hope this can clearify the things now.
>> o_O ????
>> How is that even useful? This basically means UBI will never refresh
>> the
>> data because we will constantly underestimate the number of bitflips! We
>> need to know the actual number, this averaging does not make any sense
>> for Linux. Is there another way to get the raw number of bitflips?
> I have re-checked with HW team, unfortunately currently there is no
> register fields available to get the raw number of bit flips. But
> for newer chipset they have fixed this issue. But currently the QPIC
> QPIC_NANDC_BUFFER_STATUS | 0x79B0018 register bit-8 will get set if
> there is uncorrectable bitflips happened.
>
> For 4-bit ECC if 5-bit raw bit flips happened then bit-8 will get set in
> QPIC_NANDC_BUFFER_STATUS.
>
> similar for 8-bit ECC if 9-bit raw bit flips happened then bit-8 will
> get set in QPIC_NANDC_BUFFER_STATUS.

I believe the unrecoverable situation is handled correctly. What is not
is the fact that we care about the number of bitflips before having a
failure because if it reaches a certain threshold (typically 2/3 of the
strength) the upper layer is responsible of moving the data around to
avoid loosing it.

You need to identify the hardware revision that fixed it and provide a
warning otherwise, or at least a comment in the code...

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2025-05-21  7:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-02 19:31 [PATCH next 0/2] spi: spi-qpic-snand: enable 8 bits ECC strength support Gabor Juhos
2025-05-02 19:31 ` Gabor Juhos
2025-05-02 19:31 ` [PATCH next 1/2] mtd: nand: qpic-common: add defines for ECC_MODE values Gabor Juhos
2025-05-02 19:31   ` Gabor Juhos
2025-05-05 11:08   ` Md Sadre Alam
2025-05-05 11:08     ` Md Sadre Alam
2025-05-02 19:31 ` [PATCH next 2/2] spi: spi-qpic-snand: add support for 8 bits ECC strength Gabor Juhos
2025-05-02 19:31   ` Gabor Juhos
2025-05-05 11:17   ` Md Sadre Alam
2025-05-05 11:17     ` Md Sadre Alam
2025-05-05 13:21     ` Gabor Juhos
2025-05-05 13:21       ` Gabor Juhos
2025-05-12  8:32       ` Miquel Raynal
2025-05-12  8:32         ` Miquel Raynal
2025-05-12 20:19         ` Gabor Juhos
2025-05-12 20:19           ` Gabor Juhos
2025-05-13  7:32           ` Miquel Raynal
2025-05-13  7:32             ` Miquel Raynal
2025-05-13  9:01             ` Md Sadre Alam
2025-05-13  9:01               ` Md Sadre Alam
2025-05-13 15:35             ` Md Sadre Alam
2025-05-13 15:35               ` Md Sadre Alam
2025-05-16 14:14               ` Miquel Raynal
2025-05-16 14:14                 ` Miquel Raynal
2025-05-21  5:38                 ` Md Sadre Alam
2025-05-21  5:38                   ` Md Sadre Alam
2025-05-21  7:52                   ` Miquel Raynal [this message]
2025-05-21  7:52                     ` Miquel Raynal
2025-05-22 17:49                     ` Gabor Juhos
2025-05-22 17:49                       ` Gabor Juhos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h61e8kow.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=j4g8y7@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=quic_mdalam@quicinc.com \
    --cc=quic_srichara@quicinc.com \
    --cc=quic_varada@quicinc.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.