[PATCH 1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()

[PATCH 1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()

[Christophe JAILLET]

If an error occurs after the clk_prepare_enable() call, a corresponding
clk_disable_unprepare() should be called.

Simplify code and switch to devm_clk_get_enabled() to fix it.

Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This changes the order of the clean-ups if the .remove() function is called
but it looks fine to me.
---
 drivers/mfd/qcom_rpm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
index 71bc34b74bc9..ea5eb94427c4 100644
--- a/drivers/mfd/qcom_rpm.c
+++ b/drivers/mfd/qcom_rpm.c
@@ -547,7 +547,7 @@ static int qcom_rpm_probe(struct platform_device *pdev)
 	init_completion(&rpm->ack);
 
 	/* Enable message RAM clock */
-	rpm->ramclk = devm_clk_get(&pdev->dev, "ram");
+	rpm->ramclk = devm_clk_get_enabled(&pdev->dev, "ram");
 	if (IS_ERR(rpm->ramclk)) {
 		ret = PTR_ERR(rpm->ramclk);
 		if (ret == -EPROBE_DEFER)
@@ -558,7 +558,6 @@ static int qcom_rpm_probe(struct platform_device *pdev)
 		 */
 		rpm->ramclk = NULL;
 	}
-	clk_prepare_enable(rpm->ramclk); /* Accepts NULL */
 
 	irq_ack = platform_get_irq_byname(pdev, "ack");
 	if (irq_ack < 0)
@@ -681,7 +680,6 @@ static int qcom_rpm_remove(struct platform_device *pdev)
 	struct qcom_rpm *rpm = dev_get_drvdata(&pdev->dev);
 
 	of_platform_depopulate(&pdev->dev);
-	clk_disable_unprepare(rpm->ramclk);
 
 	return 0;
 }
-- 
2.34.1

[PATCH 2/2] mfd: qcom_rpm: Use devm_of_platform_populate() to simplify code

[Christophe JAILLET]

Use devm_of_platform_populate() instead of hand-writing it.
This simplifies the code.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This changes the order of the clean-ups if the .remove() function is called
but it looks fine to me.
---
 drivers/mfd/qcom_rpm.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
index ea5eb94427c4..8fea0e511550 100644
--- a/drivers/mfd/qcom_rpm.c
+++ b/drivers/mfd/qcom_rpm.c
@@ -672,21 +672,11 @@ static int qcom_rpm_probe(struct platform_device *pdev)
 	if (ret)
 		dev_warn(&pdev->dev, "failed to mark wakeup irq as wakeup\n");
 
-	return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
-}
-
-static int qcom_rpm_remove(struct platform_device *pdev)
-{
-	struct qcom_rpm *rpm = dev_get_drvdata(&pdev->dev);
-
-	of_platform_depopulate(&pdev->dev);
-
-	return 0;
+	return devm_of_platform_populate(&pdev->dev);
 }
 
 static struct platform_driver qcom_rpm_driver = {
 	.probe = qcom_rpm_probe,
-	.remove = qcom_rpm_remove,
 	.driver  = {
 		.name  = "qcom_rpm",
 		.of_match_table = qcom_rpm_of_match,
-- 
2.34.1

[PATCH 1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()

[Christophe JAILLET]

If an error occurs after the clk_prepare_enable() call, a corresponding
clk_disable_unprepare() should be called.

Simplify code and switch to devm_clk_get_enabled() to fix it.

Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This changes the order of the clean-ups if the .remove() function is called
but it looks fine to me.
---
 drivers/mfd/qcom_rpm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
index 71bc34b74bc9..ea5eb94427c4 100644
--- a/drivers/mfd/qcom_rpm.c
+++ b/drivers/mfd/qcom_rpm.c
@@ -547,7 +547,7 @@ static int qcom_rpm_probe(struct platform_device *pdev)
 	init_completion(&rpm->ack);
 
 	/* Enable message RAM clock */
-	rpm->ramclk = devm_clk_get(&pdev->dev, "ram");
+	rpm->ramclk = devm_clk_get_enabled(&pdev->dev, "ram");
 	if (IS_ERR(rpm->ramclk)) {
 		ret = PTR_ERR(rpm->ramclk);
 		if (ret == -EPROBE_DEFER)
@@ -558,7 +558,6 @@ static int qcom_rpm_probe(struct platform_device *pdev)
 		 */
 		rpm->ramclk = NULL;
 	}
-	clk_prepare_enable(rpm->ramclk); /* Accepts NULL */
 
 	irq_ack = platform_get_irq_byname(pdev, "ack");
 	if (irq_ack < 0)
@@ -681,7 +680,6 @@ static int qcom_rpm_remove(struct platform_device *pdev)
 	struct qcom_rpm *rpm = dev_get_drvdata(&pdev->dev);
 
 	of_platform_depopulate(&pdev->dev);
-	clk_disable_unprepare(rpm->ramclk);
 
 	return 0;
 }
-- 
2.34.1

[PATCH 1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()

[Christophe JAILLET]

If an error occurs after the clk_prepare_enable() call, a corresponding
clk_disable_unprepare() should be called.

Simplify code and switch to devm_clk_get_enabled() to fix it.

Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This changes the order of the clean-ups if the .remove() function is called
but it looks fine to me.
---
 drivers/mfd/qcom_rpm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
index 71bc34b74bc9..ea5eb94427c4 100644
--- a/drivers/mfd/qcom_rpm.c
+++ b/drivers/mfd/qcom_rpm.c
@@ -547,7 +547,7 @@ static int qcom_rpm_probe(struct platform_device *pdev)
 	init_completion(&rpm->ack);
 
 	/* Enable message RAM clock */
-	rpm->ramclk = devm_clk_get(&pdev->dev, "ram");
+	rpm->ramclk = devm_clk_get_enabled(&pdev->dev, "ram");
 	if (IS_ERR(rpm->ramclk)) {
 		ret = PTR_ERR(rpm->ramclk);
 		if (ret == -EPROBE_DEFER)
@@ -558,7 +558,6 @@ static int qcom_rpm_probe(struct platform_device *pdev)
 		 */
 		rpm->ramclk = NULL;
 	}
-	clk_prepare_enable(rpm->ramclk); /* Accepts NULL */
 
 	irq_ack = platform_get_irq_byname(pdev, "ack");
 	if (irq_ack < 0)
@@ -681,7 +680,6 @@ static int qcom_rpm_remove(struct platform_device *pdev)
 	struct qcom_rpm *rpm = dev_get_drvdata(&pdev->dev);
 
 	of_platform_depopulate(&pdev->dev);
-	clk_disable_unprepare(rpm->ramclk);
 
 	return 0;
 }
-- 
2.34.1

[PATCH] cpufreq: tegra186: Use flexible array to simplify memory allocation

[Christophe JAILLET]

Use flexible array to simplify memory allocation.
It saves some memory, avoids an indirection when reading the 'clusters'
array and removes some LoC.


Detailed explanation:
====================
Knowing that:
  - each devm_ allocation over-allocates 40 bytes for internal needs
  - Some rounding is done by the memory allocator on 8, 16, 32, 64, 96,
    128, 192, 256, 512, 1024, 2048, 4096, 8192 boundaries

and that:
  - sizeof(struct tegra186_cpufreq_data) = 24
  - sizeof(struct tegra186_cpufreq_cluster) = 16

Memory allocations in tegra186_cpufreq_probe() are:
  data:           (24 + 40) = 64 		      => 64 bytes
  data->clusters: (2 * 16 + 40) = 72     => 96 bytes
So a total of 160 bytes are allocated.
56 for the real need, 80 for internal uses and 24 are wasted.


If 'struct tegra186_cpufreq_data' is reordered so that 'clusters' is a
flexible array:
  - it saves one pointer in the structure
  - only one allocation is needed

So, only 96 bytes are allocated:
  16 + 2 * 16 + 40 = 88  => 96 bytes

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile tested only
---
 drivers/cpufreq/tegra186-cpufreq.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/cpufreq/tegra186-cpufreq.c b/drivers/cpufreq/tegra186-cpufreq.c
index 6c88827f4e62..f98f53bf1011 100644
--- a/drivers/cpufreq/tegra186-cpufreq.c
+++ b/drivers/cpufreq/tegra186-cpufreq.c
@@ -65,8 +65,8 @@ struct tegra186_cpufreq_cluster {
 
 struct tegra186_cpufreq_data {
 	void __iomem *regs;
-	struct tegra186_cpufreq_cluster *clusters;
 	const struct tegra186_cpufreq_cpu *cpus;
+	struct tegra186_cpufreq_cluster clusters[];
 };
 
 static int tegra186_cpufreq_init(struct cpufreq_policy *policy)
@@ -221,15 +221,12 @@ static int tegra186_cpufreq_probe(struct platform_device *pdev)
 	struct tegra_bpmp *bpmp;
 	unsigned int i = 0, err;
 
-	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	data = devm_kzalloc(&pdev->dev,
+			    struct_size(data, clusters, TEGRA186_NUM_CLUSTERS),
+			    GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
 
-	data->clusters = devm_kcalloc(&pdev->dev, TEGRA186_NUM_CLUSTERS,
-				      sizeof(*data->clusters), GFP_KERNEL);
-	if (!data->clusters)
-		return -ENOMEM;
-
 	data->cpus = tegra186_cpus;
 
 	bpmp = tegra_bpmp_get(&pdev->dev);
-- 
2.34.1

Re: [PATCH] cpufreq: tegra186: Use flexible array to simplify memory allocation

[Viresh Kumar]

On 20-11-22, 18:19, Christophe JAILLET wrote:
> Use flexible array to simplify memory allocation.
> It saves some memory, avoids an indirection when reading the 'clusters'
> array and removes some LoC.
> 
> 
> Detailed explanation:
> ====================
> Knowing that:
>   - each devm_ allocation over-allocates 40 bytes for internal needs
>   - Some rounding is done by the memory allocator on 8, 16, 32, 64, 96,
>     128, 192, 256, 512, 1024, 2048, 4096, 8192 boundaries
> 
> and that:
>   - sizeof(struct tegra186_cpufreq_data) = 24
>   - sizeof(struct tegra186_cpufreq_cluster) = 16
> 
> Memory allocations in tegra186_cpufreq_probe() are:
>   data:           (24 + 40) = 64 		      => 64 bytes
>   data->clusters: (2 * 16 + 40) = 72     => 96 bytes
> So a total of 160 bytes are allocated.
> 56 for the real need, 80 for internal uses and 24 are wasted.
> 
> 
> If 'struct tegra186_cpufreq_data' is reordered so that 'clusters' is a
> flexible array:
>   - it saves one pointer in the structure
>   - only one allocation is needed
> 
> So, only 96 bytes are allocated:
>   16 + 2 * 16 + 40 = 88  => 96 bytes
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---

Applied. Thanks.

-- 
viresh

Re: [PATCH 1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()

[Lee Jones]

On Sun, 20 Nov 2022, Christophe JAILLET wrote:

> If an error occurs after the clk_prepare_enable() call, a corresponding
> clk_disable_unprepare() should be called.
> 
> Simplify code and switch to devm_clk_get_enabled() to fix it.
> 
> Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This changes the order of the clean-ups if the .remove() function is called
> but it looks fine to me.
> ---
>  drivers/mfd/qcom_rpm.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Something funny going on here.

I received 3 identical versions of the same patch.

-- 
Lee Jones [李琼斯]

Re: [PATCH 1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()

[Lee Jones]

On Sun, 20 Nov 2022, Christophe JAILLET wrote:

> If an error occurs after the clk_prepare_enable() call, a corresponding
> clk_disable_unprepare() should be called.
> 
> Simplify code and switch to devm_clk_get_enabled() to fix it.
> 
> Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This changes the order of the clean-ups if the .remove() function is called
> but it looks fine to me.
> ---
>  drivers/mfd/qcom_rpm.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]

Re: [PATCH 2/2] mfd: qcom_rpm: Use devm_of_platform_populate() to simplify code

[Lee Jones]

On Sun, 20 Nov 2022, Christophe JAILLET wrote:

> Use devm_of_platform_populate() instead of hand-writing it.
> This simplifies the code.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This changes the order of the clean-ups if the .remove() function is called
> but it looks fine to me.
> ---
>  drivers/mfd/qcom_rpm.c | 12 +-----------
>  1 file changed, 1 insertion(+), 11 deletions(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]

Re: [PATCH 1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()

[Christophe JAILLET]

Le 08/12/2022 à 13:30, Lee Jones a écrit :
> On Sun, 20 Nov 2022, Christophe JAILLET wrote:
> 
>> If an error occurs after the clk_prepare_enable() call, a corresponding
>> clk_disable_unprepare() should be called.
>>
>> Simplify code and switch to devm_clk_get_enabled() to fix it.
>>
>> Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> This changes the order of the clean-ups if the .remove() function is called
>> but it looks fine to me.
>> ---
>>   drivers/mfd/qcom_rpm.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> Something funny going on here.
> 
> I received 3 identical versions of the same patch.
> 

Yes, was my fault.

Sorry for the inconvenience.

CJ