linux-kernel - Re: [PATCH 2/6] clk: qcom: Add support for GPU Clock Controller on QCS8300

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <34216857-170c-45d4-8f6d-987573269215@kernel.org>
Date: Mon, 21 Oct 2024 17:11:15 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Imran Shaik <quic_imrashai@...cinc.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Ajit Pandey <quic_ajipan@...cinc.com>,
 Taniya Das <quic_tdas@...cinc.com>, Jagadeesh Kona <quic_jkona@...cinc.com>,
 Satya Priya Kakitapalli <quic_skakitap@...cinc.com>,
 linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] clk: qcom: Add support for GPU Clock Controller on
 QCS8300

On 21/10/2024 12:56, Dmitry Baryshkov wrote:
>>>  	{ }
>>>  };
>>> @@ -596,6 +635,14 @@ static int gpu_cc_sa8775p_probe(struct platform_device *pdev)
>>>  	if (IS_ERR(regmap))
>>>  		return PTR_ERR(regmap);
>>>  
>>> +	if (of_device_is_compatible(pdev->dev.of_node, "qcom,qcs8300-gpucc")) {
>>
>> Why we cannot use match data? Seeing compatibles in the code is
>> unexpected and does not scale.
> 
> Because using match data doesn't scale in such cases. We have been using

I don't understand how it could not scale. That's the entire point of
match data - scaling.

> compatibles to patch clock trees for the platforms for quite a while.
> You can see that each of the "tunings" is slightly different. From my


You have one driver, where are these tunings which are supposed to be
different? You need here only enum or define, in the simplest choice.

> point of view, this approach provides a nice balance between having a
> completely duplicate driver and having a driver which self-patches the
> tree.

How duplicate driver got into this? I don't think we talk about the
same. I meant ID table match data.
> 

Best regards,
Krzysztof