> -----Original Message----- > From: Rob Herring <robh+dt@xxxxxxxxxx> > Sent: Monday, August 16, 2021 2:19 PM > To: Sa, Nuno <Nuno.Sa@xxxxxxxxxx> > Cc: Jonathan Cameron <jic23@xxxxxxxxxx>; Andy Shevchenko > <andy.shevchenko@xxxxxxxxx>; linux-iio <linux-iio@xxxxxxxxxxxxxxx>; > Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>; Lars-Peter > Clausen <lars@xxxxxxxxxx> > Subject: Re: [PATCH] iio: ad5770r: make devicetree property reading > consistent > > On Mon, Aug 16, 2021 at 2:54 AM Sa, Nuno <Nuno.Sa@xxxxxxxxxx> > wrote: > > > > > > > > > -----Original Message----- > > > From: Jonathan Cameron <jic23@xxxxxxxxxx> > > > Sent: Saturday, August 14, 2021 6:04 PM > > > To: Sa, Nuno <Nuno.Sa@xxxxxxxxxx> > > > Cc: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>; Rob > Herring > > > <robh+dt@xxxxxxxxxx>; linux-iio <linux-iio@xxxxxxxxxxxxxxx>; > > > Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>; Lars-Peter > > > Clausen <lars@xxxxxxxxxx> > > > Subject: Re: [PATCH] iio: ad5770r: make devicetree property > reading > > > consistent > > > > > > [External] > > > > > > On Fri, 13 Aug 2021 10:05:17 +0000 > > > "Sa, Nuno" <Nuno.Sa@xxxxxxxxxx> wrote: > > > > > > > > -----Original Message----- > > > > > From: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > > > > > Sent: Friday, August 13, 2021 10:05 AM > > > > > To: Sa, Nuno <Nuno.Sa@xxxxxxxxxx> > > > > > Cc: Rob Herring <robh+dt@xxxxxxxxxx>; linux-iio <linux- > > > > > iio@xxxxxxxxxxxxxxx>; Jonathan Cameron <jic23@xxxxxxxxxx>; > > > > > Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>; Lars- > Peter > > > > > Clausen <lars@xxxxxxxxxx> > > > > > Subject: Re: [PATCH] iio: ad5770r: make devicetree property > > > reading > > > > > consistent > > > > > > > > > > On Fri, Aug 13, 2021 at 10:47 AM Sa, Nuno > <Nuno.Sa@xxxxxxxxxx> > > > > > wrote: > > > > > > > From: Rob Herring <robh+dt@xxxxxxxxxx> > > > > > > > Sent: Thursday, August 12, 2021 5:11 PM > > > > > > > On Thu, Aug 12, 2021 at 3:14 AM Sa, Nuno > > > <Nuno.Sa@xxxxxxxxxx> > > > > > > > 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 > <andy.shevchenko@xxxxxxxxx> > > > > > > > > > > > > > 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). > > > > > > > Well, It seems we need to go through the support both 'num' and > 'reg' > > route... I did some git blaming and it turns out 'num' was actually > supported > > in the bindings [1]. After some time it was replaced by 'reg' [2] > leaving the > > driver unchanged... I guess we have a significant window of time > here > > where someone could deploy a *validated* devicetree using 'num'... > > No there wasn't. Both commits landed in v5.7. Ahh I see. I just looked to dates without thinking in release cycles... > > If no objections, on v2 I will just try to get 'reg' and if not present, > fallback > > to 'num' before erroring out. > > Unless a user turns up and complains, then I say drop 'num'. > Ok, thanks! That's easier for me... - Nuno Sá
