On Wednesday, October 12, 2016 5:59:41 PM CEST Jeremy McNicoll wrote: > On 2016-10-12 3:39 AM, Arnd Bergmann wrote: > > On Tuesday, October 11, 2016 7:41:22 PM CEST Rob Herring wrote: > >> On Sat, Oct 1, 2016 at 9:38 PM, Jeremy McNicoll <jmcnicol@xxxxxxxxxx> wrote: > >>> These non standard DT entries need to be cast aside as to not > >>> pollute the main device tree bindings. Without these essential > >>> DT items the bootloader/LK will not pass control over to the kernel > >>> and thus never boot. > >> > >> I discussed this with Stephen recently. I'm okay with leaving these on > >> boards that have no chance of getting updated bootloaders to use the > >> compatible string instead. Having to use dtbTool is far worse than a > >> couple of extra properties IMO. I reserve the right to complain if new > >> stuff continues to use these though. > >> > >>> Signed-off-by: Jeremy McNicoll <jeremymc@xxxxxxxxxx> > >>> --- > >>> .../arm64/boot/dts/qcom/msm8994-angler-rev-101.dts | 1 - > >>> arch/arm64/boot/dts/qcom/msm8994.dtsi | 3 +-- > >>> .../boot/dts/qcom/nexus6p_bootloader_bits.dtsi | 24 ++++++++++++++++++++++ > >> > >> Just put this into the board file rather than yet another include. > > > > The suggestion that I had was to have two .dts files: the normal > > one without these properties, and another .dts file including the > > first but adding these three for compatibility with the legacy > > bootloaders. > > > (sorry for the late reply, I thought I had replied already but couldn't find that in the archives when I saw I still had this reply open) > So I did it backwards from what you had suggested? > Based on my discussion with, (cant seem to recall) my understanding > was that we simply wanted to have these 3 bootloader specific entries > in another file. Right What I would like to see here is two separate .dtb files, one with the hack and one without it, so we have a migration path for the machines that eventually get a boot loader with proper DT support. > > That way we could have a 'clean' .dtb file once the bootloaders > > get fixed, and can name the other one appropriately to discourage > > copying the method for new machines. > > > > Did you miss the part about Ebola or Bubonic plague ? I did, which means others are likely to miss it as well ;-) Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
