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

[Hui-Ping Chen <hpchen0nvt@gmail.com>]

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



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/