linux-kernel - Re: [PATCH v5 2/2] iio: vadc: Qualcomm SPMI PMIC voltage ADC driver

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1422609003.11083.13.camel@mm-sol.com>
Date:	Fri, 30 Jan 2015 11:10:03 +0200
From:	"Ivan T. Ivanov" <iivanov@...sol.com>
To:	Jonathan Cameron <jic23@...nel.org>
Cc:	Hartmut Knaack <knaack.h@....de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald <pmeerw@...erw.net>,
	Stanimir Varbanov <svarbanov@...sol.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v5 2/2] iio: vadc: Qualcomm SPMI PMIC voltage ADC driver


On Wed, 2015-01-28 at 18:46 +0000, Jonathan Cameron wrote:
> On 20/01/15 10:15, Ivan T. Ivanov wrote:
> > From: Stanimir Varbanov <svarbanov@...sol.com>
> > 
> > The voltage ADC is peripheral of Qualcomm SPMI PMIC chips. It has
> > 15bits resolution and register space inside PMIC accessible across
> > SPMI bus.
> > 
> > The vadc driver registers itself through IIO interface.
> > 
> > Signed-off-by: Stanimir Varbanov <svarbanov@...sol.com>
> > Signed-off-by: Ivan T. Ivanov <iivanov@...sol.com>
> One minor comment inline.  Looks good to me.
> Applied to the togreg branch of iio.git - initially pushed out as testing.
> 
> Glad to have this one out of the pending list ;)

Thank you.

> 
> > +
> > +       irq_eoc = platform_get_irq(pdev, 0);
> > +       if (irq_eoc < 0) {
> > +               if (irq_eoc == -EPROBE_DEFER || irq_eoc == -EINVAL)
> > +                       return irq_eoc;
> This does feel a little backwards.  I'd normally expect to see those
> errors that indicate one is not specified tested against, rather than
> trying to guess all the reasons it might fail otherwise....
> 
> This way round strikes me as probably more fragile as additional errors
> may turn up in that function over time..
> 

Agree, would it be better if driver just check for EPROBE_DEFER
and treat all other error codes as "no interrupt defined"? 
I could send followup patch if you like.

Regards,
Ivan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/