Re: [PATCH 1/4] dt-bindings: soc: introduce toshiba,tc9564-config-syscon.yaml

[Alex Elder <elder@riscstar.com>]

On 11/5/26 2:23 PM, Krzysztof Kozlowski wrote:
> On 04/11/2026 01:43, Alex Elder wrote:
>> Define the binding for the system controller that implements the clock
>> and reset 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>
>> ---
>>   .../toshiba/toshiba,tc9564-config-syscon.yaml | 68 +++++++++++++++++++
>>   MAINTAINERS                                   |  8 +++
>>   include/dt-bindings/soc/toshiba,tc9564.h      | 46 +++++++++++++
>>   3 files changed, 122 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/soc/toshiba/toshiba,tc9564-config-syscon.yaml
>>   create mode 100644 include/dt-bindings/soc/toshiba,tc9564.h
>>
>> diff --git a/Documentation/devicetree/bindings/soc/toshiba/toshiba,tc9564-config-syscon.yaml b/Documentation/devicetree/bindings/soc/toshiba/toshiba,tc9564-config-syscon.yaml
>> new file mode 100644
>> index 0000000000000..5a241a9c915d1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/toshiba/toshiba,tc9564-config-syscon.yaml
>> @@ -0,0 +1,68 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/soc/toshiba/toshiba,tc9564-config-syscon.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Toshiba TC9564 Multifunction System Controller
>> +
>> +maintainers:
>> +  - Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
>> +  - Alex Elder <elder@riscstar.com>
>> +  - Daniel Thompson <daniel@riscstar.com>
>> +
>> +description:
>> +  The Toshiba TC9564 is an SoC accessed by a host system through the
>> +  upstream PCIe port on the PCIe switch it implements.  The switch
>> +  includes an embedded PCIe endpoint that provides access to various
>> +  SoC peripherals via its BARs.  These peripherals include a simple
>> +  controller to gate internal clocks, as well as a reset controller.
>> +
>> +  The clock controller uses registers within the same page as a reset
>> +  controller, so this system controller controls access to both.
>> +
>> +  A total of 21 simple gated clocks are implemented within the SoC.
>> +  At this time, support for enabling and disabling only a subset of
>> +  them is provided at this time.  Similarly, the SoC implements 13
>> +  resets, but currently not all of them can be controlled.
>> +
>> +properties:
>> +  compatible:
>> +    items:
>> +      - const: toshiba,tc9564-config-syscon
>> +      - const: syscon
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  "#clock-cells":
>> +    const: 1
>> +    description:
>> +      Clock ids are defined in <include/dt-bindings/soc/toshiba,tc9564.h>
>> +
>> +  "#reset-cells":
>> +    const: 1
>> +    description:
>> +      Reset ids are defined in <include/dt-bindings/soc/toshiba,tc9564.h>
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - "#clock-cells"
>> +  - "#reset-cells"
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    syscon@0 {
>> +        compatible = "toshiba,tc9564-config-syscon", "syscon";
> 
> I disagree this to be syscon.

Conor Ack'd this patch, and then followed up asking me to
mention the other feature it provides, which I agreed to do.
It is an important third use of the memory region.

   https://lore.kernel.org/lkml/20261105-irregular-awaken-b329b9c37e70@spud/

In addition to the registers that control these clocks and
resets, this address range contains two registers (one per
PCI function) that indicate when a DWMAC hardware
initialization step is complete.  The nodes representing
those Ethernet MACs refer to this syscon with a phandle
property (and offset).

Is that additional use enough to warrant defining this as
a syscon?  I.e., with that third use, does this no longer
represent a "pure internal-register-access thingy?

> This is internal to the PCI device. I read Daniel Thompson answer:
> https://lore.kernel.org/all/auOI8LbZNWbNGJuN@aspen.lan/
> And I accept arguments that you want to re-use a lot of existing
> bindings like DWMAC and so on. Syscon does not count there.
> 
> I remember you posted somewhere full DTS, but now I could not find it
> again and I do not see it in the cover letter here.

I should have included it, and will include this in future messages.
I squashed together the DTS commits into a single complete DTS that
we are testing with, here:

  
https://github.com/riscstar/linux/blob/tc9564-dts/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts

I'll also respond to your other message.

					-Alex

> So again, why does it have to be a syscon, which is pure
> internal-register-access thingy?


> Best regards,
> Krzysztof