Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
From:   "Miclaus, Antoniu" <Antoniu.Miclaus@analog.com>
To:     Guenter Roeck <linux@roeck-us.net>
CC:     Rob Herring <robh@kernel.org>,
        "Matyas, Daniel" <Daniel.Matyas@analog.com>,
        Jean Delvare <jdelvare@suse.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        "linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] dt-bindings: hwmon: max31827: use supply pin name
Thread-Topic: [PATCH 1/2] dt-bindings: hwmon: max31827: use supply pin name
Thread-Index: AQHZ7JbW8bVvOja/3EqvTv/jlHNtWLAnWa2AgAEcYACAAW6uAIABUlFg
Date:   Mon, 25 Sep 2023 08:15:07 +0000
Message-ID: <CY4PR03MB339942655F5E8DE95F4F24999BFCA@CY4PR03MB3399.namprd03.prod.outlook.com>
References: <20230921142005.102263-1-antoniu.miclaus@analog.com>
 <20230922211201.GA3600661-robh@kernel.org>
 <CY4PR03MB3399B818487F87D7297EC33F9BFEA@CY4PR03MB3399.namprd03.prod.outlook.com>
 <0cb70677-6dfd-43e0-a3c5-cae3b861a7d1@roeck-us.net>
In-Reply-To: <0cb70677-6dfd-43e0-a3c5-cae3b861a7d1@roeck-us.net>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?VyjlyQ6DxoeJRTBOl7aVbD2jFoTZnpvN+Hq8YcWyQXjT1sLQxLKqz9JiFjjm?=
 =?us-ascii?Q?4giuiHhGnuXr+f++cAWz/QYUhVl1Otimk/1htnypuTV5EIcmQOxVBAmCPb8U?=
 =?us-ascii?Q?M4/WwzR5kmUFk5RroOZnW9KhSfaKmlCm6XS3pIVeKs5EpuYkJHekiGcdjM0+?=
 =?us-ascii?Q?osTX/OWtaRZMoBQ7qIdOPLalVXx9nxYIhlQBdV0hu8lXd1vmtlPuh8EboEoo?=
 =?us-ascii?Q?qUKj92DOgAINFNFiXlODyA+a3TLT6beK4Pia/aR1LsqXU0iHbTxAYywARZPN?=
 =?us-ascii?Q?wQSOzfIqJ41kdWjCUpJVv4/nAQJ/53Bho1Y3zPe8uinYEg/BuCr2vuxXWkQ3?=
 =?us-ascii?Q?mpKND2pvIpCLgbvYKJVW+FxQtpTk4HZ+dXvU9n862Cg8Mfk2lSjkNUTCZ82D?=
 =?us-ascii?Q?oTTtYxS01EheaNS/ywW/qLiXkgytLfJ3+X884vKfq8uuOp2uVBsh91WEyII8?=
 =?us-ascii?Q?fHhZ2L/KwWZoqWzASLQcOsZWMBc9APCvI8lDc238XyRcWZOxKkMzesFXxLW5?=
 =?us-ascii?Q?Us9f/rY4ESPT/tX5s9l0r5WQ63Fjl23T+eydqt0TTm9L+QOII8zrfSnTFurU?=
 =?us-ascii?Q?Tkh81zEVMLD98/aSLmwsWeYWerkpjXgtrpFmNHZkkBumOntfdR7u9ctU0ROA?=
 =?us-ascii?Q?GmCdqBIFs2ZJg0lgYn0v3+Z3AzvO3U2XZNce4ZyNdWuxDLfH0R1K5kOLm4hI?=
 =?us-ascii?Q?kObUXv27AOPjmVZn7RigJwE1gUSvTYXzIZNcXgsg3pezoUUXLZMruNCz5iA6?=
 =?us-ascii?Q?7t31dotYtnubfRy8KVZwZrWFRWamwbtMND1IfmjKl8v/4iU5xNHdSXTFhUjI?=
 =?us-ascii?Q?1xrgV7ufDOAARVIc/bq6E2Mrb2Q4QMb9kvE4Xg8XYYKP6hI6K1GJTKoow/f3?=
 =?us-ascii?Q?OBqjnWcjiUf3umEAITxNsOTV2sjYwHIpeAq/9wb8dqts/kwEA2PJ7QtbQjet?=
 =?us-ascii?Q?+3rSuBKJS0bd2SGN0Ojdyn7/D3GUSHVB5Y7PfydSUu8+s9ujLAt0hMjUrEly?=
 =?us-ascii?Q?yNLBVwF46NO/7N1VPfFVzRzyLtG3lWcbqHRmR7kShqDfjYHRI+EVo2u4nfqL?=
 =?us-ascii?Q?/rUFhVBHwhvek+HBDoWfVr6hO0sTCbIC7erfVkD40Tv2j/wYDkx2Yq/0DW4S?=
 =?us-ascii?Q?zKgL6AjX5OW47rxHQMjRA+ULxMEJQzib2kM02lGFysngYvOc+mHuvromcWFE?=
 =?us-ascii?Q?sGRQlFgWg7qfczpZ20w2wzFE3sA6wT6M5d1SUsQ7G4LBbdkxsWhGbL8fVl1w?=
 =?us-ascii?Q?MwBBgUS3RqkWUDedaHjy1zXN7P5JcrpKnr7hFtLX5gi2MjpBy0lyBfDKboZj?=
 =?us-ascii?Q?Te/DJUQSVgaEvv6QoeSjoNCTKyzLNyQIJSFQyo4Iwbzy4LBzY37k8cWvjTL2?=
 =?us-ascii?Q?SxW+ytOjh0LeWjw4HGO7uGlqEWeaFz/Z6qQBzuU5ZD9vkS/zoXDVBDCXC/C4?=
 =?us-ascii?Q?yz4n2BAQwTfequGqNnHlLpGrx3ijrWqcQhZJiUSVw4+hHkfNrFq+oH9HdupZ?=
 =?us-ascii?Q?ye8E7Fr6btmxSN1ix4VelvXNRFb7ePfqMymdQfCUL4Mjkg/3PYBwamCen1NV?=
 =?us-ascii?Q?SKgNmT4AO5weqDnq9U9q39qL7ntfD4iQFqpBBs1KMHQPiTFkkhTx7imzgdck?=
 =?us-ascii?Q?KA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: analog.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR03MB3399.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cfe51e6-31e2-4fd2-620b-08dbbd9f87b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2023 08:15:07.6938
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: eaa689b4-8f87-40e0-9c6f-7228de4d754a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KDnygDmdQOGU+pUBoN1wtIhd+v6lbLMZfrqSHOEv94AnLw2mzPWnOrKmU4ggUUsrRTo1K4WzwErVVZogAwiA+AHVyq2uAX2bazBT/qAwaJk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5218
X-Proofpoint-GUID: b-g4tfzLH_efpgV8FMSujRTr4g5CTpI8
X-Proofpoint-ORIG-GUID: b-g4tfzLH_efpgV8FMSujRTr4g5CTpI8
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-09-25_04,2023-09-21_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0
 suspectscore=0 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 spamscore=0
 priorityscore=1501 clxscore=1015 malwarescore=0 adultscore=0 bulkscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2309180000 definitions=main-2309250058
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 25 Sep 2023 01:16:27 -0700 (PDT)

> On Sat, Sep 23, 2023 at 02:19:45PM +0000, Miclaus, Antoniu wrote:
> >
> >
> > > On Thu, Sep 21, 2023 at 05:20:03PM +0300, Antoniu Miclaus wrote:
> > > > The actual hardware pin name for the supply of max31827 is vdd.
> > > > Update the dt-binding to reflect the hardware properties accordingl=
y.
> > >
> > > Changing this breaks the ABI. I see the old one wasn't used by the
> > > driver, but that's just one driver potentially. You need some
> > > justification here why it's okay to break the ABI.
> > >
> > As I mentioned also in the commit description, the supply should match =
the
> > actual hardware pin name. Otherwise it might create confusion. Usually
> vref
> > refers to an external voltage reference pin used for ADC/DACs which is =
not
> > exactly the case for this part, taking into account that there is no
> "reference"
> > word mentioned in the datasheet at all. VREF and VDD are usually separa=
te
> > hardware pins. There is a hint indeed in the dts example that the vref-
> supply
> > might be referenced to a vdd regulator node, but from my point of view
> > that is not enough. Moreover the current vref-supply is not handled at =
all in
> > the driver, it is only mentioned in the dt-binding (That's why I added =
a
> second
> > patch in the series handling the supply).
> >
> > If the justification is not enough to apply this change, then I can kee=
p only
> the
> > second patch, which handles the regulator in the driver and use the  ol=
d
> `vref`
> > naming which currently appears only in the dt-binding.
> >
>=20
> That would have been a good argument when the property was introduced,
> but if
> there are any systems with existing bindings out there they will use the =
old
> name and fail after this change is applied.
>=20
> I don't thnk it is mandated that every system in the world would publish =
their
> devicetree bindings in the kernel. That would not scale. So any argument
> along
> the line of "this binding is not used" is not really a valid argument.
>=20
> Guenter
Will keep then only the second patch which targets the driver.
Thanks for the feedback!