On Wed, Oct 19, 2016 at 08:07:25PM -0500, Rob Herring wrote: > On Wed, Oct 19, 2016 at 4:46 PM, Andy Gross <andy.gross@xxxxxxxxxx> wrote: > > On Wed, Oct 19, 2016 at 04:56:20PM +0200, Arnd Bergmann wrote: > >> 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. > > > > So my main beef with this is that it is kind of onerous. The machines that > > require this will never get a bootloader change. So we'll be adding 2 dtb > > targets and only ever use one. > > > > It's much simpler in my opinion to just add the msm-id to the files that need it > > right now..... comment it with something like 'this is because of the Qualcomm > > braindead bootloader requirements' and move on. > > > > If there was any hope of a new bootloader for non-bleeding edge boards, I'd > > wholeheartedly agree with you Arnd. But there isn't, and there won't be. > > Makes sense to me for things like Nexus phones here. What about DB410 > for example? Is there hope for a fix there? My bootloader is only a > couple of months old and needs the properties still. There won't be a fix for the 410c. We barely got them to respin to use PSCI. Stephen can correct me if I am wrong on this. If this is fixed, it would be 8996+. If.......... So this means introducing the msm-id's for the boards that currently require it, and for the boards that will require it in the future. And this would stay in effect until the bootloader is able to parse the compatible strings or figure this out without the msm-ids. Andy -- 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
