Re: [PATCH v8 3/7] clk: nuvoton: ma35d1: Retrieve HXT/LXT from DT when possible

[Miquel Raynal <miquel.raynal@bootlin.com>]

> This commit modifies the clock driver to retrieve the external HXT and LXT
> clocks from the device tree instead of registering them directly. It falls
> back to registering LXT for backward compatibility with older device trees.
>
>> diff --git a/drivers/clk/nuvoton/clk-ma35d1.c b/drivers/clk/nuvoton/clk-ma35d1.c
>> index ceebcbd8c18b3..ed61a990870e4 100644
>> --- a/drivers/clk/nuvoton/clk-ma35d1.c
>> +++ b/drivers/clk/nuvoton/clk-ma35d1.c
> [ ... ]
>> @@ -240,12 +257,18 @@ static int ma35d1_clocks_probe(struct platform_device *pdev)
>>  		return -EINVAL;
>>  	}
>>  
>> -	hws[HXT] = ma35d1_clk_fixed("hxt", 24000000);
>
> [Severity: Critical]
> Does this unconditional removal break ABI compatibility with older device
> trees?
>
> Because HXT (index 0) is exported as a public ABI in the DT bindings,
> removing its explicit registration leaves hws[HXT] as NULL in the provider's
> clock array. If an existing downstream or older device tree consumer explicitly
> references this clock via clocks = <&clk HXT>, won't the provider's
> of_clk_hw_onecell_get() fail to resolve the clock and return an error?

Jerome, your wisdom matters here :-) For me this is a false positive,
because nobody outside this driver should access hws[HXT] and the clock
is still referenced through the DT, just not provided by this
driver. For me this is not an issue we should consider, let me know
otherwise.

Miquèl