Re: [linux-next:master 1937/6910] drivers/mtd/nand/raw/qcom_nandc.c:2941 qcom_op_cmd_mapping() error: uninitialized symbol 'ret'.

[Sricharan Ramabadhran <quic_srichara@quicinc.com>]

On 8/18/2023 7:33 PM, Miquel Raynal wrote:
> Hi Sricharan,
> 
> quic_srichara@quicinc.com 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@quicinc.com 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.
> 
   ok, will send. Please confirm if its all fine.
   There are more abstraction/common mode in the driver to be pulled
   out, but that will do later.

> Now, what is the issue with SDX?

    Looks like SDX device that Mani is having is a 4K nand device.
    For some reason, after exec ops nand boot is broken on that board.
    We applied the fixes we did on top of Manivannan series.
    With that enumeration works, but still mount fails. But 4K nand
    device boot on IPQ works fine. Problem is we do not have a SDX board
    where we could debug that. We are trying to get a remote setup
    enabled for this.

Regards,
  Sricharan