On Tue, Feb 12, 2019 at 9:02 PM Jagan Teki <ja...@amarulasolutions.com> wrote:
>
> Hi Chen-Yu,
>
> On Tue, Feb 12, 2019 at 5:59 PM Chen-Yu Tsai <w...@csie.org> wrote:
> >
> > On Tue, Feb 12, 2019 at 8:22 PM Jagan Teki <ja...@amarulasolutions.com>
> > wrote:
> > >
> > > On Tue, Feb 12, 2019 at 5:46 PM Andre Przywara <andre.przyw...@arm.com>
> > > wrote:
> > > >
> > > > On Tue, 12 Feb 2019 17:39:35 +0530
> > > > Jagan Teki <ja...@amarulasolutions.com> wrote:
> > > >
> > > > > On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara
> > > > > <andre.przyw...@arm.com> wrote:
> > > > > >
> > > > > > On Tue, 12 Feb 2019 17:30:44 +0530
> > > > > > Jagan Teki <ja...@amarulasolutions.com> wrote:
> > > > > >
> > > > > > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai <w...@csie.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki
> > > > > > > > <ja...@amarulasolutions.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai <w...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
