Re: [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree

Marc Zyngier
2021-10-28T13:38:40Z

On Thu, 28 Oct 2021 13:31:13 +0100,
Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Oct 28, 2021 at 10:01:34AM +0100, Marc Zyngier wrote:
> > On Wed, 27 Oct 2021 17:54:52 +0100,
> > Michael Walle <michael@walle.cc> wrote:
> > >
> > > Please stop throwing every ad-hoc information in the device tree. Use the
> > > official bindings (or maybe some bindings which will get approved soon).
> > >
> > > On the quest of syncing the device tree used in u-boot with the one used in
> > > linux, there is this nice piece:
> > >
> > > gic_lpi_base: syscon@0x80000000 {
> > > compatible = "gic-lpi-base";
> > > reg = <0x0 0x80000000 0x0 0x100000>;
> > > max-gic-redistributors = <2>;
> > > };
> > >
> > > There is no offical binding for it. Also, the chances that there will be
> > > one are virtually zero. We need to get rid of it. In fact, most information
> > > there are already known or can be deduced via the offical binding.
> >
> > It is not "virtually zero". It is *exactly* zero. This node only shows
> > that the author didn't understand the nature of the problem, nor were
> > they aware of the existing solution which has been around since July
> > 2018. This solution doesn't require any update to the binding, only to
> > reserve the memory.
> >
> > I really wish people would stop piling crap in u-boot, and that the
> > u-boot maintainers would reach out to people familiar with the
> > architecture before merging this sort of changes.
>
> I'd be happy to reach out to people if I knew who would be receptive to
> spending some of their already I assume overload spare time looking in
> to things. If you're volunteering for "GIC related things" I'd be happy
> to CC you when patches come up. Thanks!

Absolutely. It is far less painful for me to quickly eyeball a change
and ask pointed questions on the spot, rather than having to reverse
engineer a set of dubious changes months after they have been merged.

I already provide similar "services" for EDK2, for example, so getting
the odd u-boot patch in my k.org inbox isn't a big deal.

Thanks,

M.

--
Without deviation from the norm, progress is not possible.