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@xxxxxxxxx> 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
