RE: Re: [PATCH] mtd: fix oops when writing to phram device on arm64

[Huaijie Yi <yihuaijie@xxxxxxxxxx>]

>On 9/21/2019 11:03 PM, Huaijie Yi wrote:
>>> On Mon, Aug 19, 2019 at 3:39 PM Huaijie Yi <yihuaijie@xxxxxxxxxx> wrote:
>>>>
>>>> From: yihuaijie <yihuaijie@xxxxxxxxxx>
>>>>
>>>> memcpy() to memory remaped by ioremap() at an address not aligned to 
>>>> 8-bytes will cause oops on arm64 platform, fixing this by using 
>>>> ioremap_wc().
>>>
>>> This might be the right thing on arm64, but I fear not for all other archs and configurations.
>>>
>>> We had a similar chain of problems already with our sram driver.
>>> See:
>>> eb43e023130b ("misc: sram: add optional ioremap without write 
>>> combining")
>>> 0ab163ad1ea0 ("misc: sram: switch to ioremap_wc from ioremap")
>>>
>>> --
>>> Thanks,
>>> //richard
>> 
>> Hi, richard
>> 
>> I verified this on x86_64, and there isn't the problem.
>> 
>> I will resend a V2 to fix this only on ARM64.
>
>The SRAM driver also takes care of using memcpy_{to,from}io() which the PHRAM does not make use, that sounds like a possible issue too. There is the alignment that is important, but also how you access the underlying memory (e.g.: beats that you generate on the bus connecting you to that memory area). ARM64 may be forgiving and allow memcpy() to work against a WC mapping, other architectures, maybe not so much.
>
>It sounds like adopting the solution that the SRAM driver did, whereby adding an optional boolean Device Tree property to indicate whether
>ioremap_wc() or ioremap() is to be used seems like the most flexible solution.
>--
>Florian

PHRAM does't use Device Tree property, so I'm going to use a boolean module param to achieve it.

--
Thanks,
//Huaijie Yi


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