Hi,
On Fri, 2019-04-26 at 19:20 +0530, Jagan Teki wrote:
On Fri, Apr 26, 2019 at 7:12 PM Paul Kocialkowski paul.kocialkowski@bootlin.com wrote:
Hi,
On Fri, 2019-04-26 at 19:07 +0530, Jagan Teki wrote:
On Fri, Apr 26, 2019 at 7:04 PM Paul Kocialkowski paul.kocialkowski@bootlin.com wrote:
Hi,
On Fri, 2019-04-26 at 18:48 +0530, Jagan Teki wrote:
u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and which is U-Boot specific devicetrees binding.
Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot bindings will move it future based on the requirement.
This would help to sync the devicetrees from Linux whenever required instead of adding specific nodes.
Signed-off-by: Jagan Teki jagan@amarulasolutions.com Reviewed-by: Paul Kocialkowski paul.kocialkowski@bootlin.com
Since your patch has changed significantly, you can no longer include a Reviewed-by that was given on a previous iteration.
It looks like we are still missing bits to have rk3399-u-boot.dtsi included, so this patch does not get my Reviewed-by tag.
It will include rockchip-u-boot.dtsi automatically and I made the receptive changes to include other files in this patch [1] and sure I will ask Philipp to remove the reviewed-by tag, thanks.
Most importantly (now that I see the new series), you should certainly have sent that patch as part of your new series because we now have an inter-dependency between both series.
It is not like an inter-dependency the previous rk3399-u-boot.dtsi is not included by these files so they would work as before. and now this series would need this change to include rk3399-u-boot.dtsi since the goal here to add binman node to common for all rk3399 dts files.
Well, what I mean is that the latest series you sent mentions a dependency on the first one, when it really should be the other way round: you need the rework to make things in your first series work at all, since that dm-pre-reloc is necessary.
We don't want to merge one broken series and then the fix for it later, even if it would still build in all cases. Here there is a clear logical dependency, in the reverse ordre to the one you are describing.
In order to get this right, you need to take that v3.1 patch from the first series and stick first in the new one. When that's done, I'll be happy to move on to reviewing the code!
Cheers,
Paul