Re: [PATCH v5 8/9] clk: nuvoton: ma35d1: get HXT/LXT from DT

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

On 30/09/2026 at 09:39:47 +02, Jerome Brunet <jbrunet@baylibre.com> wrote:

> On mar. 29 sept. 2026 at 22:36, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
>> On 29/09/2026 at 14:56:17 GMT, sashiko-bot@kernel.org wrote:
>>
>>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>>> - [High] clk: nuvoton: missing IS_ERR check causes permanent probe
>>> deferral
>>
>> Gasp. Yes that's correct.
>>
>>> - [Medium] clk: nuvoton: hardcoded parent strings cause orphaned gate
>>> clocks
>>
>> I don't think this one is serious, linkage is reliable because we
>> leverage the device tree nodes in the clk_core_get/clk_parse_spec
>> path. The fallback is indeed based on string matching, but heh, that's
>> because of backward compat, not my call.
>
> If think it is a legit warning.
>
> Here you say that your "hxt_gate" will parent to a clock named "hxt" in
> CCF, but you've got not guarantee that will be the name your externally
> provided clock. 
>
> Its fw_name is stable for you but you should make any assumption how
> another module will name its clock.
>
> You should use parent_data here with .fw_name that will match the externally
> provided clock and .name as a fallback if the clock is actually provided
> internally

Ok, I believe I got your point. I can avoid any assumptions for the gate
clocks, because I have access to their parent 'hw'.

For the crystals, I see what you mean with the naming being global and
not enforced, that's true. I will continue expecting "the first clock"
to be hxt (already enforced by the bindings/existing DT). For the
second crystal, lxt, I will try a regular DT lookup (similar to the
.fw_name approach you mentioned) and fallback to an internally provided
block.

Thanks,
Miquèl