Received-SPF: pass (google.com: domain of linux-kernel+bounces-118395-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 26 Mar 2024 11:33:35 +0530
From: Varadarajan Narayanan <quic_varada@quicinc.com>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
CC: <andersson@kernel.org>, <mturquette@baylibre.com>, <sboyd@kernel.org>,
        <robh@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
        <conor+dt@kernel.org>, <djakov@kernel.org>, <quic_anusha@quicinc.com>,
        <linux-arm-msm@vger.kernel.org>, <linux-clk@vger.kernel.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] clk: qcom: add IPQ9574 interconnect clocks support
Message-ID: <ZgJlNx1vHoM2DfSz@hu-varada-blr.qualcomm.com>
References: <20240325102036.95484-1-quic_varada@quicinc.com>
 <20240325102036.95484-4-quic_varada@quicinc.com>
 <fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org>

On Mon, Mar 25, 2024 at 08:42:21PM +0100, Konrad Dybcio wrote:
> On 25.03.2024 11:20 AM, Varadarajan Narayanan wrote:
> > Unlike MSM platforms that manage NoC related clocks and scaling
> > from RPM, IPQ SoCs dont involve RPM in managing NoC related
> > clocks and there is no NoC scaling.
> >
> > However, there is a requirement to enable some NoC interface
> > clocks for accessing the peripheral controllers present on
> > these NoCs. Though exposing these as normal clocks would work,
> > having a minimalistic interconnect driver to handle these clocks
> > would make it consistent with other Qualcomm platforms resulting
> > in common code paths.  This is similar to msm8996-cbf's usage of
> > icc-clk framework.
> >
> > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> > ---
>
> [...]
>
> >
> > +
> > +static struct icc_clk_data *icc_ipq9574;
> > +
>
> What does this help achieve?

Had it as a place holder in case if the provider pointer is needed
for any debug. Will remove it.

> > +static int noc_clks[] = {
>
> We could probably use indexed identifiers here to avoid confusion:
> [ICC_BINDING_NAME] = CLK_BINDING_NAME

ok.

> >  static int gcc_ipq9574_probe(struct platform_device *pdev)
> >  {
> > -	return qcom_cc_probe(pdev, &gcc_ipq9574_desc);
> > +	int ret = qcom_cc_probe(pdev, &gcc_ipq9574_desc);
> > +	struct icc_provider *provider;
> > +	struct icc_clk_data *icd;
> > +	int i;
> > +
> > +	if (ret)
>
> I'd personally prefer if you left ret uninitialized and assigned it
> above the if-statement.

ok

> > +		return dev_err_probe(&pdev->dev, ret, "%s failed\n", __func__);
>
> Please avoid the use of __func__ throughout your change and write
> a more useful error message.
>
> > +
> > +	icd = devm_kmalloc(&pdev->dev, ARRAY_SIZE(noc_clks) * sizeof(*icd),
> > +			   GFP_KERNEL);
>
> devm_kcalloc

ok

> > +
> > +	if (IS_ERR_OR_NULL(icd))
> > +		return dev_err_probe(&pdev->dev, PTR_ERR(icd),
> > +				     "%s malloc failed\n", __func__);
>
> ditto

ok

> > +
> > +	icc_ipq9574 = icd;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(noc_clks); i++, icd++) {
> > +		icd->clk = gcc_ipq9574_clks[noc_clks[i]]->hw.clk;
> > +		if (IS_ERR_OR_NULL(icd->clk)) {
> > +			dev_err(&pdev->dev, "%s: %d clock not found\n",
> > +				__func__, noc_clks[i]);
> > +			return -ENOENT;
>
> return dev_err_probe

ok

> > +		}
> > +		icd->name = clk_hw_get_name(&gcc_ipq9574_clks[noc_clks[i]]->hw);
> > +	}
> > +
> > +	provider = icc_clk_register(&pdev->dev, IPQ_APPS_ID,
> > +				    ARRAY_SIZE(noc_clks), icc_ipq9574);
> > +	if (IS_ERR_OR_NULL(provider))
> > +		return dev_err_probe(&pdev->dev, PTR_ERR(provider),
> > +				     "%s: icc_clk_register failed\n", __func__);
>
> ditto

ok

> On a second thought, since I'm assuming you're going to expand this to other
> IPQ SoCs, it might be useful to factor this out into drivers/clk/qcom/common.c

Will move it.

Thanks
Varada