On Fri, Aug 18, 2017 at 2:23 PM, Icenowy Zheng <[email protected]> wrote: > > > 于 2017年8月18日 GMT+08:00 下午2:21:07, Chen-Yu Tsai <[email protected]> 写到: >>Hi, >> >>On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <[email protected]> wrote: >>> When claiming SRAM, if the base is set to an error, it means that the >>> SRAM controller has been probed, but failed to remap the controller >>> memory zone. If the base is zero, thus the SRAM controller should be >>not >>> probed at all, and it should return -EPROBE_DEFER. However, currently >>we >>> returned -EPROBE_DEFER in the former situation, and ignored the >>latter >>> situation (which will lead to the kernel to panic). >>> >>> Fix the behavior on abnormal base address processing when claiming. >> >>Could you describe how you actually ran into this? The failure seems >>unlikely for a properly written device tree. > > In fact it's possible, as the probe defering used to be broken. > > On the A64 situation, the SRAM is referenced by the DE2 CCU driver, which > will be probed very early -- before SRAM is probed, and the problem happens.
OK. I see it's because the DE block's address if before almost everything else. I was wondering why we never ran into this before. Given there are no actual users in the kernel that could trigger this, I'll queue this for 4.14 instead. ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
