Re: [PATCH v2] mmc: zynq_sdhci: support Renesas RZ/N1

On 8/27/26 4:12 PM, Ralph Siemsen wrote:
> On Tue, Aug 25, 2026 at 03:47:41PM -0400, Ralph Siemsen wrote:
>> On Sat, Aug 15, 2026 at 12:21:11AM +0200, Marek Vasut wrote:
>>> On 8/14/26 8:30 PM, Ralph Siemsen wrote:
>>>>         return ret;
>>>>     }
>>>> -    clock = clk_get_rate(&clk);
>>>> +    clock = clk_get_rate(&clks.clks[0]);
>>>
>>> Can the clock ever be non-first clock , i.e. do you need to handle 
>>> clock-names DT property somehow ?
>>
>> It's not clear to me if the DT binding specifies the order. It says 
>> there must be either 2 or 3 clocks, as well as clock-names properties.
> 
> I had another look at the clock ordering. According to [1]
>   "Order in lists is significant, order in dicts is not."
> 
> The binding [2] uses a list for the clock names:
> 
>    clock-names:
>      minItems: 2
>      items:
>        - const: clk_xin
>        - const: clk_ahb
>        - const: gate
> 
> And as we can see, the reference clock ("clk_xin") is listed first.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ 
> tree/Documentation/devicetree/bindings/example-schema.yaml#n47
> 
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ 
> tree/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml#n116
> 
> As a further check, I reversed the order of the clocks, and then ran 
> "make dtbs_check" to verify against DT schema. It complains:
> 
> arch/arm/dts/r9a06g032-rzn1-snarc.dtb: mmc@40100000 (renesas,r9a06g032- 
> sdhci): clock-names:0: 'clk_xin' was expected
>      from schema $id: http://devicetree.org/schemas/mmc/arasan,sdhci.yaml
> arch/arm/dts/r9a06g032-rzn1-snarc.dtb: mmc@40100000 (renesas,r9a06g032- 
> sdhci): clock-names:1: 'clk_ahb' was expected
>      from schema $id: http://devicetree.org/schemas/mmc/arasan,sdhci.yaml
> 
> No complaint when the clocks are in the correct order.
> 
>> We could try using the name ("clk_xin") and if that fails, fall back 
>> on using the first clock.
> 
> So I think we don't need this extra complexity after all. It should be 
> fine to rely on the first clock being the correct one.
I'd still go for the safer option -- look up by name, and if it fails, 
fall back to look up by ordering.