On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote:
> On Wed, 27 Apr 2022 15:31:19 -0500
> Samuel Holland <samuel@sholland.org> wrote:
> 
> Hi Samuel, Tom,
> 
> > This series brings all of our devicetrees up to date with Linux.
> > 
> > Older SoCs (before A83T) have not been synchronized in over 3 years.
> > And I don't have any of this hardware to test. But there are not major
> > changes to those devicetrees either.
> > 
> > The big motivation for including older SoCs in this update is converting
> > the USB PHY driver to get its VBUS detection GPIO/regulator from the
> > devicetree instead of from a pin name in Kconfig. Many older boards had
> > those properties added or fixed since the last devicetree sync. This PHY
> > driver change is necessary to complete the DM_GPIO migration.
> > 
> > A couple of breaking changes were made to several SoCs' devicetrees in
> > Linux relating to the "r_intc" interrupt controller. New kernels support
> > old devicetrees, but not the other way around. So to be most compatible
> > and avoid regressions, those changes are skipped here.
> 
> Many thanks for considering this! I just skimmed over the A64 and H6
> patches, and this is indeed the only difference.
> 
> But while I love this pragmatic approach, and would be happy to take this,
> this goes against our own rules, and more importantly against Tom's one's:
> to take only direct DT file copies from the kernel tree.
> 
> Tom, can you give your opinion here? As Samuel mentioned above, the
> current mainline DTs wouldn't boot on older kernels (the changes affect
> critical devices), so this spoils stable distro and installer kernels,
> when using $fdtcontroladdr, for instance when booting via UEFI.
> 
> As a side effect of always defining SYS_SOC to "sunxi", we cannot easily
> use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance.
> 
> For context, those changed properties were in the mainline kernel tree at
> some point, but have been amended since. So it's not some random change.

So, this is I guess a bit annoying.  But, we aren't at the point where
the common use case is the downstream OS using the DTB we've loaded and
are using, are we?  I mean, we can't be, as ours are so far out of date,
so this will only be an option when we use a recent DT ourself.  So we
should be able to sync in the changes and update our code, as they can't
be using $fdtcontroladdr in this case, right?  Or am I missing the use
case that's in the wild atm?  Thanks!

-- 
Tom