| Message ID | 20170809085627.32687-3-icenowy@aosc.io (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy@aosc.io> 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. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") ? I can add the tag when applying. ChenYu
Hi, On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy@aosc.io> 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. Thanks ChenYu
于 2017年8月18日 GMT+08:00 下午2:21:07, Chen-Yu Tsai <wens@csie.org> 写到: >Hi, > >On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy@aosc.io> 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. > >Thanks >ChenYu
On Fri, Aug 18, 2017 at 2:23 PM, Icenowy Zheng <icenowy@aosc.io> wrote: > > > 于 2017年8月18日 GMT+08:00 下午2:21:07, Chen-Yu Tsai <wens@csie.org> 写到: >>Hi, >> >>On Wed, Aug 9, 2017 at 4:56 PM, Icenowy Zheng <icenowy@aosc.io> 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
diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c index 99e354c8f53f..c1ff7fa62cb4 100644 --- a/drivers/soc/sunxi/sunxi_sram.c +++ b/drivers/soc/sunxi/sunxi_sram.c @@ -190,6 +190,9 @@ int sunxi_sram_claim(struct device *dev) u32 val, mask; if (IS_ERR(base)) + return PTR_ERR(base); + + if (!base) return -EPROBE_DEFER; if (!dev || !dev->of_node)
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. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> --- drivers/soc/sunxi/sunxi_sram.c | 3 +++ 1 file changed, 3 insertions(+)