On Wed, Dec 13, 2023 at 11:42:45AM +0200, Svyatoslav Ryhel wrote: > > > 15 листопада 2023 р. 21:11:49 GMT+02:00, Tom Rini написав(-ла): > >On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote: > >> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote: > >> > On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote: > >> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel wrote: > >> > > > > >> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson пише: > >> > > > > > >> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel wrote: > >> > > > > > > >> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson пише: > >> > > > > > > > >> > > > > > > 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 > >> > >> On the Tegra side we've been fairly lax about the device trees in > >> U-Boot, I suppose. The assumption had always been that U-Boot would load > >> an external DTB and pass it to the kernel on boot, so keeping them both > >> in sync was never a high priority. > >> > >> U-Boot does only a very tiny amount of what Linux does, so dropping in > >> the kernel DTB always seemed a bit overkill. > >> > >> In either case, if this is problematic, it's something that I could take > >> a look at. Again, it's expected that the device trees are different, for > >> historical reasons, but I'd be surprised if they actually conflict with > >> one another. U-Boot's DTB was always supposed to be a subset of the > >> Linux DTB. > > > >So, the issue with U-Boot and kernel device trees being out of sync is > >that we then can't support the model of "just pass the current DT to the > >OS". This in general is good to support because it means that even if a > >given platform isn't formally SystemReady IR certified it's still likely > >to be functional. > > > >The most strict rule is that you can't have bindings in U-Boot that > >conflict with the kernel, or should be in the kernel but aren't, and so > >on. > > > > So you say that U-Boot should support only components which have linux > driver? May you clarify? I think Tom is referring specifically to the bindings only. While it's certainly preferable to have drivers in Linux for all bindings, that's never been a strict requirement. Thierry