On 19 September 2014 11:49, Simon Glass <s...@chromium.org> wrote: > Hi Robert, > > On 18 September 2014 23:25, Robert Baldyga <r.bald...@samsung.com> wrote: >> >> On 09/18/2014 08:00 PM, Simon Glass wrote: >> > Hi Robert, >> > >> > On 18 September 2014 09:13, Robert Baldyga <r.bald...@samsung.com >> > <mailto:r.bald...@samsung.com>> wrote: >> > >> > Since dev->req_seq value is initialized from "reg" property of fdt >> > node, >> > there is posibility, that address value contained in fdt is greater >> > than >> > INT_MAX, and then value in dev->req_seq is negative which led to >> > probe() >> > fail. >> > >> > This patch fix this problem by ensuring that req_seq is positive, >> > unless >> > it's one of errno codes. >> > >> > >> > Wouldn't this be a bug in the device tree file? What does it mean to >> > have a -ve value? >> > >> >> Device tree seems to be ok. We have: >> >> pinctrl0: pinctrl@e0200000 { >> compatible = "samsung,s5pc110-pinctrl"; >> reg = <0xe0200000 0x1000>; >> }; >> >> So when we take address from "reg" as dev->req_seq, then value >> 0xe0200000 after casting to int gives -534773760. Function >> uclass_resolve_seq() returns it as proper seq number, because it's >> unique. But then in file drivers/core/device.c, in function >> device_probe() we have: >> >> seq = uclass_resolve_seq(dev); >> if (seq < 0) { >> ret = seq; >> goto fail; >> } >> >> And it will obviously fail. >> >> Using "reg" value as req_seq doesn't work when this value is greater >> than INT_MAX. > > OK I see. Thanks for the clear explanation. We don't really want > req_seq for things that are not buses, but there is no real concept of > that in DM at this stage. Let's see how things pan out. For now, this > patch is a good solution. > > Acked-by: Simon Glass <s...@chromium.org>
Applied to u-boot-dm and now in mainline. Thanks! _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
