[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM4PR84MB192795B45639710259E9B19D88229@DM4PR84MB1927.NAMPRD84.PROD.OUTLOOK.COM>
Date: Wed, 12 Oct 2022 19:56:26 +0000
From: "Hawkins, Nick" <nick.hawkins@....com>
To: Rob Herring <robh+dt@...nel.org>
CC: "Verdun, Jean-Marie" <verdun@....com>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v1 2/5] dt-bindings: soc: hpe: Add hpe,gxp-plreg
> > +examples:
> > + - |
> > + cpld@...89000 {
> > + compatible = "hpe,gxp-plreg", "simple-mfd", "syscon";
> > + reg = <0x1e789000 0x1000>;
> > + fan1 {
> > + bit = <0x01>;
> > + inst = <0x27>;
> > + id = <0x2B>;
> These property names are way too generic for device specific properties. There is zero description of what the h/w does and any of these child nodes to give any advice on direction. However, a node per register or register field is generally the wrong direction.
Thank you for your valued feedback. The goal I was trying to achieve here was making our programmable logic register driver interface in a generic way across multiple platforms based on inputs we provide with the .dts file for each platform. For instance if we want to read the fan 1 install status on platform X it would be reading bit 0x01 of byte 0x27 where as on platform Y it could be bit 0x02 of byte 0x16. Is there a format you would recommend that I can adhere too?
Thanks!
-Nick Hawkins
Powered by blists - more mailing lists