Re: [RFC V2 PATCH 10/12] arm64: dts: msm8994 issolate non standard bootloader/LK entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


Regards,

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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux