> > > > > > > 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. > [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