Re: [PATCH NOT APPLY v2 4/4] clk: scmi: Support spread spectrum

[Peng Fan <peng.fan@oss.nxp.com>]

On Thu, Feb 06, 2025 at 12:26:32PM +0000, Cristian Marussi wrote:
>On Wed, Feb 05, 2025 at 05:49:54PM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>> 
>> Support Spread Spectrum with adding scmi_clk_set_spread_spectrum
>> 
>
>Hi,
>
>I forwarded ATG with our latest exchange on the possibility of using a
>standard OEM type instead of Vendor one if it is general enough....
>
>...waiting for their feedback on this before reviewing further...BUT
>just one comment down below
>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>>  drivers/clk/clk-scmi.c        | 47 +++++++++++++++++++++++++++++++++++++++++--
>>  include/linux/scmi_protocol.h |  6 ++++++
>>  2 files changed, 51 insertions(+), 2 deletions(-)
>> 
>>  		feats_key |= BIT(SCMI_CLK_PARENT_CTRL_SUPPORTED);
>>  
>> -	if (ci->extended_config)
>> -		feats_key |= BIT(SCMI_CLK_DUTY_CYCLE_SUPPORTED);
>> +	if (ci->extended_config) {
>> +		if (of_machine_compatible_match(scmi_clk_imxlist))
>
>... please NOT this also here if we use a standard OEM type :D..if it
>won't be a vendor thing anymore, you should query with CONFIG_GET, OR we
>should think also about adding some way in the spec to query the support
>for extended configs like we do for other clock features...

I see, and I marked the title as NOT APPLY. CONFIG_GET would be heavy
for each clock. The clock attributes is better to send back what OEM type
is supported, not just a single OEM extension flag.

I posted out v2 mainly for "assigned-clock-sscs" changes, and not block
i.MX8M family spread spectrum patchset.
Also I hope patch [1,2] could got R-b or A-b from Maintainers. Then in NXP
downstream, I could pick patch [1,2] and do downstream implementation
for patch 4.

Thanks,
Peng.
>
>Thanks,
>Cristian