What on earth has happened here with quoting? Please fix your mail client man, this mail is a mess to read.
On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote: > > > Le 7 déc. 2023 à 19:51, Rob Herring <robh...@kernel.org> a écrit : > > On Thu, Dec 7, 2023 at 2:08 AM ff <f...@shokubai.tech> wrote: > > > > Le 6 déc. 2023 à 21:42, Rob Herring <robh...@kernel.org> a écrit : > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.g...@linaro.org> wrote: > > On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > <krzysztof.kozlow...@linaro.org> wrote: > > On 05/12/2023 10:45, Sumit Garg wrote: > + U-boot custodians list > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > <krzysztof.kozlow...@linaro.org> wrote: > > On 05/12/2023 08:13, Sumit Garg wrote: > @DT bindings maintainers, > > Given the ease of maintenance of DT bindings within Linux kernel > source tree, I don't have a specific objection there. But can we ease > DTS testing for firmware/bootloader projects by providing a versioned > release package for DT bindings? Or if someone else has a better idea > here please feel free to chime in. > > This doesn't work for you?: > > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > Thanks, this is certainly a good step which I wasn't aware of. Further > simplification can be done to decouple devicetree source files from DT > bindings. > > Why? > > I suppose you are already aware that Linux DTS files are a subset of > what could be supported by devicetree schemas. There can be > firmware/bootloader specific properties (one example being [1]) which > Linux kernel can simply ignore. Will you be willing to add all of > those DT properties to Linux DTS files and maintain them? > > We already added them and we already maintain them. DTS describes the > hardware, not the OS-subset of the hardware. > > Let look at some numbers if your statement is justified or not for the > example I gave: > > u-boot$ git grep -nr bootph-* arch/arm* | wc -l > 4079 > > linux$ git grep -nr bootph-* arch/arm* | wc -l > 267 > > I have no control over whether anyone has submitted the other 3812 instances. > > It looks like there is always going to be a catch up game regarding DT > properties which either Linux kernel or u-boot or any other > firmware/bootloader project don't care about. > > As long as dts files in u-boot are manually sync'ed, yes. That is the > problem and it doesn't matter if we have a standalone repository or > not. > > If you want to move in that direction, start automating what u-boot > imports. You need to do that for bindings if you want to run > validation, so why not dts files too? > > However, DT bindings are something which should be common, the > hardware description of a device should be universal. IMO, splitting > > Both DT bindings and DTS should be common. I don't see the difference. > > If we really care about DTS to be common then the contribution model > has to change where there is a single repo hosting DT bindings and > DTS. All other projects whether it is Linux kernel or u-boot or any > other OS/firmware/bootloader are just consuming DTS files from that > single repo. > > Really, only the kernel and u-boot matter. No, I don't mean I don't > care about other projects, but those are the 2 with the widest h/w > support by far and which have a major effort to sync copies of dts > files in both projects. The rest are just noise in terms of this > problem. > > I suppose this is something that Linux DT maintainers > have objected to in the past for ease of maintenance. I am not sure if > you folks are willing to change that stance. > > The issue is no one steps up to help maintain such a repository while > there is lots of review and maintainer work on what goes into the > kernel tree. I'm happy to direct my binding review attention to > wherever the majority of the bindings go. But the work on the DTS side > is mostly SoC tree maintainers and sub-maintainers. > > Assume for a minute we have this standalone repo. What happens next? > We start with an empty repo and then merge and move platforms 1 by 1? > > What about leveraging SystemReady-IR compliant board maintainers and start > with a core of motivated people ? > > I think there are 2 ATM. Synquacer and i.MX8 variants. > > Based on > https://www.arm.com/architecture/system-architectures/systemready-certification-program/ir > roughly 30 boards. > > Synquacer only > has a DT in u-boot, so not really anything to do there. > I'm pretty > sure the certified DTBs for i.MX8 don't match what's in u-boot or the > kernel tree. Hopefully, it's just a subset, but still, there's a gap. > I don't know that there is motivation there either. > Note that SystemReady currently only requires every node with > 'compatible' have a schema. It does not yet require no schema > warnings. If we went with a 1 by 1 approach, I would push that > platforms have to be free of warnings. > > How many years will that take? > > Should all platforms following that organization be a goal? > > You mean should all platforms be moved? Absolutely. I don't think we > want to solve the problem of having DTS files in 2 places by creating > a 3rd place. I think this bit here is the only thing you actually wrote: > Actually, if we limit he DTS in the third place for SystemReady-IR, > there should be no DTB in the Linux distribution. > It would be the equivalent as ACPI boards . So is it still an issue ? > A reference to the the third repo may be hinted in a text file. SystemReady is only for one architecture, why would using it as the centralised point for devicetree files make sense? > > I don't really think 1 by 1 is the right approach. I was just > enumerating how this could work. It's not that useful to say we need a > standalone repo without working thru the logistics of how exactly that > will work. > > Rob
signature.asc
Description: PGP signature