From: ycllin@mxic.com.tw To: "Miquel Raynal" <miquel.raynal@bootlin.com> Cc: juliensu@mxic.com.tw, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, richard@nod.at, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>, vigneshr@ti.com Subject: Re: [PATCH 0/2] Fix double counting of S/W ECC engines' ECC stat Date: Thu, 20 May 2021 18:56:54 +0800 [thread overview] Message-ID: <OF12EB0BE9.7879DE49-ON482586DB.0039FC49-482586DB.003C2449@mxic.com.tw> (raw) In-Reply-To: <20210513084523.41d1cdd6@xps13> Hi Miquèl, > "Miquel Raynal" <miquel.raynal@bootlin.com> > Re: [PATCH 0/2] Fix double counting of S/W ECC engines' ECC stat > > Hi YouChing, > > ycllin@mxic.com.tw wrote on Thu, 13 May 2021 10:11:02 +0800: > > > > "Miquel Raynal" <miquel.raynal@bootlin.com> > > <deleted> > > > > > > Good catch! > > > > > > However I don't think the current fix is valid because these engines > > > are meant to be used by the raw NAND core as well, I propose something > > > like the below, can you please tell me if it works as expected? (not > > > even build tested) > > > > > > Thanks, > > > Miquèl > > > > > > > > <deleted> > > > > Thanks for your work. > > > > I tested the two patches(yours and mine) separately in our environment: > > 1) MXIC NFC(&raw NAND),2) MXIC SPI host(&SPI-NAND) with S/W BCH engine. > > Both patches are valid(using nandtest/nandbiterrs, values of ecc_stats are > > normal). > > > > This seems to be because the function(nand_ecc_sw_bch_finish_io_req() > > in ecc-sw-bch.c) that would increase the ecc_stats counter is not used > > in the raw NAND world. Am I misunderstanding or is it platform dependency? > > I don't think it can be called a platform dependency, it's more like > legacy from the raw NAND world which makes the use of the generic ECC > framework hard and thus is limited to a given set of functions. > > > BTW, I think your modification should be more in line with the design > > spirit > > of generic ECC engine framework. > > Yes, ideally raw NAND should fully comply to this framework but this > would require a hundred days of work and dozens of available boards to > test. During the past 20 years people assumed NAND controller and ECC > engine were a single entity which makes the use of the generic ECC > framework hard to implemented in the raw NAND. So I decided not to put > all my energy there in order to first get this framework available to > SPI-NAND devices. Thanks for your detailed explanation. I agree with your change and it works fine in SPI-NAND world (with on-die or S/W ECC engines) and raw NAND world(with S/W ECC engines). Tested-by: YouChing Lin <ycllin@mxic.com.tw> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. ===================================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. ===================================================================== ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: ycllin@mxic.com.tw To: "Miquel Raynal" <miquel.raynal@bootlin.com> Cc: juliensu@mxic.com.tw, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, richard@nod.at, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>, vigneshr@ti.com Subject: Re: [PATCH 0/2] Fix double counting of S/W ECC engines' ECC stat Date: Thu, 20 May 2021 18:56:54 +0800 [thread overview] Message-ID: <OF12EB0BE9.7879DE49-ON482586DB.0039FC49-482586DB.003C2449@mxic.com.tw> (raw) In-Reply-To: <20210513084523.41d1cdd6@xps13> Hi Miquèl, > "Miquel Raynal" <miquel.raynal@bootlin.com> > Re: [PATCH 0/2] Fix double counting of S/W ECC engines' ECC stat > > Hi YouChing, > > ycllin@mxic.com.tw wrote on Thu, 13 May 2021 10:11:02 +0800: > > > > "Miquel Raynal" <miquel.raynal@bootlin.com> > > <deleted> > > > > > > Good catch! > > > > > > However I don't think the current fix is valid because these engines > > > are meant to be used by the raw NAND core as well, I propose something > > > like the below, can you please tell me if it works as expected? (not > > > even build tested) > > > > > > Thanks, > > > Miquèl > > > > > > > > <deleted> > > > > Thanks for your work. > > > > I tested the two patches(yours and mine) separately in our environment: > > 1) MXIC NFC(&raw NAND),2) MXIC SPI host(&SPI-NAND) with S/W BCH engine. > > Both patches are valid(using nandtest/nandbiterrs, values of ecc_stats are > > normal). > > > > This seems to be because the function(nand_ecc_sw_bch_finish_io_req() > > in ecc-sw-bch.c) that would increase the ecc_stats counter is not used > > in the raw NAND world. Am I misunderstanding or is it platform dependency? > > I don't think it can be called a platform dependency, it's more like > legacy from the raw NAND world which makes the use of the generic ECC > framework hard and thus is limited to a given set of functions. > > > BTW, I think your modification should be more in line with the design > > spirit > > of generic ECC engine framework. > > Yes, ideally raw NAND should fully comply to this framework but this > would require a hundred days of work and dozens of available boards to > test. During the past 20 years people assumed NAND controller and ECC > engine were a single entity which makes the use of the generic ECC > framework hard to implemented in the raw NAND. So I decided not to put > all my energy there in order to first get this framework available to > SPI-NAND devices. Thanks for your detailed explanation. I agree with your change and it works fine in SPI-NAND world (with on-die or S/W ECC engines) and raw NAND world(with S/W ECC engines). Tested-by: YouChing Lin <ycllin@mxic.com.tw> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. ===================================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================
next prev parent reply other threads:[~2021-05-20 10:58 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-11 1:40 [PATCH 0/2] Fix double counting of S/W ECC engines' ECC stat YouChing Lin 2021-05-11 1:40 ` YouChing Lin 2021-05-11 1:40 ` [PATCH 1/2] mtd: nand: ecc-bch: Fix the double counting of " YouChing Lin 2021-05-11 1:40 ` YouChing Lin 2021-05-11 1:40 ` [PATCH 2/2] mtd: nand: ecc-hamming: " YouChing Lin 2021-05-11 1:40 ` YouChing Lin 2021-05-11 8:53 ` [PATCH 0/2] Fix double counting of S/W ECC engines' " Miquel Raynal 2021-05-11 8:53 ` Miquel Raynal 2021-05-13 2:11 ` ycllin 2021-05-13 2:11 ` ycllin 2021-05-13 6:45 ` Miquel Raynal 2021-05-13 6:45 ` Miquel Raynal 2021-05-20 10:56 ` ycllin [this message] 2021-05-20 10:56 ` ycllin
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=OF12EB0BE9.7879DE49-ON482586DB.0039FC49-482586DB.003C2449@mxic.com.tw \ --to=ycllin@mxic.com.tw \ --cc=juliensu@mxic.com.tw \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=miquel.raynal@bootlin.com \ --cc=richard@nod.at \ --cc=thomas.petazzoni@bootlin.com \ --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: linkBe 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.