[PATCH 00/21] Qualcomm generic board support

[Conor Dooley]

On Fri, Dec 08, 2023 at 09:39:27AM +0000, ff wrote:
> 
> 
> Le 7 déc. 2023 à 21:31, Conor Dooley <conor at kernel.org> a écrit :
> 
> What on earth has happened here with quoting? Please fix your mail
> client man, this mail is a mess to read.
> 
> Conor: Hopefully I have now fixed MacOS Mail configuration…
> For all: please accept my apologies on past inconveniences.

Judging by this mail looking like it does, nothing has changed?
You can check it on lore too:
https://lore.kernel.org/u-boot/CAC_iWjKKwjpD1VAbXJaB=UDQPWMS+k65tv-qL=JnewzSEhGEow@mail.gmail.com/T/#ma8c4fc1268c68aab0b05b96b2cea5c90cc2525b8

I'm not going to fix the quoting by hand, I have better things to do :)

Cheers,
Conor.

> 
> On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote:
> 
> 
> Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt at kernel.org> a écrit :
> 
> On Thu, Dec 7, 2023 at 2:08 AM ff <ff at shokubai.tech> wrote:
> 
> 
> 
> Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt at kernel.org> a écrit :
> 
> On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg at linaro.org> wrote:
> 
> On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski
> <krzysztof.kozlowski at 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.kozlowski at 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?
> 
> SystemReady is an Arm certification but built on EBBR which is
> the important part and also adopted by RISC-V.
> So when I said SystemReady, one should read EBBR.
> EBBR is promoting a DT life cycle that is in line with
> having an out of OS/Firmware repos definitions.
> 
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231208/2988df2b/attachment.sig>