[PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

Simon Glass sjg at chromium.org
Mon Oct 11 22:00:56 CEST 2021


Hi Rob,

On Mon, 11 Oct 2021 at 13:49, Rob Herring <robh at kernel.org> wrote:
>
> On Mon, Oct 11, 2021 at 2:00 PM Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> >
> > > From: Rob Herring <robh at kernel.org>
> > > Date: Mon, 11 Oct 2021 13:36:29 -0500
> >
> > Hi Rob,
> >
> > > On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis <kettenis at openbsd.org> wrote:
> > > >
> > > > Add preliminary device trees for the Apple M1 mini (2020) and
> > > > Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> > > > the Apple M1 SoC are still being formalized and these device
> > > > trees will be synchronized with the Linux kernel as needed.
> > >
> > > So not synchronized currently? If it is sync'ed, you should specify
> > > which version you got.
> >
> > Not synched at the moment.  It is based on what was in 5.13 or 5.14,
> > but with lots of stuff added so specifying a version would be
> > misleading.  It should be mostly aligned with the bindings that are
> > making their way into 5.15 or 5.16 though.
>
> This and what's added or preliminary would be good to have in the commit msg.
>
> > Hopefully now that the power domains are getting addressed we'll have
> > something that can be synchronized soon.  I was explicitly encouraged
> > to start upstreaming the U-Boot code even though not all the DT
> > bindings had been sorted out.
>
> In general, sounds like a recipe for getting out of sync and bindings
> never getting documented properly without any checks in place. The
> good news is checking that is at least possible now.
>
> > > > These device trees are provided as a reference only as U-Boot
> > > > uses the device tree passed by the m1n1 bootloader.
> > >
> > > If reference only, why do they need to be checked in here? We're
> > > trying to get to fewer copies both of dtbs at runtime and dts files in
> > > source trees.
> >
> > The U-Boot maintainers insist there is a DT for each supported system
> > in the U-Boot tree.
>
> Ok, fair enough.
>
> > > I mainly bring it up here because this is a platform with multiple OS
> > > targets, following the model that DT comes from the firmware, and
> > > should be free of schema validation warnings. In other words, it's a
> > > good candidate to define best practices.
> >
> > You're preaching to the choir ;).
>
> Good.
>
> > Must admit that it is somewhat convenient for me to have a somewhat
> > complete DT for these devices at the moment.  But in the long run I
> > think it will just confuse people.  That said, I plan to be aggressive
> > in keeping the U-Boot tree synchronized with Linux.
>
> What I'd like to see here is some sort of automatic synchronization.
> The idea I have here is just a list of boards to sync from the kernel
> tree to wherever. The requirement to get on the list would be passing
> schema validation and would be a declaration of stability (there's
> been numerous discussions over the years of how to declare a DT stable
> or unstable). It would perhaps also include passing validation on an
> older schema. I'm not sure how well that would catch compatibility
> issues, but that's the only idea I've come up with besides just
> testing of mixed versions. I'm happy to do the tooling to support that
> if we have a board/device to put in the list and u-boot folks agree to
> use it. I suppose even if just m1n1 used it to start with, I'd be
> willing to do the tooling.

That sounds great to me. Yes m1n1 is a good first target since it is
new, but I'm pretty sure there are quite a few other SoCs that could
move over right away.

Ideally we would add it to U-Boot CI too, so that pull requests warn
or fail if something wrong is added. Of course it is probably a no-no
to make U-Boot CI due to comparisons with another tree over which we
have no control, but perhaps we can head in that direction.

+Tom Rini too as he has been looking at this.

Regards,
Simon


More information about the U-Boot mailing list