From: Eugen Hristev <eugen.hristev@collabora.com>
To: AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
matthias.bgg@gmail.com
Cc: krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
robh+dt@kernel.org, p.zabel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, kernel@collabora.com,
wenst@chromium.org
Subject: Re: [PATCH v3 09/20] soc: mediatek: mtk-svs: Move t-calibration-data retrieval to svs_probe()
Date: Wed, 22 Nov 2023 13:23:54 +0200 [thread overview]
Message-ID: <6018ec3f-d3e6-4fe0-b57f-9a7994f983a5@collabora.com> (raw)
In-Reply-To: <20231121125044.78642-10-angelogioacchino.delregno@collabora.com>
On 11/21/23 14:50, AngeloGioacchino Del Regno wrote:
> The t-calibration-data (SVS-Thermal calibration data) shall exist for
> all SoCs or SVS won't work anyway: move it to the common svs_probe()
> function and remove it from all of the per-SoC efuse_parsing() probe
> callbacks.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/soc/mediatek/mtk-svs.c | 32 ++++++--------------------------
> 1 file changed, 6 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
> index ab564d48092b..1042af2aee3f 100644
> --- a/drivers/soc/mediatek/mtk-svs.c
> +++ b/drivers/soc/mediatek/mtk-svs.c
> @@ -1884,11 +1884,6 @@ static bool svs_mt8195_efuse_parsing(struct svs_platform *svsp)
> svsb->vmax += svsb->dvt_fixed;
> }
>
> - ret = svs_get_efuse_data(svsp, "t-calibration-data",
> - &svsp->tefuse, &svsp->tefuse_max);
> - if (ret)
> - return false;
> -
Hello Angelo,
if you removed the code using `ret` in this patch, it makes sense to
also remove the variable here instead of doing it in patch 18.
It will avoid unused variable warnings for this patch.
> for (i = 0; i < svsp->tefuse_max; i++)
> if (svsp->tefuse[i] != 0)
> break;
> @@ -1949,11 +1944,6 @@ static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
> svsb->vmax += svsb->dvt_fixed;
> }
>
> - ret = svs_get_efuse_data(svsp, "t-calibration-data",
> - &svsp->tefuse, &svsp->tefuse_max);
> - if (ret)
> - return false;
> -
> for (i = 0; i < svsp->tefuse_max; i++)
> if (svsp->tefuse[i] != 0)
> break;
> @@ -2009,11 +1999,6 @@ static bool svs_mt8188_efuse_parsing(struct svs_platform *svsp)
> svsb->vmax += svsb->dvt_fixed;
> }
>
> - ret = svs_get_efuse_data(svsp, "t-calibration-data",
> - &svsp->tefuse, &svsp->tefuse_max);
> - if (ret)
> - return false;
> -
> for (i = 0; i < svsp->tefuse_max; i++)
> if (svsp->tefuse[i] != 0)
> break;
> @@ -2097,11 +2082,6 @@ static bool svs_mt8186_efuse_parsing(struct svs_platform *svsp)
> svsb->vmax += svsb->dvt_fixed;
> }
>
> - ret = svs_get_efuse_data(svsp, "t-calibration-data",
> - &svsp->tefuse, &svsp->tefuse_max);
> - if (ret)
> - return false;
> -
> golden_temp = (svsp->tefuse[0] >> 24) & GENMASK(7, 0);
> if (!golden_temp)
> golden_temp = 50;
> @@ -2198,11 +2178,6 @@ static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
> }
> }
>
> - ret = svs_get_efuse_data(svsp, "t-calibration-data",
> - &svsp->tefuse, &svsp->tefuse_max);
> - if (ret)
> - return false;
> -
> /* Thermal efuse parsing */
> adc_ge_t = (svsp->tefuse[1] >> 22) & GENMASK(9, 0);
> adc_oe_t = (svsp->tefuse[1] >> 12) & GENMASK(9, 0);
> @@ -3040,8 +3015,13 @@ static int svs_probe(struct platform_device *pdev)
>
> ret = svs_get_efuse_data(svsp, "svs-calibration-data",
> &svsp->efuse, &svsp->efuse_max);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret, "Cannot read SVS calibration\n");
With the previous code, if svs-calibration-data could not be read, the
code would go to svs_probe_free_efuse. In your case, it returns directly.
I believe that svs_get_efuse_data using nvmem_cell_read does not
allocate the buffer for the efuse , hence no more need to free it ? The
exit code is checking if it's ERR or NULL, but still, if the buffer was
not allocated, it doesn't make sense to jump there indeed.
In that case, you are also changing the behavior here , and your commit
appears to do more than a simple move.
> +
> + ret = svs_get_efuse_data(svsp, "t-calibration-data",
> + &svsp->tefuse, &svsp->tefuse_max);
> if (ret) {
> - ret = -EPERM;
> + dev_err_probe(&pdev->dev, ret, "Cannot read SVS-Thermal calibration\n");
> goto svs_probe_free_efuse;
again in this case the tefuse has not been allocated I assume.
So previous code was a bit excessive in trying to free the efuse/tefuse ?
Eugen
> }
>
next prev parent reply other threads:[~2023-11-22 11:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 12:50 [PATCH v3 00/20] MediaTek SVS driver partial refactoring AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 01/20] arm64: dts: mediatek: mt8183: Change iospaces for thermal and svs AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 02/20] soc: mediatek: mtk-svs: Subtract offset from regs_v2 to avoid conflict AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 03/20] soc: mediatek: mtk-svs: Convert sw_id and type to enumerations AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 04/20] soc: mediatek: mtk-svs: Build bank name string dynamically AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 05/20] soc: mediatek: mtk-svs: Reduce memory footprint of struct svs_bank AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 06/20] soc: mediatek: mtk-svs: Change the thermal sensor device name AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 07/20] soc: mediatek: mtk-svs: Add a map to retrieve fused values AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 08/20] soc: mediatek: mtk-svs: Add SVS-Thermal coefficient to SoC platform data AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 09/20] soc: mediatek: mtk-svs: Move t-calibration-data retrieval to svs_probe() AngeloGioacchino Del Regno
2023-11-22 11:23 ` Eugen Hristev [this message]
2023-11-22 12:41 ` AngeloGioacchino Del Regno
2023-11-22 12:51 ` Eugen Hristev
2023-11-21 12:50 ` [PATCH v3 10/20] soc: mediatek: mtk-svs: Commonize efuse parse function for most SoCs AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 11/20] soc: mediatek: mtk-svs: Drop supplementary svs per-bank pointer AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 12/20] soc: mediatek: mtk-svs: Commonize MT8192 probe function for MT8186 AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 13/20] soc: mediatek: mtk-svs: Remove redundant print in svs_get_efuse_data AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 14/20] soc: mediatek: mtk-svs: Compress of_device_id entries AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 15/20] soc: mediatek: mtk-svs: Cleanup of svs_probe() function AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 16/20] soc: mediatek: mtk-svs: Check if SVS mode is available in the beginning AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 17/20] soc: mediatek: mtk-svs: Use ULONG_MAX to compare floor frequency AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 18/20] soc: mediatek: mtk-svs: Constify runtime-immutable members of svs_bank AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 19/20] arm64: dts: mediatek: mt8192: Add Smart Voltage Scaling node AngeloGioacchino Del Regno
2023-11-21 12:50 ` [PATCH v3 20/20] arm64: dts: mediatek: mt8195: Add SVS node and reduce LVTS_AP iospace AngeloGioacchino Del Regno
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=6018ec3f-d3e6-4fe0-b57f-9a7994f983a5@collabora.com \
--to=eugen.hristev@collabora.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@collabora.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=wenst@chromium.org \
/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