On Fri, 8 Mar 2019 21:19:29 -0300 Renato Lui Geh <renatogeh@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> > >> > > > --- > >> > > > 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 > >> > > > > >> > >> _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
