linux-kernel - Re: [PATCH V3 5/5] regulator: max77620: add regulator driver for max77620/max20024

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]

Message-id: <569DE510.8090606@samsung.com>
Date:	Tue, 19 Jan 2016 16:26:08 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Laxman Dewangan <ldewangan@...dia.com>, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	linus.walleij@...aro.org, gnurou@...il.com, lee.jones@...aro.org,
	broonie@...nel.org, a.zummo@...ertech.it,
	alexandre.belloni@...e-electrons.com
Cc:	lgirdwood@...il.com, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	rtc-linux@...glegroups.com, swarren@...dia.com, treding@...dia.com,
	Mallikarjun Kasoju <mkasoju@...dia.com>
Subject: Re: [PATCH V3 5/5] regulator: max77620: add regulator driver for
 max77620/max20024

On 19.01.2016 16:04, Laxman Dewangan wrote:
> Thanks for review.
> Here is my view on the some of the review comment.
> 
> On Tuesday 19 January 2016 10:59 AM, Krzysztof Kozlowski wrote:
>> On 14.01.2016 20:32, Laxman Dewangan wrote:
> 
>> +    return ret;
>> +}
>> +
>> +static int max77620_init_pmic(struct max77620_regulator *pmic, int id)
>> +{
>> This function seems to be used only from max77620_of_parse_cb(). I would
>> find easier to read if this was located before definition of
>> max77620_of_parse_cb(). Can you move it (or you had other idea of
>> placing algorithm)?
> 
> I wanted to keep all local function on top which is used on this file
> and not the regulator ops.
> Then implement regulator ops and then probe.
> Let me see if I can do anything here.

Ah, OK then. That kind of order makes sense as well.

> 
>>
>>> +             pmic->enable_power_mode[id]) {
>>> +            ret = max77620_regulator_set_power_mode(
>>> +                    pmic, pmic->enable_power_mode[id], id);
>> The 'pmic' argument should be after opening parenthesis, not at new line.
> 
> This is done for indenting alignment. I am using checkpatch --strict
> option and for this the next line should be on same column of first
> charcter after opening parenthesis.
> To avoid this error, if we want to re-align the indenting for next line
> then left the line empty after "(".

But the next line is not aligned with the function call. So the 'strict'
is not followed and the code is less readable. Instead this should be
something like:

+			ret = max77620_regulator_set_power_mode(pmic
+					pmic->enable_power_mode[id],
					id);

You cannot align it with function call anyway (to many indentations and
too long name of function).

> 
> +
> +static int __init max77620_regulator_init(void)
> +{
> +    return platform_driver_register(&max77620_regulator_driver);
> +}
> +subsys_initcall(max77620_regulator_init);
> +
> 
>> Does it have to be subsys_initcall? Any special requirements for
>> ordering the drivers? Probe deferring is encouraged instead.
>>
>>
> 
> 
> This is to make sure th regulators are ready before other driver get
> probed. This is basic need of some of driver and hence subsys_initcall.
> I will move to module_init() as some of other PMIC driver (as3722) is in
> the module init and used in tegra platform so not seeing much issue on
> this.

The other driver should support deferred probe and then the problem is
somehow solved. There are some rare cases when this does not work yet
but then please describe exactly which driver cannot work with it.

For example max77802 regulator works well.

Best regards,
Krzysztof