From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
Cc: Liang Yang <liang.yang@amlogic.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
<oxffffaa@gmail.com>, <kernel@sberdevices.ru>,
<linux-mtd@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-amlogic@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v5 4/6] mtd: rawnand: meson: use macro for OOB area
Date: Thu, 1 Jun 2023 10:34:05 +0200 [thread overview]
Message-ID: <20230601103405.51cb459a@xps-13> (raw)
In-Reply-To: <20230601061850.3907800-5-AVKrasnov@sberdevices.ru>
Hi Arseniy,
AVKrasnov@sberdevices.ru wrote on Thu, 1 Jun 2023 09:18:47 +0300:
> This replaces constants and same patterns for OOB handling with special
> macroses.
>
> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> ---
> drivers/mtd/nand/raw/meson_nand.c | 33 ++++++++++++++++++-------------
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
> index e42c28be02f3..23a73268421b 100644
> --- a/drivers/mtd/nand/raw/meson_nand.c
> +++ b/drivers/mtd/nand/raw/meson_nand.c
> @@ -108,6 +108,9 @@
>
> #define PER_INFO_BYTE 8
>
> +#define NFC_USER_BYTES 2
> +#define NFC_OOB_PER_ECC(nand) ((nand)->ecc.bytes + NFC_USER_BYTES)
OOB per ECC for me does not make sense.
OOB is the whole area after the data.
What about NFC_OOB_SZ_PER_ECC_STEP ?
> +
> struct meson_nfc_nand_chip {
> struct list_head node;
> struct nand_chip nand;
> @@ -339,7 +342,7 @@ static u8 *meson_nfc_oob_ptr(struct nand_chip *nand, int i)
> struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
> int len;
>
> - len = nand->ecc.size * (i + 1) + (nand->ecc.bytes + 2) * i;
> + len = nand->ecc.size * (i + 1) + NFC_OOB_PER_ECC(nand) * i;
>
> return meson_chip->data_buf + len;
> }
> @@ -350,7 +353,7 @@ static u8 *meson_nfc_data_ptr(struct nand_chip *nand, int i)
> int len, temp;
>
> temp = nand->ecc.size + nand->ecc.bytes;
> - len = (temp + 2) * i;
> + len = (temp + NFC_USER_BYTES) * i;
>
> return meson_chip->data_buf + len;
> }
> @@ -364,7 +367,7 @@ static void meson_nfc_get_data_oob(struct nand_chip *nand,
> u8 *dsrc, *osrc;
> u8 *oobtail;
>
> - oob_len = nand->ecc.bytes + 2;
> + oob_len = NFC_OOB_PER_ECC(nand);
> for (i = 0; i < nand->ecc.steps; i++) {
> if (buf) {
> dsrc = meson_nfc_data_ptr(nand, i);
> @@ -393,7 +396,7 @@ static void meson_nfc_set_data_oob(struct nand_chip *nand,
> u8 *dsrc, *osrc;
> u8 *oobtail;
>
> - oob_len = nand->ecc.bytes + 2;
> + oob_len = NFC_OOB_PER_ECC(nand);
> for (i = 0; i < nand->ecc.steps; i++) {
> if (buf) {
> dsrc = meson_nfc_data_ptr(nand, i);
> @@ -452,7 +455,7 @@ static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf)
> __le64 *info;
> int i, count;
>
> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (nand->ecc.bytes + 2)) {
> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += NFC_OOB_PER_ECC(nand)) {
> info = &meson_chip->info_buf[i];
> *info |= oob_buf[count];
> *info |= oob_buf[count + 1] << 8;
> @@ -465,7 +468,7 @@ static void meson_nfc_get_user_byte(struct nand_chip *nand, u8 *oob_buf)
> __le64 *info;
> int i, count;
>
> - for (i = 0, count = 0; i < nand->ecc.steps; i++, count += (nand->ecc.bytes + 2)) {
> + for (i = 0, count = 0; i < nand->ecc.steps; i++, count += NFC_OOB_PER_ECC(nand)) {
> info = &meson_chip->info_buf[i];
> oob_buf[count] = *info;
> oob_buf[count + 1] = *info >> 8;
> @@ -661,7 +664,7 @@ static u32 meson_nfc_oob_free_bytes(struct nand_chip *nand)
> {
> struct mtd_info *mtd = nand_to_mtd(nand);
>
> - return mtd->oobsize - nand->ecc.steps * (nand->ecc.bytes + 2);
> + return mtd->oobsize - nand->ecc.steps * NFC_OOB_PER_ECC(nand);
> }
>
> static int meson_nfc_write_oob(struct nand_chip *nand, int page)
> @@ -712,11 +715,11 @@ static int meson_nfc_read_oob(struct nand_chip *nand, int page)
> /* Read ECC codes and user bytes. */
> for (i = 0; i < nand->ecc.steps; i++) {
> u32 ecc_offs = nand->ecc.size * (i + 1) +
> - (nand->ecc.bytes + 2) * i;
> + NFC_OOB_PER_ECC(nand) * i;
>
> ret = nand_change_read_column_op(nand, ecc_offs,
> - oob_buf + i * (nand->ecc.bytes + 2),
> - (nand->ecc.bytes + 2), false);
> + oob_buf + i * NFC_OOB_PER_ECC(nand),
> + NFC_OOB_PER_ECC(nand), false);
> if (ret)
> return ret;
> }
> @@ -918,12 +921,14 @@ static int meson_nfc_read_page_hwecc(struct nand_chip *nand, u8 *buf,
>
> for (i = 0; i < nand->ecc.steps ; i++) {
> u8 *data = buf + i * ecc->size;
> - u8 *oob = nand->oob_poi + i * (ecc->bytes + 2);
> + u8 *oob = nand->oob_poi + i * NFC_OOB_PER_ECC(nand);
>
> if (correct_bitmap & BIT_ULL(i))
> continue;
> +
> ret = nand_check_erased_ecc_chunk(data, ecc->size,
> - oob, ecc->bytes + 2,
> + oob,
> + NFC_OOB_PER_ECC(nand),
> NULL, 0,
> ecc->strength);
> if (ret < 0) {
> @@ -1073,7 +1078,7 @@ static int meson_ooblayout_ecc(struct mtd_info *mtd, int section,
> if (section >= nand->ecc.steps)
> return -ERANGE;
>
> - oobregion->offset = 2 + (section * (2 + nand->ecc.bytes));
> + oobregion->offset = NFC_USER_BYTES + (section * NFC_OOB_PER_ECC(nand));
No, the first "2" here is for bad block markers, it is not related to
your ECC engine layout I believe.
> oobregion->length = nand->ecc.bytes;
>
> return 0;
> @@ -1091,7 +1096,7 @@ static int meson_ooblayout_free(struct mtd_info *mtd, int section,
> /* Split rest of OOB area (not covered by ECC engine) per each
> * ECC section. This will be OOB data available to user.
> */
> - oobregion->offset = (section + nand->ecc.steps) * (2 + nand->ecc.bytes);
> + oobregion->offset = (section + nand->ecc.steps) * NFC_OOB_PER_ECC(nand);
> oobregion->length = oob_bytes / nand->ecc.steps;
>
> return 0;
Thanks,
Miquèl
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2023-06-01 8:34 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 6:18 [RFC PATCH v5 0/6] refactoring, fixes and updates for Meson NAND Arseniy Krasnov
2023-06-01 6:18 ` [RFC PATCH v5 1/6] mtd: rawnand: meson: fix ready/busy command Arseniy Krasnov
2023-06-01 7:51 ` Miquel Raynal
2023-06-01 22:44 ` Arseniy Krasnov
2023-06-05 7:08 ` Miquel Raynal
2023-06-01 6:18 ` [RFC PATCH v5 2/6] mtd: rawnand: meson: wait for command in polling mode Arseniy Krasnov
2023-06-01 7:57 ` Arseniy Krasnov
2023-06-01 8:07 ` Miquel Raynal
2023-06-01 23:09 ` Arseniy Krasnov
2023-06-05 9:05 ` Miquel Raynal
2023-06-05 13:19 ` Liang Yang
2023-06-05 13:30 ` Liang Yang
2023-06-05 16:58 ` Arseniy Krasnov
2023-06-06 7:03 ` Miquel Raynal
2023-06-06 7:40 ` Arseniy Krasnov
2023-06-06 7:55 ` Miquel Raynal
2023-06-06 11:49 ` Arseniy Krasnov
2023-06-06 12:11 ` Miquel Raynal
2023-06-06 12:10 ` Arseniy Krasnov
2023-06-01 6:18 ` [RFC PATCH v5 3/6] mtd: rawnand: meson: only expose unprotected user OOB bytes Arseniy Krasnov
2023-06-01 8:31 ` Miquel Raynal
2023-06-02 8:53 ` Arseniy Krasnov
2023-06-05 9:48 ` Miquel Raynal
2023-06-06 4:42 ` Arseniy Krasnov
2023-06-06 7:11 ` Miquel Raynal
2023-06-06 7:41 ` Arseniy Krasnov
2023-06-01 6:18 ` [RFC PATCH v5 4/6] mtd: rawnand: meson: use macro for OOB area Arseniy Krasnov
2023-06-01 8:34 ` Miquel Raynal [this message]
2023-06-01 6:18 ` [RFC PATCH v5 5/6] mtd: rawnand: meson: check buffer length Arseniy Krasnov
2023-06-01 6:18 ` [RFC PATCH v5 6/6] mtd: rawnand: meson: remove unneeded bitwise OR with zeroes Arseniy Krasnov
2023-06-01 7:50 ` [RFC PATCH v5 0/6] refactoring, fixes and updates for Meson NAND Miquel Raynal
2023-06-01 7:51 ` Arseniy Krasnov
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=20230601103405.51cb459a@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=AVKrasnov@sberdevices.ru \
--cc=jbrunet@baylibre.com \
--cc=kernel@sberdevices.ru \
--cc=khilman@baylibre.com \
--cc=liang.yang@amlogic.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=neil.armstrong@linaro.org \
--cc=oxffffaa@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).