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

[Thierry Reding]

On Mon, Nov 13, 2023 at 04:52:22PM +0000, Peter Robinson wrote:
> > > > > > > > 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.
> 
> I don't believe I've seen upstream Tegra maintainers being actively
> hostile towards updates for older devices, I know they have certainly
> defocused them, but I'm not sure that's what I'd consider hostile.

No objections from me on upstreaming older devices in Linux. I used to
be able to test most of the older devices, but many of which I used to
have direct access to are now defunct (for varying reasons). So I will
have to rely on the community for testing etc. since I cannot scale to
the point where I personally have all of these devices.

Now, I don't think that's hostile and if I ever came across as hostile
I'm sorry. The intent was never to reject device support. Obviously the
Linux kernel has high standards and sometimes that can be off-putting,
but I don't think we've ever asked for anything out of the ordinary.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231115/5067e219/attachment.sig>