[PATCH v2 2/2] ARM: dts: aspeed: add device tree for YADRO VEGMAN BMC

[Andrei Kartashev]

On Tue, 2021-12-07 at 08:11 +0000, Milton Miller II wrote:
> On Monday, December 6, 2021, Joel Stanley wrote:
> 
> > On Sat, 20 Nov 2021 at 15:51, Andrei Kartashev
> > <a.kartashev at yadro.com> wrote:
> > > 
> > > > 
> > > > Can we utilize
> > > > 
> [ gpio naming ]
> > > > to get some consistent naming across the GPIO’s on OpenBMC
> > machines?
> > > > 
> > > 
> > > Some names here are standard for Intel daemons like
> > x86-power-control,
> > > host-error-monitor, pfr-manager, IntrusionSensor and so on. Other
> > lines
> > > just called same as in schematics to make it easy for our
> > > engineers
> > to
> > > understand what does it refer to. BTW, most of the lines there
> > > not
> > used
> > > by software and appeared just because dts files are supposed to
> > > be
> > > hardware description and thus we describe all we have in
> > schematics.
> > > 
> > > We can rename all this according to guide you mention, but are
> > > you
> > > sure, there is any sense to do so?
> > > Keep in mind, currently there are lot of dts files which also
> > > don't
> > > follow convention, so I believe, it is unnecessary work.
> > 
> > I have a strong preference for using the naming document. It
> > provides
> > consistency, which makes it easier to review. I'm encouraging that
> > for
> > any new dts.
> > 
> > If you think it makes the descriptions less useful for your
> > platform
> > then that's a reasonable reason to not follow the convention.
> > 
> 
> Actually, what I would prefer is that these well established signal
> names that appear in the x86 industry servers be enumerated in the
> gpio naming document and be accepted like the original OpenPOWER
> legacy names were.   This will clearly show the names that appear 
> on other systems and will help reviewing things like power control 
> applications.
> 
> Andrei does this sound reasonable?

Actually, as TOF member I can't decline this input, it really sounds
reasonable and important for OBMC in common. I will take this action,
but this will require some time since now I'm working on other tasks.

-- 
Best regards,
Andrei Kartashev