Re: [PATCH] interconnect: qcom: Fix DT backwards compatibility for QoS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4.07.2024 7:44 PM, Bjorn Andersson wrote:
> On Thu, Jul 04, 2024 at 06:25:15PM GMT, Odelu Kukatla wrote:
>> Add qos_clks_required flag to skip QoS configuration if clocks property
>> is not populated in devicetree for providers which require clocks to be
>> enabled for accessing registers. This is to keep the QoS configuration
>> backwards compatible with devices that have older DTB.
>>
> 
> Please read "Describe your changes" [1], and make your commit message
> start with the problem description - establish to the reader why this
> change is needed, then follow that with a technical description of the
> solution (likely in a separate paragraph).
> 
> [1] https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
> 
>> Reported-by: Bjorn Andersson <andersson@xxxxxxxxxx>
>> Closes: https://lore.kernel.org/all/ciji6nlxn752ina4tmh6kwvek52nxpnguomqek6plwvwgvoqef@yrtexkpmn5br/
>> Signed-off-by: Odelu Kukatla <quic_okukatla@xxxxxxxxxxx>
>> ---
>>  drivers/interconnect/qcom/icc-rpmh.c | 2 +-
>>  drivers/interconnect/qcom/icc-rpmh.h | 1 +
>>  drivers/interconnect/qcom/sc7280.c   | 2 ++
>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/interconnect/qcom/icc-rpmh.c b/drivers/interconnect/qcom/icc-rpmh.c
>> index 93047defd5e2..f49a8e0cb03c 100644
>> --- a/drivers/interconnect/qcom/icc-rpmh.c
>> +++ b/drivers/interconnect/qcom/icc-rpmh.c
>> @@ -311,7 +311,7 @@ int qcom_icc_rpmh_probe(struct platform_device *pdev)
>>  		}
>>  
>>  		qp->num_clks = devm_clk_bulk_get_all(qp->dev, &qp->clks);
>> -		if (qp->num_clks < 0) {
>> +		if (qp->num_clks < 0 || (!qp->num_clks && desc->qos_clks_required)) {
> 
> For this new case, I think the dev_info() below makes total sense. I.e.
> this looks good to me.
> 
> 
> However, the num_clks < 0 case would represent finding a devicetree node
> with clocks specified, but failing to get these clocks. I believe that
> this would include EPROBE_DEFER.
> 
> I don't think it's correct to print a informational message and continue
> without QoS. I think we should fail here.

Since setting QoS settings is optional, I'd say we should simply skip trying
to do so. Unless setting them on some buses (i.e. ones without failing clocks)
and not on the rest would cause issues. But then, these settings should be
bus-local, so perhaps it would still be fine?

Konrad




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux