From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51124C4338F for ; Sat, 14 Aug 2021 16:01:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2BA4360ED5 for ; Sat, 14 Aug 2021 16:01:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229818AbhHNQBh convert rfc822-to-8bit (ORCPT ); Sat, 14 Aug 2021 12:01:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:58714 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232131AbhHNQBg (ORCPT ); Sat, 14 Aug 2021 12:01:36 -0400 Received: from jic23-huawei (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 96FD360295; Sat, 14 Aug 2021 16:01:05 +0000 (UTC) Date: Sat, 14 Aug 2021 17:04:02 +0100 From: Jonathan Cameron To: "Sa, Nuno" Cc: Andy Shevchenko , Rob Herring , linux-iio , "Hennerich, Michael" , Lars-Peter Clausen Subject: Re: [PATCH] iio: ad5770r: make devicetree property reading consistent Message-ID: <20210814170204.387bf394@jic23-huawei> In-Reply-To: References: <20210811074827.21889-1-nuno.sa@analog.com> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On Fri, 13 Aug 2021 10:05:17 +0000 "Sa, Nuno" wrote: > > -----Original Message----- > > From: Andy Shevchenko > > Sent: Friday, August 13, 2021 10:05 AM > > To: Sa, Nuno > > Cc: Rob Herring ; linux-iio > iio@vger.kernel.org>; Jonathan Cameron ; > > Hennerich, Michael ; Lars-Peter > > Clausen > > Subject: Re: [PATCH] iio: ad5770r: make devicetree property reading > > consistent > > > > On Fri, Aug 13, 2021 at 10:47 AM Sa, Nuno > > wrote: > > > > From: Rob Herring > > > > Sent: Thursday, August 12, 2021 5:11 PM > > > > On Thu, Aug 12, 2021 at 3:14 AM Sa, Nuno > > > > wrote: > > > > ... > > > > > > > Could you give your input on this one? > > > > > > > > There's no context, but I'm assuming this is in channel nodes. Keep > > > > > > Sorry about that. Your assumption is correct, the binding is for a > > channel > > > node [1]. The driver just get's it as 'num' [2] which is not consistent. > > > Naively, I just though changing the driver to use reg would be > > enough > > > but Andy nicely raised the question of someone being already relying > > > on 'num'... > > > > > > > the binding 'reg' and make the driver support both if needed. > > > > Considering the author of the binding also changed the binding > > from > > > > num to reg shortly after adding the binding, I don't think 'num' > > > > support is needed. If someone used 'num' and didn't run > > validation, > > > > well, that's their problem. > > > > > > > > > > So I guess the solution here is just to change the driver to support > > both > > > reg and num. > > > > As far as I got Rob's answer, if the binding never had the 'num', > > dropping it from the driver is what we want now (actually your > > original patch) and users, who are 'too much clever' :-) should have > > had run validation for their DTs before production. > > > > Taking this into account, I'm fine with the patch (but update a commit > > message to summarize this discussion) > > Reviewed-by: Andy Shevchenko > > > > You're right... > Jonathan, do you want a v2 with an updated commit message? Please do. Also please add a fixes tag given we are treating it as a fix. If we discover someone is using the num variant then we'll just have to support both values as a fix to the fix. Not ideal, but as observed, hopefully people are validating the DTs (which basically means no one is using this in production or it would have been pointed out before). Jonathan > > - Nuno Sá