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

Tom Rini trini at konsulko.com
Thu Oct 28 15:51:24 CEST 2021


On Thu, Oct 28, 2021 at 02:38:26PM +0100, Marc Zyngier wrote:
> On Thu, 28 Oct 2021 13:31:13 +0100,
> Tom Rini <trini at 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 at 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 at 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.

Will do, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211028/047f6bfb/attachment.sig>


More information about the U-Boot mailing list