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

Will do, thanks!

-- 
Tom

Attachment: signature.asc
Description: PGP signature

Reply via email to