> Le 4 déc. 2023 à 12:00, Daniel Thompson <daniel.thomp...@linaro.org> a écrit : > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >> + Linux kernel DT bindings maintainers, EBBR ML >> >>> On Thu, 30 Nov 2023 at 20:05, Tom Rini <tr...@konsulko.com> wrote: >>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: >>>> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstr...@linaro.org> >>>> wrote: >>>>>> I've been thinking about and hacking on this for the last week or so, >>>>>> sorry for the delayed reply here. >>>>>> >>>>>> The value is in preventing any of the existing bindings from regressing, >>>> >>>> That is actually best addressed in Linux by checking the DTS against >>>> yaml DT bindings. We don't have that testing available in u-boot and >>>> only depend on careful reviews. >>> >>> I would absolutely love for someone to make another attempt at updating >>> our kbuild infrastucture so that we can run the validation targets. >>> >> >> Given that EBBR requires [1] the platform (firmware/bootloader) and >> not OS to supply the devicetree, it becomes evident that >> firmware/bootloaders import DTS from Linux kernel (where it is >> maintained). >> >> But currently u-boot doesn't have a proper way to validate those DTS >> against DT bindings (maintained in Linux kernel). Although there are >> Devicetree schema tools available here [2], there isn't a versioned >> release package of DT bindings which one should use to validate DTS >> files. > > The kernel is regularly released in multiple forms (including git > tags and tarball). Why isn't the kernel itself sufficient to be a > versioned release of the DT bindings directory? > The Linux kernel may not see all devices. For instance it could see a PCI port while the firmware sees a SERDES that is configured to match the board implementation and touting. The firmware shall be responsible to, statically or dynamically make those things available to the kernel. An OS distribution (not necessarily Linux) should not embedded all possible combinations and know all derived boards.
> > Daniel. > _______________________________________________ > boot-architecture mailing list -- boot-architect...@lists.linaro.org > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
