Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> > >
> > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > >
> > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > >
> > > > > Hi Svyatoslav,
> > > > >
> > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > >
> > > > > > Svyatoslav Ryhel (5):
> > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > >
> > > > > Is there a reason why the two above devices don't appear to have their
> > > > > .dts files in the upstream kernel?
> > > > >
> > > >
> > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > existential enemies or as dirt at least. I was trying to work with
> > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > lg_x3.
> > >
> > > The usual policy for acceptance into U-Boot is to have upstream review
> > > in the kernel first.
> > >
> >
> > May you point to a policy which clearly and explicitly states this as
> > a mandatory condition?
> 
> There have been a number of devices rejected in the past until their
> DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> to clarify the exact policy.

Well, here is where it's tricky. I brought this up for one of the
Broadcom MIPS platforms a week or two back, and Linus Walleij's point
(and I'm paraphrasing) is there's not really an upstream for it to go.

What we cannot have is device tree bindings[1] that aren't upstream or
worse yet conflict with the official bindings.

So the general way to resolve that is have device tree file be drop-in
from the linux kernel, and what additions we must have be done via
-u-boot.dtsi files. And in turn, some SoCs are better about keeping in
sync with the kernel than other SoCs are.

Now, upstream being actively hostile to dts files, especially for older
platforms? That's unfortunate. So long as we aren't violating the rules
about bindings, the intention is that we don't have device trees that
are either (a) massively out of sync with the kernel[2] or (b) kept
intentionally mismatched from the kernel.

-- 
Tom

[1]: There are both examples like binman that Simon is working on at
least but this is more exception than intentional rule.
[2]: Per our other conversions, I know the tegra ones are in this
unfortunate state in general

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]