Hi Sricharan, quic_srichara@xxxxxxxxxxx wrote on Fri, 18 Aug 2023 19:21:04 +0530: > 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. If the READ path works on IPQ platforms it's already a huge step forward, please send the fix on top of Mannivan series. Now, what is the issue with SDX? Thanks, Miquèl
