mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Re: [PATCH v1 2/3] cpufreq: mediatek: fix KP caused by handler usage after regulator_put/clk_put
       [not found] ` <20230310051750.4745-3-jia-wei.chang@mediatek.com>
@ 2023-03-10  9:11   ` Dan Carpenter
  2023-03-10  9:30   ` AngeloGioacchino Del Regno
  1 sibling, 0 replies; 4+ messages in thread
From: Dan Carpenter @ 2023-03-10  9:11 UTC (permalink / raw)
  To: jia-wei.chang
  Cc: Rafael J . Wysocki, Viresh Kumar, Matthias Brugger,
	AngeloGioacchino Del Regno, Kevin Hilman, Rex-BC Chen,
	linux-arm-kernel, linux-mediatek, linux-kernel,
	Project_Global_Chrome_Upstream_Group, hsinyi, Nick

On Fri, Mar 10, 2023 at 01:17:49PM +0800, jia-wei.chang wrote:
> From: "Jia-Wei Chang" <jia-wei.chang@mediatek.com>
> 
> Any kind of failure in mtk_cpu_dvfs_info_init() will lead to calling
> regulator_put() or clk_put() and the KP will occur since the regulator/clk
> handlers are used after released in mtk_cpu_dvfs_info_release().
> 

This patch is harmless but it's not required.

If the mtk_cpu_dvfs_info_init() function is not able to complete
successfully then it cleans up all the partial allocations.  If it is
able to allocate everything successfully, then the caller, which is
mtk_cpufreq_probe(), adds it to the &dvfs_info_list.  If the
probe() function is not able to complete successfully it releases
everything in the &dvfs_info_list.

In this way, mtk_cpu_dvfs_info_init() never frees anything which has
not been allocated and it never frees anything which has already been
freed.  All the IS_ERR() checks in mtk_cpu_dvfs_info_release() can be
removed.

In reviewing this code, I can't help but notice that mtk_cpu_dvfs_info_init()
is buggy.  Please read my blog on error handling:
https://staticthinking.wordpress.com/2022/04/28/free-the-last-thing-style/

drivers/cpufreq/mediatek-cpufreq.c
   411          info->cpu_clk = clk_get(cpu_dev, "cpu");
   412          if (IS_ERR(info->cpu_clk)) {
   413                  ret = PTR_ERR(info->cpu_clk);
   414                  return dev_err_probe(cpu_dev, ret,
                        ^^^^^^^^^^^^^^^^^^^^
Here we have a direct return which means there is nothing to free.
Okay.

   415                                       "cpu%d: failed to get cpu clk\n", cpu);
   416          }
   417  
   418          info->inter_clk = clk_get(cpu_dev, "intermediate");
   419          if (IS_ERR(info->inter_clk)) {
   420                  ret = PTR_ERR(info->inter_clk);
   421                  dev_err_probe(cpu_dev, ret,
   422                                "cpu%d: failed to get intermediate clk\n", cpu);
   423                  goto out_free_resources;
                        ^^^^^^^^^^^^^^^^^^^^^^^
The last thing we successfully allocated was ->cpu_clk so ideally the
goto would be something like "goto put_cpu_clk;".  Let's assume this
clk_get() fails.


   424          }
   425  
   426          info->proc_reg = regulator_get_optional(cpu_dev, "proc");
                ^^^^^^^^^^^^^^
Note that this is where ->proc_reg is allocated.  Prior to that point
it is NULL because it's allocated with kzalloc().

   427          if (IS_ERR(info->proc_reg)) {
   428                  ret = PTR_ERR(info->proc_reg);
   429                  dev_err_probe(cpu_dev, ret,
   430                                "cpu%d: failed to get proc regulator\n", cpu);
   431                  goto out_free_resources;
   432          }

[ snip ]

   536  out_free_resources:
   537          if (regulator_is_enabled(info->proc_reg))
                                         ^^^^^^^^^^^^^^
Oops!  This is a NULL dereference because ->proc_reg wasn't allocated
yet.

   538                  regulator_disable(info->proc_reg);
   539          if (info->sram_reg && regulator_is_enabled(info->sram_reg))
   540                  regulator_disable(info->sram_reg);
   541  
   542          if (!IS_ERR(info->proc_reg))
   543                  regulator_put(info->proc_reg);
   544          if (!IS_ERR(info->sram_reg))
   545                  regulator_put(info->sram_reg);
   546          if (!IS_ERR(info->cpu_clk))
   547                  clk_put(info->cpu_clk);
   548          if (!IS_ERR(info->inter_clk))
   549                  clk_put(info->inter_clk);
   550  
   551          return ret;
   552  }

It would be safer and more readable to have:

err_put_inter_clk:
	clk_put(info->inter_clk);
err_put_cpu_clk:
	clk_put(info->cpu_clk);

etc.

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v1 2/3] cpufreq: mediatek: fix KP caused by handler usage after regulator_put/clk_put
       [not found] ` <20230310051750.4745-3-jia-wei.chang@mediatek.com>
  2023-03-10  9:11   ` [PATCH v1 2/3] cpufreq: mediatek: fix KP caused by handler usage after regulator_put/clk_put Dan Carpenter
@ 2023-03-10  9:30   ` AngeloGioacchino Del Regno
  1 sibling, 0 replies; 4+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-03-10  9:30 UTC (permalink / raw)
  To: jia-wei.chang, Rafael J . Wysocki, Viresh Kumar,
	Matthias Brugger, Kevin Hilman, Rex-BC Chen
  Cc: linux-arm-kernel, linux-mediatek, linux-kernel,
	Project_Global_Chrome_Upstream_Group, hsinyi, Nick,
	Dan Carpenter

Il 10/03/23 06:17, jia-wei.chang ha scritto:
> From: "Jia-Wei Chang" <jia-wei.chang@mediatek.com>
> 
> Any kind of failure in mtk_cpu_dvfs_info_init() will lead to calling
> regulator_put() or clk_put() and the KP will occur since the regulator/clk
> handlers are used after released in mtk_cpu_dvfs_info_release().
> 
> To prevent the usage after regulator_put()/clk_put(), the regulator/clk
> handlers are reassigned to NULL value for validation check afterwards.
> 
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Fixes: 4b9ceb757bbb ("cpufreq: mediatek: Enable clocks and regulators")
> Reported-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Link: https://lore.kernel.org/linux-arm-kernel/20220921071913.p7kwsjnnuad2jgvk@vireshk-i7/T/

Actually, it's not just Reported-by, but also please add:
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>


Anyway, apart from that:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v1 1/3] cpufreq: mediatek: fix passing zero to 'PTR_ERR'
       [not found] ` <20230310051750.4745-2-jia-wei.chang@mediatek.com>
@ 2023-03-10  9:30   ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 4+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-03-10  9:30 UTC (permalink / raw)
  To: jia-wei.chang, Rafael J . Wysocki, Viresh Kumar,
	Matthias Brugger, Kevin Hilman, Rex-BC Chen
  Cc: linux-arm-kernel, linux-mediatek, linux-kernel,
	Project_Global_Chrome_Upstream_Group, hsinyi, Nick,
	Dan Carpenter

Il 10/03/23 06:17, jia-wei.chang ha scritto:
> From: "Jia-Wei Chang" <jia-wei.chang@mediatek.com>
> 
> In order to prevent passing zero to 'PTR_ERR' in
> mtk_cpu_dvfs_info_init(), we fix the return value of of_get_cci() using
> error pointer by explicitly casting error number.
> 
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Fixes: 0daa47325bae ("cpufreq: mediatek: Link CCI device to CPU")
> Reported-by: Dan Carpenter <error27@gmail.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v1 3/3] cpufreq: mediatek: raise proc/sram max voltage for MT7622 and MT8516
       [not found] ` <20230310051750.4745-4-jia-wei.chang@mediatek.com>
@ 2023-03-10  9:32   ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 4+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-03-10  9:32 UTC (permalink / raw)
  To: jia-wei.chang, Rafael J . Wysocki, Viresh Kumar,
	Matthias Brugger, Kevin Hilman, Rex-BC Chen
  Cc: linux-arm-kernel, linux-mediatek, linux-kernel,
	Project_Global_Chrome_Upstream_Group, hsinyi, Nick,
	Dan Carpenter

Il 10/03/23 06:17, jia-wei.chang ha scritto:
> From: "Jia-Wei Chang" <jia-wei.chang@mediatek.com>
> 
> Since the upper boundary of proc/sram voltage of MT7622 and MT8516 are
> 1350 mV and 1300 mV respectively, both are greater than the value of
> MT2701 1150 mV, we fix it by adding the corresponding platform data and
> specify proc/sram_max_volt to support MT7622 and MT8516 individually.
> 
> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com>
> Fixes: ead858bd128d ("cpufreq: mediatek: Move voltage limits to platform data")
> Fixes: 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
> Reported-by: Nick Hainke <vincent@systemli.org>
> Link: https://lore.kernel.org/lkml/75216e0c-9d36-7ada-1507-1bb4a91a3326@systemli.org/T/

that's 2/3 my patch, 1/3 your patch.....
...in that case, send my patch as it is and add one more for MT8516.

Regards,
Angelo

> ---
>   drivers/cpufreq/mediatek-cpufreq.c | 26 ++++++++++++++++++++++----
>   1 file changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index cb8b76f9c2c3..f6824d4bf85d 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -707,6 +707,15 @@ static const struct mtk_cpufreq_platform_data mt2701_platform_data = {
>   	.ccifreq_supported = false,
>   };
>   
> +static const struct mtk_cpufreq_platform_data mt7622_platform_data = {
> +	.min_volt_shift = 100000,
> +	.max_volt_shift = 200000,
> +	.proc_max_volt = 1360000,
> +	.sram_min_volt = 0,
> +	.sram_max_volt = 1360000,
> +	.ccifreq_supported = false,
> +};
> +
>   static const struct mtk_cpufreq_platform_data mt8183_platform_data = {
>   	.min_volt_shift = 100000,
>   	.max_volt_shift = 200000,
> @@ -725,20 +734,29 @@ static const struct mtk_cpufreq_platform_data mt8186_platform_data = {
>   	.ccifreq_supported = true,
>   };
>   
> +static const struct mtk_cpufreq_platform_data mt8516_platform_data = {
> +	.min_volt_shift = 100000,
> +	.max_volt_shift = 200000,
> +	.proc_max_volt = 1310000,
> +	.sram_min_volt = 0,
> +	.sram_max_volt = 1310000,
> +	.ccifreq_supported = false,
> +};
> +
>   /* List of machines supported by this driver */
>   static const struct of_device_id mtk_cpufreq_machines[] __initconst = {
>   	{ .compatible = "mediatek,mt2701", .data = &mt2701_platform_data },
>   	{ .compatible = "mediatek,mt2712", .data = &mt2701_platform_data },
> -	{ .compatible = "mediatek,mt7622", .data = &mt2701_platform_data },
> -	{ .compatible = "mediatek,mt7623", .data = &mt2701_platform_data },
> -	{ .compatible = "mediatek,mt8167", .data = &mt2701_platform_data },
> +	{ .compatible = "mediatek,mt7622", .data = &mt7622_platform_data },
> +	{ .compatible = "mediatek,mt7623", .data = &mt7622_platform_data },
> +	{ .compatible = "mediatek,mt8167", .data = &mt8516_platform_data },
>   	{ .compatible = "mediatek,mt817x", .data = &mt2701_platform_data },
>   	{ .compatible = "mediatek,mt8173", .data = &mt2701_platform_data },
>   	{ .compatible = "mediatek,mt8176", .data = &mt2701_platform_data },
>   	{ .compatible = "mediatek,mt8183", .data = &mt8183_platform_data },
>   	{ .compatible = "mediatek,mt8186", .data = &mt8186_platform_data },
>   	{ .compatible = "mediatek,mt8365", .data = &mt2701_platform_data },
> -	{ .compatible = "mediatek,mt8516", .data = &mt2701_platform_data },
> +	{ .compatible = "mediatek,mt8516", .data = &mt8516_platform_data },
>   	{ }
>   };
>   MODULE_DEVICE_TABLE(of, mtk_cpufreq_machines);


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-03-10  9:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20230310051750.4745-1-jia-wei.chang@mediatek.com>
     [not found] ` <20230310051750.4745-3-jia-wei.chang@mediatek.com>
2023-03-10  9:11   ` [PATCH v1 2/3] cpufreq: mediatek: fix KP caused by handler usage after regulator_put/clk_put Dan Carpenter
2023-03-10  9:30   ` AngeloGioacchino Del Regno
     [not found] ` <20230310051750.4745-2-jia-wei.chang@mediatek.com>
2023-03-10  9:30   ` [PATCH v1 1/3] cpufreq: mediatek: fix passing zero to 'PTR_ERR' AngeloGioacchino Del Regno
     [not found] ` <20230310051750.4745-4-jia-wei.chang@mediatek.com>
2023-03-10  9:32   ` [PATCH v1 3/3] cpufreq: mediatek: raise proc/sram max voltage for MT7622 and MT8516 AngeloGioacchino Del Regno

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®