Re: [PATCH 2/4] clk: qcom: common: introduce qcom_cc_sync_state()

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 6/15/26 4:24 PM, Brian Masney wrote:
> Hi Dmitry,
> 
> On Sun, Jun 07, 2026 at 01:30:03PM +0300, Dmitry Baryshkov wrote:
>> On Sun, Jun 07, 2026 at 01:43:06AM -0300, Val Packett wrote:
>>>
>>> On 6/6/26 8:15 AM, Dmitry Baryshkov wrote:
>>>> On Wed, Jun 03, 2026 at 10:21:47AM -0400, Brian Masney wrote:
>>>>> Several qcom clk providers currently have a sync_state helper set to
>>>>> icc_sync_state(). With an upcoming change to the clk framework, if
>>>>> sync_state is not defined for the device, then the clk framework sets it
>>>>> to clk_sync_state().
>>>>> [..]
>>>>> @@ -464,5 +466,12 @@ int qcom_cc_probe_by_index(struct platform_device *pdev, int index,
>>>>>   }
>>>>>   EXPORT_SYMBOL_GPL(qcom_cc_probe_by_index);
>>>>> +void qcom_cc_sync_state(struct device *dev)
>>>>> +{
>>>>> +	icc_sync_state(dev);
>>>> Only if desc->icc_hws != 0, otherwise it will mess the interconnect
>>>> internals. You might need to set drvdata to desc.
>>>
>>> Hmm…
>>>
>>> Currently icc_sync_state does not seem to use the dev argument at all.
>>>
>>> How would something get messed up, now or whenever icc_sync_state changes?
>>> o.0
>>
>> Yes :-(
> 
> Sorry about the delayed response since I was out of town all last week.
> Just to be clear, the missing check for 'desc->icc_hws != 0' is a bug that
> existed prior to my change, and I should label it as such with a Fixes
> tag when I post my next version?

Up until this change, having icc_hws > 0 but lacking icc_sync_state
(or the reverse) would be be considered programmer error

Starting with patch 4, this gets assigned unconditionally, so there's
no prior bug to be fixed

Konrad