Re: [PATCH v6 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC

Hui-Ping Chen
2024-10-11T00:31:46Z

Dear Miquel,

Thank you for your reply.

On 2024/10/9 下午 04:04, Miquel Raynal wrote:
> Hi Hui-Ping,
>
>>>>>> + return 0;
>>>>>> + }
>>>>>> +
>>>>>> + ma35_nand_dmac_init(nand);
>>>>>> +
>>>>>> + writel(mtd->oobsize, nand->regs + MA35_NFI_REG_NANDRACTL);
>>>>>> +
>>>>>> + /* setup and start DMA using dma_addr */
>>>>>> + dma_addr = dma_map_single(nand->dev, (void *)addr, len, DMA_FROM_DEVICE);
>>>>>> + ret = dma_mapping_error(nand->dev, dma_addr);
>>>>>> + if (ret) {
>>>>>> + dev_err(nand->dev, "dma mapping error\n");
>>>>>> + return -EINVAL;
>>>>>> + }
>>>>>> +
>>>>>> + writel((unsigned long)dma_addr, nand->regs + MA35_NFI_REG_DMASA);
>>>>> Please enforce a dma mask of 32 (even though it might be the fault).
>>>> I will change it to dma_addr & 0xffffffff.
>>> That's not what I mean, I believe you should use the dma API to ask for
>>> a mapping within the accessible 32-bit address range. The
>>> dma_mapping_error() check should return an error if that's not the
>>> case. Then you can safely write the value.
>> Here is my misunderstanding: just fill in the dma_addr directly,
>>
>> no type conversion is needed. I have already tested it.
> FYI, it only works because the default DMA mask for your device is gonna
> be 32 bits. If the reality (what your peripheral DMA can do) was
> different than this, you would have to set a different mask explicitly
> to make sure the dma-mapping step would not provide buffers which are
> out of reach.

Sure, I will keep that in mind. However, due to the memory architecture
of the MA35,

which is designed for a maximum of 4GB, there won’t be any situation
exceeding 32 bits.

Thank you.

> Thanks,
> Miquèl

Best regards,

Hui-Ping Chen