Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 9 Mar 2019 17:47:59 +0000
From:   Jonathan Cameron <jic23@kernel.org>
To:     Renato Lui Geh <renatogeh@gmail.com>
Cc:     "Ardelean, Alexandru" <Alex.Ardelean@analog.com>,
        "kernel-usp@googlegroups.com" <kernel-usp@googlegroups.com>,
        "lars@metafoo.de" <lars@metafoo.de>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "knaack.h@gmx.de" <knaack.h@gmx.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "Hennerich, Michael" <Michael.Hennerich@analog.com>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "giuliano.belinassi@usp.br" <giuliano.belinassi@usp.br>,
        "pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "Popa, Stefan Serban" <StefanSerban.Popa@analog.com>
Subject: Re: [PATCH v4 4/9] staging:iio:ad7780: add chip ID values and mask
Message-ID: <20190309174759.2c6b1435@archlinux>
In-Reply-To: <20190309001928.uhwia4ujvqqwawlg@renatolg>
References: <cover.1551358569.git.renatogeh@gmail.com>
        <90c573cd53bb54d49de6ac270bcff66880ccfeb5.1551358569.git.renatogeh@gmail.com>
        <190e26b19b8ed6559b92d3a000d852bbb0099a52.camel@analog.com>
        <20190303140107.ljjo3flatwmd44ya@renatolg>
        <20190303145347.41d49646@archlinux>
        <13ef212f8aeebd0c893be253cb4834a3e4d741b8.camel@analog.com>
        <20190309001928.uhwia4ujvqqwawlg@renatolg>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, 8 Mar 2019 21:19:29 -0300
Renato Lui Geh <renatogeh@gmail.com> wrote:

> On 03/04, Ardelean, Alexandru wrote:
> >On Sun, 2019-03-03 at 14:53 +0000, Jonathan Cameron wrote:  
> >> [External]
> >>
> >>
> >> On Sun, 3 Mar 2019 11:01:09 -0300
> >> Renato Lui Geh <renatogeh@gmail.com> wrote:
> >>  
> >> > On 03/01, Ardelean, Alexandru wrote:  
> >> > > On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote:  
> >> > > >
> >> > > >
> >> > > > The ad7780 supports both the ad778x and ad717x families. Each chip
> >> > > > has
> >> > > > a corresponding ID. This patch provides a mask for extracting ID
> >> > > > values
> >> > > > from the status bits and also macros for the correct values for the
> >> > > > ad7170, ad7171, ad7780 and ad7781.
> >> > > >
> >> > > > Signed-off-by: Renato Lui Geh <renatogeh@gmail.com>
> >> > > > ---
> >> > > >  drivers/staging/iio/adc/ad7780.c | 8 ++++++--
> >> > > >  1 file changed, 6 insertions(+), 2 deletions(-)
> >> > > >
> >> > > > diff --git a/drivers/staging/iio/adc/ad7780.c
> >> > > > b/drivers/staging/iio/adc/ad7780.c
> >> > > > index 56c49e28f432..ad7617a3a141 100644
> >> > > > --- a/drivers/staging/iio/adc/ad7780.c
> >> > > > +++ b/drivers/staging/iio/adc/ad7780.c
> >> > > > @@ -26,10 +26,14 @@
> >> > > >  #define AD7780_RDY             BIT(7)
> >> > > >  #define AD7780_FILTER          BIT(6)
> >> > > >  #define AD7780_ERR             BIT(5)
> >> > > > -#define AD7780_ID1             BIT(4)
> >> > > > -#define AD7780_ID0             BIT(3)
> >> > > >  #define AD7780_GAIN            BIT(2)
> >> > > >
> >> > > > +#define AD7170_ID              0
> >> > > > +#define AD7171_ID              1
> >> > > > +#define AD7780_ID              1
> >> > > > +#define AD7781_ID              0
> >> > > > +
> >> > > > +#define AD7780_ID_MASK         (BIT(3) | BIT(4))  
> >> > >
> >> > > This also doesn't have any functionality change.
> >> > > The AD7170_ID, AD7171_ID, AD7780_ID & AD7781_ID IDs are also unused
> >> > > (maybe
> >> > > in a later patch they are ?).  
> >> >
> >> > They aren't. I added them following a previous review suggestion.
> >> > Should
> >> > I remove them?  
> >>
> >> Can we check them?  It's always useful to confirm that the device is
> >> the one you think it is.  Then we can either use what is there
> >> with a suitable warning, or if that is tricky just fault out as the
> >> dt is giving us the wrong part number.
> >>
> >> J  
> >
> >I guess `dev_warn_ratelimited()` could be used to make sure syslog isn't
> >spammed-to-death when doing multiple conversions, and the ID isn't correct.
> >Since these IDs are read after you get a sample, I'm a bit fearful of log-
> >spam.
> >
> >I wouldn't throw an error in the ad7780_postprocess_sample() for this, but
> >warning [with rate-limit] sounds reasonable.  
> 
> Looking at dev_warn_ratelimited's definition (and its use in other parts
> of the kernel), I see that we'd need the device to be stored somewhere
> (perhaps in ad7780_state?) in order for us to pass it as argument to
> dev_warn from within postprocess_sample. Should this be stored in
> ad7780_state?  Or can I get the spi_device some other way?
Ah. I was being lazy and hadn't looked at the datasheet.

If they are that nasty to get to, don't bother checking them.
Mostly we can assume people don't claim to have the wrong
compatible device.

Jonathan

> >  
> >>  
> >> > >
> >> > > I would also leave the AD7780_ID1 & AD7780_ID0 definitions in place,
> >> > > since
> >> > > they're easier matched with the datasheet.
> >> > >  
> >> > > >
> >> > > >  #define AD7780_PATTERN_GOOD    1
> >> > > >  #define AD7780_PATTERN_MASK    GENMASK(1, 0)
> >> > > > --
> >> > > > 2.21.0
> >> > > >  
> >>
> >>