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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
> ---
Applied. Thanks.
--
viresh
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 <[email protected]>
> ---
> 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 [李琼斯]
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 <[email protected]>
> ---
> 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 [李琼斯]
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 <[email protected]>
>> ---
>> 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