Hi Miquel,
On 8/18/2023 7:03 PM, Miquel Raynal wrote:
Hi Sricharan,
quic_srichara@xxxxxxxxxxx wrote on Tue, 8 Aug 2023 10:46:14 +0530:
<..>
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.
ok understand. Will fix this up.
This is urgent now. The driver in -next is broken, shall I revert
everything or will you test the above fix quickly?
While we are able to reproduce the issue, add path for
CMD_READ0/READ_START for IPQ platforms. All mtd tests including
nandbiterrs works fine. But we are not able to get hold of a SDX
device where we could reproduce the issue to debug. We are working
offline with Manivannan for the SDX remote debug. Will keep you
updated here and if we are not able to solve this on SDX in next
couple of days, only way looks like revert and re-apply it for 6.7.
Regards,
Sricharan
