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: <CAKew6eUqqC-jSRoY1e4Q=JnLekuA_geGcCjQr4=6g86nf3LfDA@mail.gmail.com>
Date:	Mon, 21 May 2012 13:27:26 +0530
From:	Yadwinder Singh Brar <yadi.brar01@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, Liam Girdwood <lrg@...com>,
	Yadwinder Singh Brar <yadi.brar@...sung.com>
Subject: Re: [PATCH v2 2/2] regulator: Add support for MAX77686.

Hi Mark,

On Sun, May 20, 2012 at 3:30 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Thu, May 17, 2012 at 07:09:27PM +0530, Yadwinder Singh Brar wrote:
>
> Looks mostly good.  A couple of fairly small things:
>
>> +static int max77686_get_voltage_sel(struct regulator_dev *rdev)
>> +{
>
> This looks like it should be regulator_get_voltage_sel_regmap().
>
>> +static int max77686_set_voltage_sel(struct regulator_dev *rdev,
>> +                                     unsigned sel)
>> +{
>
> This looks like it should be regulator_set_voltage_sel_regmap().
>

Yes, We can use  regulator_set_voltage_sel_regmap(), I will replace it.

>> +     max77686->ramp_delay = pdata->ramp_delay - 1;
>> +     max77686_update_reg(i2c, MAX77686_REG_BUCK2CTRL1,
>> +             RAMP_VALUE, RAMP_MASK);
>> +     max77686_update_reg(i2c, MAX77686_REG_BUCK3CTRL1,
>> +             RAMP_VALUE, RAMP_MASK);
>> +     max77686_update_reg(i2c, MAX77686_REG_BUCK4CTRL1,
>> +             RAMP_VALUE, RAMP_MASK);
>
> This code is unclear because RAMP_VALUE looks like a constant that has
> nothing to do with ramp_delay when in fact it's actually this:
>
>> +#define RAMP_VALUE (max77686->ramp_delay << 6)
>
> which isn't constant - this is why I queried this last time.  Just
> remove the define and write this out directly.  The way the code is
> written at the minute it looks like ramp_delay is just stored and not
> referred to unless you go searching around the rest of the driver.

Ok, I will remove it.

Thanks,
Yadwinder.
--
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