lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 9 Mar 2019 17:47:59 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Renato Lui Geh <renatogeh@...il.com>
Cc:     "Ardelean, Alexandru" <Alex.Ardelean@...log.com>,
        "kernel-usp@...glegroups.com" <kernel-usp@...glegroups.com>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "knaack.h@....de" <knaack.h@....de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "giuliano.belinassi@....br" <giuliano.belinassi@....br>,
        "pmeerw@...erw.net" <pmeerw@...erw.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "Popa, Stefan Serban" <StefanSerban.Popa@...log.com>
Subject: Re: [PATCH v4 4/9] staging:iio:ad7780: add chip ID values and mask

On Fri, 8 Mar 2019 21:19:29 -0300
Renato Lui Geh <renatogeh@...il.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@...il.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@...il.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
> >> > > >  
> >>
> >>  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ