On Sep 15, 20= 21, at 12:15 AM, Milton Miller II <miltonm@us.ibm.com> wrote:

On = September 14, 2021, Joel Stanley wrote:
On Tue, 14 Sept 2021 at 20:46, Adriana Kobylak &l= t;anoo@linux.ibm.com&g= t;
wrote:
=
On Sep 14, 2021, at 3:49 AM, Joel Stan= ley <joel@jms.id.au>= wrote:
On Fri, 10 Sept 2021 at 19:54, Adriana Kobylak
<anoo@linux.ibm= .com> wrote:

From: Adriana Kobylak <anoo@us.ibm.com>

The N_MODE_VRE= F gpio is designed to be used to specify how many
power
supplies the system should have (2 or 4). If enough powersupplies fail
so that the system no longer has re= dundancy (no longer n+1), the
hardware will signal to the Onb= oard Chip Controller that the
system may
be ove= rsubscribed, and performance may need to be reduced so the
sy= stem
can maintain it's powered on state. This gpio is on a 95= 52,
populate all
the gpios on that chip for com= pleteness.

Signed-off-by: Adriana Kobylak <= anoo@us.ibm.com>
---

v2: Update commit message.

arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 103
+++++++++++++++++++
1 file changed, 103 insertio= ns(+)

diff --git a/arch/arm/boot/dts/aspeed-bm= c-ibm-rainier.dts
b/ar= ch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
index 6fd3ddf97a21..d5eea86dc260 100644
= --- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
+++ b/arch= /arm/boot/dts/aspeed-bmc-ibm-rainier.dts
@@ -1502,6 +1502,109= @@ eeprom@51 {
       &nb= sp;      reg =3D <0x51>;
=       };

+ = ;     pca_pres3: pca9552@60 {
+ &nbs= p;            &= nbsp;compatible =3D "nxp,pca9552";
+     =           reg =3D <0x6= 0>;
+         &nbs= p;     #address-cells =3D <1>;
+             =   #size-cells =3D <0>;
+    &n= bsp;          gpio-contro= ller;
+          = ;     #gpio-cells =3D <2>;
++           =     gpio-line-names =3D
+   &nb= sp;            =        "",
+   &= nbsp;           &nbs= p;       "APSS_RESET_N",
+=             &n= bsp;         "", "", "", "",+           =             "P1= 0_DCM0_PRES",
+        &nb= sp;            =   "P10_DCM1_PRES",
+      =             &nb= sp;    "", "",
+     =             &nb= sp;     "N_MODE_CPU_N",
+ &nbs= p;            &= nbsp;       "",
+ &n= bsp;            = ;        "PRESENT_VRM_DCM0_N",
+           &nb= sp;           "PRESE= NT_VRM_DCM1_N",
+        &= nbsp;           &nbs= p;  "N_MODE_VREF",

Shou= ld any (all?) of these names be documented?

INVALID URI REMOVED
mc_docs_blob_master_designs_de= vice-2Dtree-2Dgpio-2Dnaming.md&d=3DDwIFaQ
&c=3Djf_iaS= HvJObTbx-siA1ZOg&r=3Dbvv7AJEECoRKBU02rcu4F5DWd-EwX8As2xrXeO9ZS
o4&m=3DJzmffOJA0hX_vgi3n0P-A6l60imZToV7q1U2W2h6xt4&s=3D14_ACu= QWMp-IFlhLQa
ejLVBN8XVgDnn1_l6336-FBG8&e=3D

Not sure. Seems the openbmc doc is documenting= the gpios for
gpiochip0 only?

AIUI the d= ocument is for GPIOs that are exposed to userspace.

It doesn't matter where they're coming from. If they are going to be<= br class=3D"">used by a libgpio application, they need to have names, and t= he names
should be documented where possible.
<= br class=3D"">

I agre= e which gpiochip is just a board wiring consideration and has
no bearing on the documentation.

However, in the intro= ductory sections in the document clearly says
the p= urpose is to establish naming for common (function) GPIOs, and
the justification is by using consisten= t names across machines code
will be able to be reu= sed with little to no configuration. In
addit= ion it mentions "common" GPIOs must be added to the document in
the future. So an evaluation should be made to the like= lihood that
such code reuse can be anticipated.

Most of the names added in this patch are presence detect signals us= ed
to cross check VPD is re= ad into inventory.   I'd expect any such uses to
be configured in an inventory config file = listing the name and where the
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Verdana; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none; float: none; display: inline !important;" class= =3D"">FRU appears in the Dbus or Redfish model. I'd argue the names f= or any
such gpio would be beyond the present docu= ment scope.

The one mentioned in the changelog, N_MODE_VREF, is i= ntended to
be relayed to the OCC, basically a power= management controller in
c= ommon in POWER processor chips. I can see an argument to list this,
but feel it would be in the = OpenPOWER specific section unless the=
activation me= thod is exposed in some method that would be common
to other chipsets.

Thanks. I submitted a proposal to def= ine N_MODE_VREF: https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/= 46914
Once the name is approved I=E2=80=99ll add just that on= e to the device tree, since the others are not going to be used.

...documented in the openbmc des= ign
doc, such as SLOT6_PRSNT_EN_RSVD, SLOT11_EXPANDER_PRSNT_N= , etc.

They should be fixed, if possible.

The scope = is clearly use reusable names going forward. The technical
debt from past naming can be brought = down as new uses are added but
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Verdana; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none; float: none; display: inline !important;" class= =3D"">we are not renaming every GPIO in every existing platform, and we don= 't
have the review bandwidt= h to agree on common names should be added for
all existing signals.

milton