linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chanwoo Choi <cw00.choi@samsung.com>
To: "Artur Świgoń" <a.swigon@samsung.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-pm@vger.kernel.org
Cc: myungjoo.ham@samsung.com, kyungmin.park@samsung.com,
	kgene@kernel.org, krzk@kernel.org, b.zolnierkie@samsung.com,
	m.szyprowski@samsung.com, inki.dae@samsung.com,
	sw0312.kim@samsung.com, k.konieczny@samsung.com,
	leonard.crestez@nxp.com, rostedt@goodmis.org
Subject: Re: [PATCH v3 4/4] devfreq: exynos-bus: Clean up code
Date: Thu, 12 Dec 2019 10:52:29 +0900	[thread overview]
Message-ID: <852f742c-1f7b-0981-4409-d2d50ee86301@samsung.com> (raw)
In-Reply-To: <32cd66aca8d9435bed69732771a7716db883f5a0.camel@samsung.com>

Hi,

On 12/11/19 11:39 PM, Artur Świgoń wrote:
> Hi,
> 
> On Tue, 2019-12-10 at 13:20 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> This patch contains the clean-up code related to 'goto' style.
>> Please merge the the clean-up code of 'goto' to one patch with patch3/patch4.
>> - patch3 related to 'goto' clean-up code
>> - patch4 related to remaining clean-up code. 
>>
>> And I added the comment below. Please check them.
> 
> OK, I can merge these patches. Please also see my comments below regarding
> the issues you highlighted: kzalloc vs. kcalloc, fitting in 80 columns and
> changing repeated expressions to variables.
> 
>>
>> On 12/9/19 7:49 PM, Artur Świgoń wrote:
>>> This patch adds minor improvements to the exynos-bus driver, including
>>> cleaning up header includes, variables, and return paths.
>>>
>>> Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
>>> ---
>>>  drivers/devfreq/exynos-bus.c | 56 +++++++++++++++---------------------
>>>  1 file changed, 23 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 0b557df63666..3eb6a043284a 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -15,11 +15,10 @@
>>>  #include <linux/device.h>
>>>  #include <linux/export.h>
>>>  #include <linux/module.h>
>>> -#include <linux/of_device.h>
>>> +#include <linux/of.h>
>>>  #include <linux/pm_opp.h>
>>>  #include <linux/platform_device.h>
>>>  #include <linux/regulator/consumer.h>
>>> -#include <linux/slab.h>
>>>  
>>>  #define DEFAULT_SATURATION_RATIO	40
>>>  
>>> @@ -178,7 +177,7 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
>>>  	struct device *dev = bus->dev;
>>>  	struct opp_table *opp_table;
>>>  	const char *vdd = "vdd";
>>> -	int i, ret, count, size;
>>> +	int i, ret, count;
>>>  
>>>  	opp_table = dev_pm_opp_set_regulators(dev, &vdd, 1);
>>>  	if (IS_ERR(opp_table)) {
>>> @@ -201,8 +200,7 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
>>>  	}
>>>  	bus->edev_count = count;
>>>  
>>> -	size = sizeof(*bus->edev) * count;
>>> -	bus->edev = devm_kzalloc(dev, size, GFP_KERNEL);
>>> +	bus->edev = devm_kcalloc(dev, count, sizeof(*bus->edev), GFP_KERNEL);
>>
>> ditto.
>> It depends on personal style. Don't change it because we cannot
>> modify them at the all device driver. If is not wrong,
>> just keep the original code.
> 
> Of course, this is a matter of style, but I think that Coccinelle reports
> such code, compare with e.g., https://protect2.fireeye.com/url?k=9d96be53-c05a72f6-9d97351c-0cc47a30d446-615469bafe78ddb7&u=https://lkml.org/lkml/2019/5/8/927

OK. If it is result from Coccinelle reports, you need to add
the 'Coccinelle reports' in the patch description.

When you send v2, you can contain this clean-up
with 'Coccinelle reports'. If there are reasonable reason,
always I'll agree.

> 
> Anyway, I can drop it since the purpose of this patchset as a whole was to
> untangle all the goto's and I agree this is kind of unrelated.
> 
>>
>>>  	if (!bus->edev) {
>>>  		ret = -ENOMEM;
>>>  		goto err_regulator;
>>> @@ -301,10 +299,9 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
>>>  	profile->exit = exynos_bus_exit;
>>>  
>>>  	ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
>>> -	if (!ondemand_data) {
>>> -		ret = -ENOMEM;
>>> -		goto err;
>>> -	}
>>> +	if (!ondemand_data)
>>> +		return -ENOMEM;
>>> +
>>>  	ondemand_data->upthreshold = 40;
>>>  	ondemand_data->downdifferential = 5;
>>>  
>>> @@ -314,15 +311,14 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
>>>  						ondemand_data);
>>>  	if (IS_ERR(bus->devfreq)) {
>>>  		dev_err(dev, "failed to add devfreq device\n");
>>> -		ret = PTR_ERR(bus->devfreq);
>>> -		goto err;
>>> +		return PTR_ERR(bus->devfreq);
>>>  	}
>>>  
>>>  	/* Register opp_notifier to catch the change of OPP  */
>>>  	ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
>>>  	if (ret < 0) {
>>>  		dev_err(dev, "failed to register opp notifier\n");
>>> -		goto err;
>>> +		return ret;
>>>  	}
>>>  
>>>  	/*
>>> @@ -332,17 +328,16 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
>>>  	ret = exynos_bus_enable_edev(bus);
>>>  	if (ret < 0) {
>>>  		dev_err(dev, "failed to enable devfreq-event devices\n");
>>> -		goto err;
>>> +		return ret;
>>>  	}
>>>  
>>>  	ret = exynos_bus_set_event(bus);
>>>  	if (ret < 0) {
>>>  		dev_err(dev, "failed to set event to devfreq-event devices\n");
>>> -		goto err;
>>> +		return ret;
>>>  	}
>>>  
>>> -err:
>>> -	return ret;
>>> +	return 0;
>>>  }
>>>  
>>>  static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
>>> @@ -351,7 +346,6 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
>>>  	struct device *dev = bus->dev;
>>>  	struct devfreq_passive_data *passive_data;
>>>  	struct devfreq *parent_devfreq;
>>> -	int ret = 0;
>>>  
>>>  	/* Initialize the struct profile and governor data for passive device */
>>>  	profile->target = exynos_bus_target;
>>> @@ -359,30 +353,26 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
>>>  
>>>  	/* Get the instance of parent devfreq device */
>>>  	parent_devfreq = devfreq_get_devfreq_by_phandle(dev, 0);
>>> -	if (IS_ERR(parent_devfreq)) {
>>> -		ret = -EPROBE_DEFER;
>>> -		goto err;
>>> -	}
>>> +	if (IS_ERR(parent_devfreq))
>>> +		return -EPROBE_DEFER;
>>>  
>>>  	passive_data = devm_kzalloc(dev, sizeof(*passive_data), GFP_KERNEL);
>>> -	if (!passive_data) {
>>> -		ret = -ENOMEM;
>>> -		goto err;
>>> -	}
>>> +	if (!passive_data)
>>> +		return -ENOMEM;
>>> +
>>>  	passive_data->parent = parent_devfreq;
>>>  
>>>  	/* Add devfreq device for exynos bus with passive governor */
>>> -	bus->devfreq = devm_devfreq_add_device(dev, profile, DEVFREQ_GOV_PASSIVE,
>>> +	bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> +						DEVFREQ_GOV_PASSIVE,
>>
>> It is not clean-up. It depends on personal style. Don't change it
>> because we cannot modify them at the all device driver. If is not wrong,
>> just keep the original code.
> 
> I wanted to make the code fit in 80 columns (issue reported by
> scripts/checkpatch.pl). For the reasons stated in my previous comment,
> I am happy to drop this change if you don't like it.

ditto. Please mention the reason from checkpatch.pl on patch4 description.

> 
>>
>>>  						passive_data);
>>>  	if (IS_ERR(bus->devfreq)) {
>>>  		dev_err(dev,
>>>  			"failed to add devfreq dev with passive governor\n");
>>> -		ret = PTR_ERR(bus->devfreq);
>>> -		goto err;
>>> +		return PTR_ERR(bus->devfreq);
>>>  	}
>>>  
>>> -err:
>>> -	return ret;
>>> +	return 0;
>>>  }
>>>  
>>>  static int exynos_bus_probe(struct platform_device *pdev)
>>> @@ -400,18 +390,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>>  		return -EINVAL;
>>>  	}
>>>  
>>> -	bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
>>> +	bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
>>
>> ditto.
>> It depends on personal style. Don't change it because we cannot
>> modify them at the all device driver. If is not wrong,
>> just keep the original code.
> 
> Please note that there exists this variable in exynos_bus_probe():
> 
> struct device *dev = &pdev->dev;
> 
> but the expression '&pdev->dev' is reused twice more ('dev' itself
> is also used). Is there any reason for such inconsistency?

Frankly, it is not any reason. Mabye, we could find same thing like thin
in the linux kernel. As you commented, we better to keep the only one
style without any specific reason.

But, in my experience, these minor issues will happen continuously
in linux kernel. I think tha it is not much valuable to change
the these minor issues except for result rom checkpatch.pl/Coccinelle script.
I think that sometimes it make the difficult to keep the patch history.

If there are any special reason, In my case, just keep the origin code
for the patch history.

> 
>>
>>>  	if (!bus)
>>>  		return -ENOMEM;
>>>  	mutex_init(&bus->lock);
>>> -	bus->dev = &pdev->dev;
>>> +	bus->dev = dev;
>>
>> ditto.
>> It depends on personal style. Don't change it because we cannot
>> modify them at the all device driver. If is not wrong,
>> just keep the original code.
> 
> (See above)
> 
>>
>>>  	platform_set_drvdata(pdev, bus);
>>>  
>>>  	profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
>>>  	if (!profile)
>>>  		return -ENOMEM;
>>>  
>>> -	node = of_parse_phandle(dev->of_node, "devfreq", 0);
>>> +	node = of_parse_phandle(np, "devfreq", 0);
>>>  	if (node) {
>>>  		of_node_put(node);
>>>  		passive = true;
>>>
>>
> 
> Best regards,
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

      reply	other threads:[~2019-12-12  1:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20191209105030eucas1p11e28297118da5a1d9f3a8c955584a4bf@eucas1p1.samsung.com>
2019-12-09 10:48 ` [PATCH v3 0/4] devfreq: Clean up exynos-bus driver Artur Świgoń
     [not found]   ` <CGME20191209105031eucas1p137c3c5b0046570453e1ebed2dcd88277@eucas1p1.samsung.com>
2019-12-09 10:48     ` [PATCH v3 1/4] devfreq: exynos-bus: Extract exynos_bus_profile_init() Artur Świgoń
2019-12-10  4:20       ` Chanwoo Choi
     [not found]   ` <CGME20191209105032eucas1p13fa6c46a1e80cdda68ab4bac3e008b8f@eucas1p1.samsung.com>
2019-12-09 10:49     ` [PATCH v3 2/4] devfreq: exynos-bus: Extract exynos_bus_profile_init_passive() Artur Świgoń
2019-12-10  4:20       ` Chanwoo Choi
     [not found]   ` <CGME20191209105033eucas1p21ee8064e1d6917b403c06ee59a97421d@eucas1p2.samsung.com>
2019-12-09 10:49     ` [PATCH v3 3/4] devfreq: exynos-bus: Change goto-based logic to if-else logic Artur Świgoń
     [not found]   ` <CGME20191209105034eucas1p277be9a40363fec76b4241d28e71e40d2@eucas1p2.samsung.com>
2019-12-09 10:49     ` [PATCH v3 4/4] devfreq: exynos-bus: Clean up code Artur Świgoń
2019-12-10  4:20       ` Chanwoo Choi
2019-12-11 14:39         ` Artur Świgoń
2019-12-12  1:52           ` Chanwoo Choi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=852f742c-1f7b-0981-4409-d2d50ee86301@samsung.com \
    --to=cw00.choi@samsung.com \
    --cc=a.swigon@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=inki.dae@samsung.com \
    --cc=k.konieczny@samsung.com \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=leonard.crestez@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=rostedt@goodmis.org \
    --cc=sw0312.kim@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).