Re: [PATCH v2 1/3] dt-bindings: clock: introduce toshiba,tc9564-clock.yaml

[Krzysztof Kozlowski <krzk@kernel.org>]

On 09/10/2026 17:09, Alex Elder wrote:
> On 10/9/26 9:46 AM, Krzysztof Kozlowski wrote:
>> On 09/10/2026 16:23, Alex Elder wrote:
>>> On 10/9/26 8:56 AM, Krzysztof Kozlowski wrote:
>>>> On 09/10/2026 15:44, Alex Elder wrote:
>>>>> On 10/9/26 4:31 AM, Krzysztof Kozlowski wrote:
>>>>>> On Mon, Oct 05, 2026 at 06:09:24PM -0500, Alex Elder wrote:
>>>>>>> Define the binding for the clock controller functionality present in
>>>>>>> the Toshiba TC9564 SoC.
>>>>>>>
>>>>>>> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
>>>>>>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>>>>>>> Signed-off-by: Alex Elder <elder@riscstar.com>
>>>
>>> . . .
>>>
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    const: toshiba,tc9564-clock
>>>>>>> +
>>>>>>> +  toshiba,config-syscon:
>>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>>> +    description:
>>>>>>> +      Phandle for the configuration space system controller.
>>>>>>
>>>>>> I do not see my previous comment addressed - you have no resources here,
>>>>>> so this belongs to the parent. You responded something about pci-ep, but
>>>>>> the parent is not pci-ep. Open your code:
>>>>>> https://lore.kernel.org/lkml/20260918165234.687224-5-elder@riscstar.com/
>>>>>>
>>>>>> I clearly see code like:
>>>>>>      syscon {
>>>>>>        clock@ {
>>>>>>        };
>>>>>>      };
>>>>>>
>>>>>> so I do not understand what pci-ep has anything to do here.
>>>>>
>>>>> What I have now (about to send) looks like this:
>>>>>
>>>>>        syscon@0 {
>>>>>            compatible = "syscon", "simple-mfd";
>>>>>            reg = <0x0 0x2000>;
>>>>>
>>>>>            clock {
>>>>>                compatible = "toshiba,tc9564-clock";
>>>>>                #clock-cells = <1>;
>>>>>            };
>>>>>        };
>>>>>
>>>>> A reset node will also go inside the syscon, so there is another
>>>>> function for that MFD.
>>>>>
>>>>> The regmap belongs to the parent, and is looked up this way:
>>>>>
>>>>>        regmap = syscon_node_to_regmap(dev_of_node(dev->parent));
>>>>
>>>> That's driver code, so irrelevant. So how does this solve my comment
>>>> from v1?
>>>
>>> I'm trying Krzysztof.
>>
>> In v1 I asked to fold the node into the parent. v2 did not have it. v3,
>> which you are preparing, still has no node folded, because they are
>> separate.
> 
> Are you saying to fold it into the PCI function?

I do not see in the example the parent being PCI function, so I do not
understand that. What is this node? What is its parent?


> 
> If so, could the PCI function be a clock provider and
> define #clock-cells (and #reset-cells)?
> 
> Because as things stand now, clock and reset are used by
> the two DWMAC Ethernet interfaces as well as a separate
> interrupt controller (one for each PCI function).
> 
> It sounds a little like you might prefer everything being
> wrapped up in the DWMAC driver, as we originally did six
> months ago.
> 
Not sure which patchset you refer to - v1 was in September.

Best regards,
Krzysztof