On Fri, Aug 18, 2017 at 2:23 PM, Icenowy Zheng <icenowy@xxxxxxx> wrote: > > > 于 2017年8月18日 GMT+08:00 下午2:21:07, Chen-Yu Tsai <wens@xxxxxxxx> 写到: >>Hi, >> >>On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
