From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
<oe-kbuild@lists.linux.dev>,
"Md Sadre Alam" <quic_mdalam@quicinc.com>, <lkp@intel.com>,
<oe-kbuild-all@lists.linux.dev>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [linux-next:master 1937/6910] drivers/mtd/nand/raw/qcom_nandc.c:2941 qcom_op_cmd_mapping() error: uninitialized symbol 'ret'.
Date: Mon, 7 Aug 2023 21:14:58 +0200 [thread overview]
Message-ID: <20230807211458.3de7c627@xps-13> (raw)
In-Reply-To: <908ee5e8-6213-5685-7094-8c4b1282015c@quicinc.com>
Hi Sricharan,
quic_srichara@quicinc.com wrote on Tue, 8 Aug 2023 00:24:08 +0530:
> Hi Mani/Miquel,
>
> On 8/6/2023 1:28 PM, Sricharan Ramabadhran wrote:
> > Hi Miquel/Mani/Dan,
> >
> > <..>
> >
> >>>>> The || should be &&, otherwise it cannot work, or am I missing
> >>>>> something?
> >>>>
> >>>> Yeah. That's how this bug normally looks like. NAND_OP_CMD_INSTR
> >>>> always returns -ENOTSUPP.
> >>>>
> >>
> >> Yes, this is a bug.
> >>
> >> I didn't get a chance to review the exec_op conversion series (blame >> myself).
> >> Now I see scope for a cleaup series :/
> >>
> >> Let me spin something by the end of today.
> >>
> > Thanks a lot Mani for the quick fixes. Will test it.
> > Sorry it was a holiday for us past few days, so just checked this.
> >
> > Regards,
> > Sricharan
>
> With this series applied on linux-next, started seeing the below
> messages flooded on console while doing mtd r/w.
> "xxx "Opcode not supported: 0"
>
> opcode '0' corresponds to NAND_CMD_READ0. This command inturn was
> invoked from qcom_nandc.c driver from below places. For read/write_page
> driver does not use the exec ops. Hence these calls just ends up
> being -ENOTSUPP and ignored. So removed their invocations.
> If this is fine, can this be added to your series ? (will send
> git-format patch to add to your cleanup series). So far, tested
> mtd raw/block read/writes and all works fine. Will do further tests
> as well.
Unless I really don't understand the controller, this is non sense.
nand_read_page_op() is precisely what allows your NAND to perform a
read. Removing this call cannot work.
What you need is a proper ->exec_op() implementation, and repeating
this becomes slightly annoying.
Look at your qcom_op_cmd_mapping, you don't even have a path for reads.
I bet something along:
CMD_READ0:
ret = XXX_OPCODE_READ;
break;
will make it work.
Please fix the driver and test with nandbiterrs -i. If this test works,
it is encouraging. Otherwise it is still broken.
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -1470,7 +1470,6 @@ qcom_nandc_read_cw_raw(struct mtd_info *mtd, struct nand_chip *chip,
> int ret, reg_off = FLASH_BUF_ACC, read_loc = 0;
> int raw_cw = cw;
>
> - nand_read_page_op(chip, page, 0, NULL, 0);
> host->use_ecc = false;
>
> if (nandc->props->qpic_v2)
> @@ -1890,7 +1889,6 @@ static int qcom_nandc_read_page(struct nand_chip *chip, u8 *buf,
> if (host->nr_boot_partitions)
> qcom_nandc_codeword_fixup(host, page);
>
> - nand_read_page_op(chip, page, 0, NULL, 0);
> nandc->buf_count = 0;
> nandc->buf_start = 0;
> host->use_ecc = true;
> @@ -1965,8 +1963,6 @@ static int qcom_nandc_write_page(struct nand_chip *chip, const u8 *buf,
> if (host->nr_boot_partitions)
> qcom_nandc_codeword_fixup(host, page);
>
> - nand_prog_page_begin_op(chip, page, 0, NULL, 0);
> -
> set_address(host, 0, page);
> nandc->buf_count = 0;
> nandc->buf_start = 0;
> @@ -2039,7 +2035,6 @@ static int qcom_nandc_write_page_raw(struct nand_chip *chip,
> if (host->nr_boot_partitions)
> qcom_nandc_codeword_fixup(host, page);
>
> - nand_prog_page_begin_op(chip, page, 0, NULL, 0);
> clear_read_regs(nandc);
> clear_bam_transaction(nandc);
>
>
> Regards,
> Sricharan
Miquèl
next prev parent reply other threads:[~2023-08-07 19:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 12:20 Dan Carpenter
2023-08-04 16:45 ` Miquel Raynal
2023-08-04 16:52 ` Dan Carpenter
2023-08-04 17:07 ` Miquel Raynal
2023-08-05 6:55 ` Manivannan Sadhasivam
2023-08-06 7:58 ` Sricharan Ramabadhran
2023-08-07 18:54 ` Sricharan Ramabadhran
2023-08-07 19:14 ` Miquel Raynal [this message]
2023-08-08 5:16 ` Sricharan Ramabadhran
2023-08-18 13:33 ` Miquel Raynal
2023-08-18 13:51 ` Sricharan Ramabadhran
2023-08-18 14:03 ` Miquel Raynal
2023-08-18 14:17 ` Sricharan Ramabadhran
2023-08-18 15:24 ` Sricharan Ramabadhran
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=20230807211458.3de7c627@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=dan.carpenter@linaro.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=mani@kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oe-kbuild@lists.linux.dev \
--cc=quic_mdalam@quicinc.com \
--cc=quic_srichara@quicinc.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