[U-Boot] [PATCH 1/3] sunxi: Sync Bananapi M2+ device tree from Linux v5.0-rc1

[Chen-Yu Tsai]

On Tue, Feb 12, 2019 at 9:02 PM Jagan Teki <jagan at amarulasolutions.com> wrote:
>
> Hi Chen-Yu,
>
> On Tue, Feb 12, 2019 at 5:59 PM Chen-Yu Tsai <wens at csie.org> wrote:
> >
> > On Tue, Feb 12, 2019 at 8:22 PM Jagan Teki <jagan at amarulasolutions.com> wrote:
> > >
> > > On Tue, Feb 12, 2019 at 5:46 PM Andre Przywara <andre.przywara at arm.com> wrote:
> > > >
> > > > On Tue, 12 Feb 2019 17:39:35 +0530
> > > > Jagan Teki <jagan at amarulasolutions.com> wrote:
> > > >
> > > > > On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara <andre.przywara at arm.com> wrote:
> > > > > >
> > > > > > On Tue, 12 Feb 2019 17:30:44 +0530
> > > > > > Jagan Teki <jagan at amarulasolutions.com> wrote:
> > > > > >
> > > > > > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai <wens at csie.org> wrote:
> > > > > > > >
> > > > > > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki <jagan at amarulasolutions.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai <wens at csie.org> wrote:
> > > > > > > > > >
> > > > > > > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > > > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> > > > > > > > > > device tree for the Bananapi M2+ has been split into a common dtsi file,
> > > > > > > > > > and an SoC-specific board device tree file that includes both the shared
> > > > > > > > > > dtsi file and the soc dtsi file. This was done to support both the H3
> > > > > > > > > > and H5 variants of the same board. This is similar to what was doen for
> > > > > > > > >
> > > > > > > > > s/doen/done
> > > > > > > >
> > > > > > > > Good catch.
> > > > > > > >
> > > > > > > > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: Split
> > > > > > > > > > out common board design for ALL-H3-CC device tree").
> > > > > > > > > >
> > > > > > > > > > The newly split files are directly synced from Linux tag v5.0-rc1.
> > > > > > > > >
> > > > > > > > > Better sync all dts(i) files on this relevant SoC, this would help to
> > > > > > > > > track and use for rest of SoC's are inline to the same version later.
> > > > > > > >
> > > > > > > > Ok. Would syncing with linux-next (5.1) work for you? FYI all the PRs
> > > > > > > > for the next release have been sent out.
> > > > > > >
> > > > > > > Yes, better we can pick relevant version on during next MW.
> > > > > >
> > > > > > I think what Chen-Yu wanted to hint at is that you can this already, by picking the patches from the currently existing branches of the linux-sunxi repository:
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
> > > > > >
> > > > > > There should be no need to wait for the Linux MW to close.
> > > > >
> > > > > Not for Linux, I'm referring here about u-boot MW.
> > > >
> > > > Why do we have to wait for so long? The next U-Boot MW is about two months away from now. And with U-Boot's usage of the DT we can surely minimise the risk of breaking something, by just reviewing that the DT changes do not touch or interfere with any devices that U-Boot cares about.
> > > > This way we can get up-to-date DTs now (which UEFI boot benefits from), so that users don't have to provide "their own" DTs.
> > >
> > > I knew this degree of risk with dts changes and I have no specific
> > > reason for this except to follow U-Boot release cycle[1] not to take
> > > new features in 'release candidate phase' which was missed.
> > >
> > > [1] https://www.denx.de/wiki/U-Boot/ReleaseCycle
> >
> > Or you can merge these patches as is for now, and sync up all the
> > device tree files
>
> Can't you wait till all get in? any urgency? idea is to grab all sync
> changes in one commit.

It's not urgent at all. It's more likely that I completely forget about
this in two months.

And it will still be two commits either way you cut it: 1 for the sync,
the other for the defconfig and MAINTAINERS entry.

> > once the next merge window opens. These patches were sent a full two
> > weeks before
> > the merge window closed. AFAIK they are eligible [1] for the pending release.
>
> To be clear I knew this and same mentioned above, I missed it during last MW.

OK.

ChenYu