linux-kernel - Re: [PATCH 2/3] regulator: MAX77686: Add Maxim 77686 regulator 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] [thread-next>] [day] [month] [year] [list]

Message-id: <4FB9EFBB.20306@samsung.com>
Date:	Mon, 21 May 2012 16:33:15 +0900
From:	jonghwa3.lee@...sung.com
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-kernel@...r.kernel.org,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Samuel Oritz <sameo@...ux.intel.com>,
	Liam Girdwood <trg@...com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	MyungJoo Ham <myungjoo.ham@...sung.com>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Chiwoong Byun <woong.byun@...sung.com>
Subject: Re: [PATCH 2/3] regulator: MAX77686: Add Maxim 77686 regulator driver

On 2012년 05월 21일 00:56, Mark Brown wrote:
Hi, Mark.

> On Fri, May 18, 2012 at 06:32:18PM +0900, Jonghwa Lee wrote:
> 
>> Add driver for support max77686 regulator.
>> MAX77686 provides LDOs[1~26] and BUCKs[1~9]. It support to set or get the
>> volatege of regulator on max77686 chip with using regmap.
> 
> Looks mostly good, a few things below but they're all pretty
> minor/straghtforward.
> 
>> +/* LDO3 ~ 5, 9 ~ 14, 16 ~ 26 (uV) */
>> +static const struct voltage_map_desc ldo_voltage_map_desc = {
>> +	.min = 800000,	.max = 3950000,	.step = 50000,	.n_bits = 6,
>> +};
> 
> Should convert all these to use regulator_map_voltage_linear() and
> regulator_{get,set}_voltage_vsel().
> 
>> +	ret = regmap_read(max77686->iodev->regmap, reg, &val);
>> +
>> +	if (ret)
>> +		return ret;
> 
>> +	printk(PMIC_DEBUG "id=%d, ret=%d, val=%x, mask=%x, pattern=%x\n",
>> +		 rdev_get_id(rdev), (val & mask) == pattern,
>> +		 val, mask, pattern);
> 
> dev_dbg() or just remove this (and similarly for the other similar logs).
> 
>> +	{
>> +		.name	= "EN32KHz AP",
>> +		.id	= MAX77686_EN32KHZ_AP,
>> +		.ops	= &max77686_fixedvolt_ops,
>> +		.type	= REGULATOR_VOLTAGE,
>> +		.owner	= THIS_MODULE,
>> +	}, {
>> +		.name	= "EN32KHz CP",
>> +		.id	= MAX77686_EN32KHZ_CP,
>> +		.ops	= &max77686_fixedvolt_ops,
>> +		.type	= REGULATOR_VOLTAGE,
>> +		.owner	= THIS_MODULE,
>> +	}, {
>> +		.name	= "EN32KHz PMIC",
>> +		.id	= MAX77686_P32KH,
>> +		.ops	= &max77686_fixedvolt_ops,
>> +		.type	= REGULATOR_VOLTAGE,
>> +		.owner	= THIS_MODULE,
>> +	},
> 
> These should be managed via the clock API now we have one.

>

I already updated all your comments except only this one. Could you
explain more details?


>> +	if (!pdata)
>> +		dev_err(pdev->dev.parent, "No platform init data supplied.\n");
> 
> Should be able to carry on without this and register the regulators to
> allow for diagnostics and powering off unused regulators when we have
> full constraints.
> 
>> +	size = sizeof(struct regulator_dev *) * MAX77686_REGULATORS;
>> +	max77686->rdev = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
>> +	if (!max77686->rdev) {
>> +		devm_kfree(&pdev->dev, max77686);
> 
> Shouldn't need to devm_kfree(), the major point is that this will happen
> automatically.


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