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: <DC88CAD03C0052499C1907B327FC63229EC576@DBDE04.ent.ti.com>
Date:	Tue, 18 Jun 2013 16:56:13 +0000
From:	"J, KEERTHY" <j-keerthy@...com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"broonie@...nel.org" <broonie@...nel.org>,
	"ldewangan@...dia.com" <ldewangan@...dia.com>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"swarren@...dia.com" <swarren@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"gg@...mlogic.co.uk" <gg@...mlogic.co.uk>
Subject: RE: [PATCH v2 2/4] MFD: Palmas: Add SMPS10_BOOST feature

Hi Stephen,


> -----Original Message-----
> From: Stephen Warren [mailto:swarren@...dotorg.org]
> Sent: Tuesday, June 18, 2013 9:23 PM
> To: J, KEERTHY
> Cc: linux-omap@...r.kernel.org; broonie@...nel.org;
> ldewangan@...dia.com; sameo@...ux.intel.com; grant.likely@...retlab.ca;
> swarren@...dia.com; linux-kernel@...r.kernel.org; linux-
> doc@...r.kernel.org; gg@...mlogic.co.uk
> Subject: Re: [PATCH v2 2/4] MFD: Palmas: Add SMPS10_BOOST feature
> 
> On 06/18/2013 04:03 AM, J Keerthy wrote:
> > The SMPS10 regulator is not presesnt in all the variants of the
> PALMAS
> > PMIC family. Hence adding a feature to distingush between them.
> 
> > diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
> 
> > +	match = of_match_device(of_match_ptr(of_palmas_match_tbl),
> > +&i2c->dev);
> > +
> > +	if (match) {
> > +		features = (unsigned int *)match->data;
> > +		palmas->features = *features;
> > +	} else {
> > +		return -ENODATA;
> > +	}
> 
> 
> I think it's more common to do the error-checking first. That way, the
> success-case code doesn't need an indent:
> 
> match = of_match...(...);
> if (!match)
>     return -ENODATA;
> 
> features = ...;
> palmas->features = *features;

Sure. I will fix this.

Regards,
Keerthy

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ