clk: introduce TC9564 clock and reset

Define the binding for a system controller used in the Toshiba TC9564 SoC.

Co-developed-by Daniel Thompson <[email protected]>

Signed-off-by Daniel Thompson <[email protected]>

Signed-off-by Alex Elder <[email protected]>

---
 .../bindings/mfd/toshiba,tc9564.yaml          | 56 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +3 -0

new file mode 100644
index 0000000000000..32e73a727c82a
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +15 -0

+  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 on one of its downstream ports that provides
+  access to various SoC peripherals (including a clock and reset controller)
+  via one of its BARs.  A system controller provides managed access to the
+  first two pages of this memory region to ensure accesses made by these
+  peripherals produce well-defined results.
+
+properties:
+  compatible:
+    items:
+      - const: toshiba,tc9564-config
+      - const: syscon
+      - const: simple-mfd
+

Quoted 6 lines · Alex Elder

Define the binding for a system controller used in the Toshiba TC9564 SoC.

Co-developed-by Daniel Thompson <[email protected]>

Signed-off-by Daniel Thompson <[email protected]>

Signed-off-by Alex Elder <[email protected]>

Quoted 19 lines

---
  .../bindings/mfd/toshiba,tc9564.yaml          | 56 +++++++++++++++++++
  MAINTAINERS                                   |  1 +
  2 files changed, 57 insertions(+)

create mode 100644 Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +7 -0

new file mode 100644
index 0000000000000..32e73a727c82a
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/toshiba,tc9564.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC9564 System Controller

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml line 13

Quoted 6 lines

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +6 -0

+
+maintainers:
+  - Alex Elder <[email protected]>
+  - Daniel Thompson <[email protected]>
+
+description: |

Do not need '|' unless you need to preserve formatting.

Quoted 19 lines

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +19 -0

+  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 on one of its downstream ports that provides
+  access to various SoC peripherals (including a clock and reset controller)
+  via one of its BARs.  A system controller provides managed access to the
+  first two pages of this memory region to ensure accesses made by these
+  peripherals produce well-defined results.
+
+properties:
+  compatible:
+    items:
+      - const: toshiba,tc9564-config
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  ranges: true

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml line 38

Quoted 6 lines

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +6 -0

+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 1

Both properties and simple-mfd are redundant. You do not have children.

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml line 44

Quoted 6 lines

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +6 -0

+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false

And this should be additionalProperties instead

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml line 55

Quoted 10 lines

Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml new file +10 -0

+examples:
+  - |
+    syscon@0 {
+        compatible = "toshiba,tc9564-config",
+                     "syscon",
+                     "simple-mfd";
+        reg = <0x0 0x2000>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;

As you can see here - no children.

I also have doubts that this is needed - I see no updates to the misc binding, which would be referencing it. But then another point would be, that you do not need separate child node, which has no properties.

Well, has one - address space.

Lack of full picture is not helping here.

Best regards,
Krzysztof

Quoted 3 lines

I also have doubts that this is needed - I see no updates to the misc binding, which would be referencing it. But then another point would be, that you do not need separate child node, which has no properties.

Quoted 3 lines · Alex Elder

Quoted 3 lines

I also have doubts that this is needed - I see no updates to the misc binding, which would be referencing it. But then another point would be, that you do not need separate child node, which has no properties.

Krzysztof, I've done some additional work on this based on your feedback.

I think you are correct that there is no need to define this as a special syscon with its own compatible string.

Instead, I can simply define a simple syscon with a label:

         tc9564_config_syscon0: syscon@0 {
                 compatible = "syscon";

                 reg = <0x0 0x2000>;
         };

And then have the devices that need to use it, refer to its label using a phandle:

         tc9564_clock0: clock@1004 {
                 compatible = "toshiba,tc9564-clock";
                 toshiba,config-syscon = <&tc9564_config_syscon0>;
                 #clock-cells = <1>;
                 #reset-cells = <1>;
         };

         tc9564_emac0: ethernet@40000 {
                 compatible = "toshiba,tc9564-xgmac";
                 reg = <0x40000 0x8000>;
                 toshiba,config-syscon = <&tc9564_config_syscon0 0x1070>;
		. . .
	};

         tc9564_emac1: ethernet@48000 {
                 compatible = "toshiba,tc9564-xgmac";
                 reg = <0x48000 0x8000>;
                 toshiba,config-syscon = <&tc9564_config_syscon0 0x1074>;
		. . .
	};

That simplifies things a bit, and requires no devicetree binding.

If you think this is incorrect, please let me know, otherwise it is the direction I plan to go with the next version of this series.

I think nothing behind PCI EP should be described in DT, because everything is internal to the device and implied by compatible (or vid/pid). We do describe internals of devices in DT usually for complex devices (like some display blocks with multiple subblocks) or when they are used outside of that device. That's why I asked how are all these clocks and resets exposed to the host. If the syscon is used only by the device itself, I don't quite get the benefits of describing it in DT.

Quoted 7 lines · Krzysztof Kozlowski

I think nothing behind PCI EP should be described in DT, because everything is internal to the device and implied by compatible (or vid/pid). We do describe internals of devices in DT usually for complex devices (like some display blocks with multiple subblocks) or when they are used outside of that device. That's why I asked how are all these clocks and resets exposed to the host. If the syscon is used only by the device itself, I don't quite get the benefits of describing it in DT.

You say you think "nothing behind PCI EP should be described in DT". However the mere existence of the PCI endpoint bus as an option contradicts that statement, by providing a means of doing *exactly*
that: using devicetree to describe things behind a PCI endpoint. This is the model we are using.

In June we switched over to using the pci-ep-bus model based on a suggestion from Rob Herring (and Mani Sadhasivam). Rob felt our previous auxiliary device approach wasn't right for the peripherals found within the SoC, given we were accessing them via PCI BARs.
https://lore.kernel.org/lkml/[email protected]/

We found that using pci-ep-bus provided a very natural and familiar way of representing the organization of the TC9564 SoC, and used it to represent all of the peripherals (including XGMAC). It nicely partitions the hardware design, as well as providing a well-understood connection with the software.

The switch involved quite a bit of work, and the result is a set of basically independent platform drivers that are modular and easily reviewed. I really would rather not go back to to what we had before.

Do you have criteria for what in a chip/SoC is sufficiently "complex" to warrant allowing devicetree to describe some of its internal details?

I believe the TC9564 *is* such a "complex" SoC. And in any case, anywhere pci-ep-bus is used, it implies that some chip internals would be described using devicetree.

Would incorporating the chip internals in a devicetree *overlay* have any effect on your opinion on this? I.e., the "main" devicetree nodes would simply define the PCI device hierarchy, but anything behind an endpoint would be described in an overlay. This way, pci-ep-bus on a PCI endpoint just provides an external interface onto which a very complex device could be "mounted" (and described in an overlay).

I'd like to continue to move ahead with upstreaming support for this SoC, but to me it seems you have basic doubts about pci-ep-bus and I'd like to get past that.

Quoted 13 lines · Alex Elder

On 9/23/26 2:25 AM, Krzysztof Kozlowski wrote:
I believe the TC9564 *is* such a "complex" SoC. And in any case, anywhere pci-ep-bus is used, it implies that some chip internals would be described using devicetree.

Would incorporating the chip internals in a devicetree *overlay* have any effect on your opinion on this? I.e., the "main" devicetree nodes would simply define the PCI device hierarchy, but anything behind an endpoint would be described in an overlay. This way, pci-ep-bus on a PCI endpoint just provides an external interface onto which a very complex device could be "mounted" (and described in an overlay).

Quoted 3 lines

I'd like to continue to move ahead with upstreaming support for this SoC, but to me it seems you have basic doubts about pci-ep-bus and I'd like to get past that.

Well, Rob might understand this better, so maybe review from him will solve these questions.

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml new file +33 -0

+  compatible string.  All of the clocks are simple gate clocks.
+
+  A total of 21 clocks are implemented, though two of these are not
+  controllable.  Access to the clock controller relies on PCIe being
+  functional, so the PCIe clock is assumed to be always on.  Similarly,
+  the PCIe controller relies on I2C, so the I2C clock is also assumed
+  to be always on.
+
+  In addition, 13 resets are implemented.  Similar to clocks, the PCIe
+  and I2C resets are assumed to be deasserted and cannot be controlled.
+
+  Clock and reset ids are defined in <dt-bindings/clock/toshiba,tc9564.h>.
+
+properties:
+  compatible:
+    const: toshiba,tc9564-clock
+
+  reg:
+    maxItems: 1
+
+  "#clock-cells":
+    const: 1
+
+  "#reset-cells":
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - "#clock-cells"
+  - "#reset-cells"
+
+unevaluatedProperties: false

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml new file +1 -0

+    };

MAINTAINERS +7 -0

index b2d3257b8f892..66d0e7e65adcb 100644
@@ -27670,6 +27670,13 @@ F:	Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.txt
 F:	drivers/media/i2c/tc358743*
 F:	include/media/i2c/tc358743.h
 
+TOSHIBA TC9564 CLOCK DRIVER
+M:	Alex Elder <[email protected]>
+M:	Daniel Thompson <[email protected]>
+S:	Maintained
+F:	Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
+F:	include/dt-bindings/clock/toshiba,tc9564.h
+
 TOSHIBA TC9564 PCI DRIVER
 M:	Alex Elder <[email protected]>
 M:	Daniel Thompson <[email protected]>

include/dt-bindings/clock/toshiba,tc9564.h new file +5 -0

new file mode 100644
index 0000000000000..75732fddd3025
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */

Quoted 1 line · Alex Elder

+description: |

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml line 20

Quoted 7 lines

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml new file +7 -0

+  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 (including a clock/reset controller) via its BARs.
+
+  The SoC is represented using a devicetree PCI endpoint bus, so the
+  clock controller is bound to its driver using a platform driver

Do not mention drivers here. Just say that host can access clocks etc via PCI.

But then more questions. This is PCI, yes? So how are the clocks from PCI routed BACK to the main soc, which would justify having this in DTS in the first place?

Quoted 38 lines

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml new file +38 -0

+  compatible string.  All of the clocks are simple gate clocks.
+
+  A total of 21 clocks are implemented, though two of these are not
+  controllable.  Access to the clock controller relies on PCIe being
+  functional, so the PCIe clock is assumed to be always on.  Similarly,
+  the PCIe controller relies on I2C, so the I2C clock is also assumed
+  to be always on.
+
+  In addition, 13 resets are implemented.  Similar to clocks, the PCIe
+  and I2C resets are assumed to be deasserted and cannot be controlled.
+
+  Clock and reset ids are defined in <dt-bindings/clock/toshiba,tc9564.h>.
+
+properties:
+  compatible:
+    const: toshiba,tc9564-clock
+
+  reg:
+    maxItems: 1
+
+  "#clock-cells":
+    const: 1
+
+  "#reset-cells":
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - "#clock-cells"
+  - "#reset-cells"
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/toshiba,tc9564.h>
+

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml line 63

Quoted 5 lines

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml new file +5 -0

+    clock@1004 {
+        compatible = "toshiba,tc9564-clock";
+        reg = <0x1004 0x20>;
+        #clock-cells = <1>;
+        #reset-cells = <1>;

No resources except small address space, so does not look like a separate device and should be folded into the parent node.

Quoted 31 lines

Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml new file +1 -0

+    };

MAINTAINERS +7 -0

index b2d3257b8f892..66d0e7e65adcb 100644
@@ -27670,6 +27670,13 @@ F:	Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.txt
  F:	drivers/media/i2c/tc358743*
  F:	include/media/i2c/tc358743.h
 
+TOSHIBA TC9564 CLOCK DRIVER
+M:	Alex Elder <[email protected]>
+M:	Daniel Thompson <[email protected]>
+S:	Maintained
+F:	Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
+F:	include/dt-bindings/clock/toshiba,tc9564.h
+
  TOSHIBA TC9564 PCI DRIVER
  M:	Alex Elder <[email protected]>
  M:	Daniel Thompson <[email protected]>

include/dt-bindings/clock/toshiba,tc9564.h new file +5 -0

new file mode 100644
index 0000000000000..75732fddd3025
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */

include/dt-bindings/clock/toshiba,tc9564.h line 15

Quoted 10 lines

include/dt-bindings/clock/toshiba,tc9564.h new file +10 -0

+
+#ifndef __ClOCK_TOSHIBA_TC9564_H__
+#define __ClOCK_TOSHIBA_TC9564_H__
+
+/* Clock IDs */
+
+#define CLOCK_MCU		0
+#define CLOCK_INTC		1
+/* #define CLOCK_PCIE		2 */
+/* #define CLOCK_I2C		3 */

Drop both, and SRAM is number 2. Or enable and implement them.

Best regards,
Krzysztof

Quoted 14 lines

include/dt-bindings/clock/toshiba,tc9564.h new file +8 -0

new file mode 100644
index 0000000000000..75732fddd3025
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */
+
+#ifndef __ClOCK_TOSHIBA_TC9564_H__
+#define __ClOCK_TOSHIBA_TC9564_H__

include/dt-bindings/clock/toshiba,tc9564.h line 15

Quoted 7 lines

include/dt-bindings/clock/toshiba,tc9564.h new file +7 -0

+
+/* Clock IDs */
+
+#define CLOCK_MCU		0
+#define CLOCK_INTC		1
+/* #define CLOCK_PCIE		2 */
+/* #define CLOCK_I2C		3 */

Drop both, and SRAM is number 2. Or enable and implement them.

Quoted 14 lines · Krzysztof Kozlowski

Quoted 14 lines

include/dt-bindings/clock/toshiba,tc9564.h new file +8 -0

new file mode 100644
index 0000000000000..75732fddd3025
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */
+
+#ifndef __ClOCK_TOSHIBA_TC9564_H__
+#define __ClOCK_TOSHIBA_TC9564_H__

Quoted 8 lines

include/dt-bindings/clock/toshiba,tc9564.h line 15

Quoted 7 lines

include/dt-bindings/clock/toshiba,tc9564.h new file +7 -0

+
+/* Clock IDs */
+
+#define CLOCK_MCU		0
+#define CLOCK_INTC		1
+/* #define CLOCK_PCIE		2 */
+/* #define CLOCK_I2C		3 */

Drop both, and SRAM is number 2. Or enable and implement them.

I forgot to respond to this. I think you are confused.

SRAM is BAR number 2. This is defining clock IDs.

And the reason these are commented out is that, while they do exist, we explicitly do not want anyone to disable either of these clocks because PCIe uses them. This clock (and reset) control is accessed via PCIe.

I do accept that someone might want me to simply omit these commented-out definitions, and I'd be fine with that.

But your suggestion wasn't sensible so I wanted to clear that up before deleting these.

Hello Alex,

drivers/clk/clk-tc9564.c line 14

Quoted 8 lines · Alex Elder

drivers/clk/clk-tc9564.c new file +8 -0

+#include <linux/bits.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>

Please rely on linux/platform_device.h to provide of_device_id and drop including <linux/mod_devicetable.h>. (If you want to go full iwyu, include <linux/device-id/of.h> instead.)

drivers/clk/clk-tc9564.c line 351

Quoted 4 lines

drivers/clk/clk-tc9564.c new file +4 -0

+static const struct of_device_id tc9564_clk_ids[] = {
+	{ .compatible = "toshiba,tc9564-clock" },
+	{ },
+};

Drop the trailing comma after the list terminator please.

Best regards
Uwe

Quoted 13 lines · Uwe Kleine-König

drivers/clk/clk-tc9564.c line 14

Quoted 8 lines · Alex Elder

drivers/clk/clk-tc9564.c new file +8 -0

+#include <linux/bits.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>

Please rely on linux/platform_device.h to provide of_device_id and drop including <linux/mod_devicetable.h>. (If you want to go full iwyu, include <linux/device-id/of.h> instead.)

In general I would like to "go full iwyu" but have never heard it expressed that way. Can you recommend a tool available that will help me do that?

It looks like "mod_devicetable.h" doesn't help much unless I need struct_cpu_feature (which I do not), so I'll include "of.h".

Quoted 6 lines

drivers/clk/clk-tc9564.c line 351

Quoted 4 lines

drivers/clk/clk-tc9564.c new file +4 -0

+static const struct of_device_id tc9564_clk_ids[] = {
+	{ .compatible = "toshiba,tc9564-clock" },
+	{ },
+};

Drop the trailing comma after the list terminator please.

OK. Only for the list terminator, right, because nothing will ever follow it? Non-empty final initializer is OK to have a comma as far as you're concerned?

Define a new platform driver that manages clock and reset signals within the TC9564 SoC. There are 21 clocks, which can only be enabled and disabled, as well as 13 reset signals.

Two registers manage the state of the clocks and two others manage the state of the resets. The registers are accessed via a regmap supplied by a system controller, which coordinates access to a region of memory that will be shared with another driver.

Access to the memory region is provided via a BAR on a PCIe endpoint function embedded in the TC9564 SoC. For that reason, neither the PCIe clock nor PCIe reset can be manipulated by this driver (they are assumed always on and deasserted, respectively).

Similarly, control is not available for the I2C clock and reset, because the PCIe subsystem on the TC9564 relies on I2C

Co-developed-by Daniel Thompson <[email protected]>

Signed-off-by Daniel Thompson <[email protected]>

Signed-off-by Alex Elder <[email protected]>

---
 MAINTAINERS              |   1 +
 drivers/clk/Kconfig      |  11 ++
 drivers/clk/Makefile     |   1 +
 drivers/clk/clk-tc9564.c | 366 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 379 insertions(+)
 create mode 100644 drivers/clk/clk-tc9564.c

MAINTAINERS +1 -0

index 66d0e7e65adcb..39346a5cd9a7f 100644
@@ -27675,6 +27675,7 @@ M:	Alex Elder <[email protected]>
 M:	Daniel Thompson <[email protected]>
 S:	Maintained
 F:	Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
+F:	drivers/clk/clk-tc9564.c
 F:	include/dt-bindings/clock/toshiba,tc9564.h
 
 TOSHIBA TC9564 PCI DRIVER

drivers/clk/Kconfig +0 -0

index f9592fd9ec2bb..50efa10d48450 100644

drivers/clk/Kconfig +1 -0

+
 config CLK_TWL
 	tristate "Clock driver for the TWL PMIC family"
 	depends on TWL4030_CORE

drivers/clk/Makefile +1 -0

index b18af485d7f03..a98ea8ff92066 100644
@@ -110,6 +110,7 @@ obj-$(CONFIG_COMMON_CLK_SI570)		+= clk-si570.o
 obj-$(CONFIG_COMMON_CLK_SP7021)		+= clk-sp7021.o
 obj-$(CONFIG_COMMON_CLK_STM32F)		+= clk-stm32f4.o
 obj-$(CONFIG_COMMON_CLK_STM32H7)	+= clk-stm32h7.o
+obj-$(CONFIG_COMMON_CLK_TC9564)		+= clk-tc9564.o
 obj-$(CONFIG_COMMON_CLK_TPS68470)      += clk-tps68470.o
 obj-$(CONFIG_CLK_TWL6040)		+= clk-twl6040.o
 obj-$(CONFIG_CLK_TWL)			+= clk-twl.o

drivers/clk/clk-tc9564.c new file +0 -0

new file mode 100644
index 0000000000000..4f900bc8994a7

drivers/clk/clk-tc9564.c new file +52 -0

+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+#include <dt-bindings/clock/toshiba,tc9564.h>
+
+#define CLK_CTRL0_OFFSET	0x1004
+#define RST_CTRL0_OFFSET	0x1008
+#define CLK_CTRL1_OFFSET	0x100c
+#define RST_CTRL1_OFFSET	0x1010
+
+struct tc9564_clock_init {
+	const char *name;	/* NULL means unused entry */
+	u32 offset;
+	u32 mask;
+};
+
+struct tc9564_clock {
+	struct clk_hw hw;
+	u32 which;
+	u32 offset;		/* CLK_CTRL0_OFFSET or CLK_CTRL1_OFFSET */
+	u32 mask;		/* Zero means undefined clock */
+};
+
+struct tc9564_reset {
+	u32 offset;		/* RST_CTRL0_OFFSET or RST_CTRL1_OFFSET */
+	u32 mask;		/* Zero means undefined reset */
+};
+
+struct tc9564_clocks {
+	struct device *dev;
+	struct regmap *regmap;
+	struct reset_controller_dev rcdev;
+	size_t clock_count;
+	struct tc9564_clock clocks[] __counted_by(clock_count);
+};
+
+#define TC9564_CLOCK_INIT0(_name, _bit)	__TC9564_CLOCK_INIT(_name, 0, _bit)
+#define TC9564_CLOCK_INIT1(_name, _bit)	__TC9564_CLOCK_INIT(_name, 1, _bit)
+
+#define __TC9564_CLOCK_INIT(_name, _reg, _bit)		\
+	[CLOCK_##_name] = {				\
+		.name	= #_name,			\
+		.offset	= CLK_CTRL ## _reg ## _OFFSET,	\
+		.mask	= BIT(_bit),			\
+	}
+
+#define TC9564_RESET_INIT0(_name, _bit)	__TC9564_RESET_INIT(_name, 0, _bit)
+#define TC9564_RESET_INIT1(_name, _bit)	__TC9564_RESET_INIT(_name, 1, _bit)
+
+#define __TC9564_RESET_INIT(_name, _reg, _bit)		\

drivers/clk/clk-tc9564.c new file +203 -0

+	TC9564_CLOCK_INIT0(SRAM, 13),
+	TC9564_CLOCK_INIT0(UART, 16),
+	TC9564_CLOCK_INIT0(MSIGEN, 18),
+	TC9564_CLOCK_INIT0(PLL, 24),
+	TC9564_CLOCK_INIT0(SGMII, 25),
+	TC9564_CLOCK_INIT0(REFCLKO, 26),
+
+	TC9564_CLOCK_INIT0(MAC0_TX, 7),
+	TC9564_CLOCK_INIT0(MAC0_RX, 14),
+	TC9564_CLOCK_INIT0(MAC0_125M, 29),
+	TC9564_CLOCK_INIT0(MAC0_312_5M, 30),
+	TC9564_CLOCK_INIT0(MAC0_ALL, 31),
+
+	TC9564_CLOCK_INIT1(MAC1_TX, 7),
+	TC9564_CLOCK_INIT1(MAC1_RX, 14),
+	TC9564_CLOCK_INIT1(MAC1_RMII, 15),
+	TC9564_CLOCK_INIT1(MAC1_125M, 29),
+	TC9564_CLOCK_INIT1(MAC1_312_5M, 30),
+	TC9564_CLOCK_INIT1(MAC1_ALL, 31),
+};
+#define TC9564_CLOCK_COUNT	ARRAY_SIZE(tc9564_clock_init)
+
+static const struct tc9564_reset tc9564_reset[] = {
+	TC9564_RESET_INIT0(MCU, 0),
+	TC9564_RESET_INIT0(MCU1, 1),
+	TC9564_RESET_INIT0(INTC, 4),
+	/* TC9564_RESET_INIT0(PCIE, 9), */
+	/* TC9564_RESET_INIT0(I2C, 12), */
+	TC9564_RESET_INIT0(UART, 16),
+	TC9564_RESET_INIT0(MSIGEN, 18),
+
+	TC9564_RESET_INIT0(MAC0_MAC, 7),
+	TC9564_RESET_INIT0(MAC0_PMA, 30),
+	TC9564_RESET_INIT0(MAC0_XPCS, 31),
+
+	TC9564_RESET_INIT1(MAC1_MAC, 7),
+	TC9564_RESET_INIT1(MAC1_PMA, 30),
+	TC9564_RESET_INIT1(MAC1_XPCS, 31),
+};
+#define TC9564_RESET_COUNT	ARRAY_SIZE(tc9564_reset)
+
+static const struct tc9564_clock *hw_to_tc9564_clock(struct clk_hw *hw)
+{
+	return container_of_const(hw, struct tc9564_clock, hw);
+}
+
+static const struct tc9564_clocks *
+tc9564_clock_to_clocks(const struct tc9564_clock *clock)
+{
+	u32 which = clock->which;
+
+	if (which >= TC9564_CLOCK_COUNT)
+		return ERR_PTR(-ENXIO);
+
+	return container_of_const(clock, struct tc9564_clocks, clocks[which]);
+}
+
+static int tc9564_clk_manage(struct clk_hw *hw, bool enable)
+{
+	const struct tc9564_clock *clock = hw_to_tc9564_clock(hw);
+	const struct tc9564_clocks *clocks;
+	u32 offset = clock->offset;
+	u32 mask = clock->mask;
+
+	clocks = tc9564_clock_to_clocks(clock);
+	if (IS_ERR(clocks) || !mask) {
+		dev_err(clk_hw_get_dev(hw), "invalid clock (%s id %u)\n",
+			enable ? "enable" : "disable", clock->which);
+		return -ENXIO;
+	}
+
+	return regmap_update_bits(clocks->regmap, offset, mask,
+				  enable ? mask : 0);
+}
+
+static int tc9564_clk_enable(struct clk_hw *hw)
+{
+	return tc9564_clk_manage(hw, true);
+}
+
+static void tc9564_clk_disable(struct clk_hw *hw)
+{
+	(void)tc9564_clk_manage(hw, false);
+}
+
+static const struct clk_ops tc9564_clk_ops = {
+	.enable = tc9564_clk_enable,
+	.disable = tc9564_clk_disable,
+};
+
+static void tc9564_clock_disable_all(struct tc9564_clocks *clocks)
+{
+	for (int i = 0; i < clocks->clock_count; i++) {
+		const struct tc9564_clock *clock = &clocks->clocks[i];
+
+		if (clock->mask)
+			regmap_update_bits(clocks->regmap, clock->offset,
+					   clock->mask, 0);
+	}
+}
+
+static struct clk_hw *tc9564_clk_hw_get(struct of_phandle_args *clkspec,
+					void *data)
+{
+	struct tc9564_clocks *clocks = data;
+	unsigned int i = clkspec->args[0];
+
+	if (i < clocks->clock_count)
+		return &clocks->clocks[i].hw;
+
+	dev_err(clocks->dev, "invalid index %u\n", i);
+
+	return ERR_PTR(-EINVAL);
+}
+
+static struct tc9564_clocks *tc9564_clk_init(struct device *dev)
+{
+	struct tc9564_clocks *clocks;
+	size_t clocks_size;
+	int ret;
+
+	clocks_size = struct_size(clocks, clocks, TC9564_CLOCK_COUNT);
+	clocks = devm_kzalloc(dev, clocks_size, GFP_KERNEL);
+	if (!clocks)
+		return ERR_PTR(-ENOMEM);
+
+	clocks->dev = dev;
+	clocks->clock_count = TC9564_CLOCK_COUNT;
+
+	clocks->regmap = syscon_node_to_regmap(dev_of_node(dev->parent));
+	if (IS_ERR(clocks->regmap)) {
+		dev_err(dev, "failed to get config regmap\n");
+		return ERR_CAST(clocks->regmap);
+	}
+
+	for (u32 i = 0; i < TC9564_CLOCK_COUNT; i++) {
+		const struct tc9564_clock_init *clock_init;
+		struct clk_init_data init = { };
+		struct tc9564_clock *clock;
+
+		clock_init = &tc9564_clock_init[i];
+		if (!clock_init->name)
+			continue;
+
+		init.name = clock_init->name;
+		init.ops = &tc9564_clk_ops;
+
+		clock = &clocks->clocks[i];
+		clock->hw.init = &init;
+
+		ret = devm_clk_hw_register(dev, &clock->hw);
+		if (ret) {
+			dev_err(dev, "failed to register clock \"%s\"\n",
+				init.name);
+			return ERR_PTR(ret);
+		}
+
+		clock->which = i;
+		clock->offset = clock_init->offset;
+		clock->mask = clock_init->mask;
+	}
+
+	ret = devm_of_clk_add_hw_provider(dev, tc9564_clk_hw_get, clocks);
+	if (ret) {
+		dev_err(dev, "failed to add clock hardware provider\n");
+		return ERR_PTR(ret);
+	}
+
+	return clocks;
+}
+
+static const struct tc9564_clocks *
+rcdev_to_tc9564_clocks(struct reset_controller_dev *rcdev)
+{
+	return container_of_const(rcdev, struct tc9564_clocks, rcdev);
+}
+
+static int tc9564_reset_manage(struct reset_controller_dev *rcdev,
+			       unsigned long id, bool assert)
+{
+	const struct tc9564_clocks *clocks = rcdev_to_tc9564_clocks(rcdev);
+
+	if (id < rcdev->nr_resets) {
+		const struct tc9564_reset *reset = &tc9564_reset[id];
+		u32 mask = reset->mask;
+
+		if (mask)
+			return regmap_update_bits(clocks->regmap,
+						  reset->offset, mask,
+						  assert ? mask : 0);
+	}
+
+	dev_err(clocks->dev, "invalid reset (%sassert id %lu)\n",
+		assert ? "" : "de", id);
+
+	return -ENXIO;
+}
+
+static int tc9564_reset_assert(struct reset_controller_dev *rcdev,
+			       unsigned long id)
+{
+	return tc9564_reset_manage(rcdev, id, true);
+}

drivers/clk/clk-tc9564.c new file +47 -0

+};
+
+static void tc9564_reset_assert_all(struct tc9564_clocks *clocks)
+{
+	for (u32 id = 0; id < TC9564_RESET_COUNT; id++)
+		if (tc9564_reset[id].mask)
+			tc9564_reset_manage(&clocks->rcdev, id, true);
+}
+
+static int tc9564_reset_init(struct tc9564_clocks *clocks)
+{
+	struct reset_controller_dev *rcdev = &clocks->rcdev;
+
+	rcdev->ops = &tc9564_reset_control_ops;
+	rcdev->owner = THIS_MODULE;
+	rcdev->dev = clocks->dev;
+	rcdev->of_node = dev_of_node(clocks->dev);
+	rcdev->nr_resets = TC9564_RESET_COUNT;
+
+	return devm_reset_controller_register(clocks->dev, rcdev);
+}
+
+static int tc9564_clk_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct tc9564_clocks *clocks;
+	int ret;
+
+	if (!dev_of_node(dev))
+		return dev_err_probe(dev, -EINVAL, "no devicetree node\n");
+
+	clocks = tc9564_clk_init(dev);
+	if (IS_ERR(clocks))
+		return dev_err_probe(dev, PTR_ERR(clocks),
+				     "failed to initialize clocks\n");
+
+	ret = tc9564_reset_init(clocks);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to initialize resets\n");
+
+	/* Force all resets to be initially asserted */
+	tc9564_reset_assert_all(clocks);
+
+	/* Force all clocks to be initially disabled */
+	tc9564_clock_disable_all(clocks);
+
+	platform_set_drvdata(pdev, clocks);

drivers/clk/clk-tc9564.c new file +24 -0

+
+	/* Leave all clocks disabled when done */
+	tc9564_clock_disable_all(clocks);
+}
+
+static const struct of_device_id tc9564_clk_ids[] = {
+	{ .compatible = "toshiba,tc9564-clock" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, tc9564_clk_ids);
+
+static struct platform_driver tc9564_clk_driver = {
+	.probe	= tc9564_clk_probe,
+	.remove	= tc9564_clk_remove,
+	.driver	= {
+		.name		= KBUILD_MODNAME,
+		.of_match_table = tc9564_clk_ids,
+		.probe_type	= PROBE_PREFER_ASYNCHRONOUS,
+	},
+};
+module_platform_driver(tc9564_clk_driver);
+
+MODULE_DESCRIPTION("Toshiba TC9564 Clock and Reset Driver");
+MODULE_LICENSE("GPL");

Signature · 1 line

2.53.0

Hi Alex,

Quoted 48 lines · Alex Elder

Define a new platform driver that manages clock and reset signals within the TC9564 SoC. There are 21 clocks, which can only be enabled and disabled, as well as 13 reset signals.

Two registers manage the state of the clocks and two others manage the state of the resets. The registers are accessed via a regmap supplied by a system controller, which coordinates access to a region of memory that will be shared with another driver.

Access to the memory region is provided via a BAR on a PCIe endpoint function embedded in the TC9564 SoC. For that reason, neither the PCIe clock nor PCIe reset can be manipulated by this driver (they are assumed always on and deasserted, respectively).

Similarly, control is not available for the I2C clock and reset, because the PCIe subsystem on the TC9564 relies on I2C

Co-developed-by Daniel Thompson <[email protected]>

Signed-off-by Daniel Thompson <[email protected]>

Signed-off-by Alex Elder <[email protected]>

---
  MAINTAINERS              |   1 +
  drivers/clk/Kconfig      |  11 ++
  drivers/clk/Makefile     |   1 +
  drivers/clk/clk-tc9564.c | 366 +++++++++++++++++++++++++++++++++++++++
  4 files changed, 379 insertions(+)

create mode 100644 drivers/clk/clk-tc9564.c

MAINTAINERS +1 -0

index 66d0e7e65adcb..39346a5cd9a7f 100644
@@ -27675,6 +27675,7 @@ M:	Alex Elder <[email protected]>
  M:	Daniel Thompson <[email protected]>
  S:	Maintained
  F:	Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
+F:	drivers/clk/clk-tc9564.c
  F:	include/dt-bindings/clock/toshiba,tc9564.h
 
  TOSHIBA TC9564 PCI DRIVER

drivers/clk/Kconfig +0 -0

index f9592fd9ec2bb..50efa10d48450 100644
@@ -292,6 +292,17 @@ config COMMON_CLK_S2MPS11
  	  clock. These multi-function devices have two (S2MPS14) or three
  	  (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
 

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 297

Quoted 3 lines

drivers/clk/Kconfig +3 -0

+config COMMON_CLK_TC9564
+	tristate "Toshiba TC9564 clock support"
+	depends on TC9564_PCI

select RESET_CONTROLLER

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 298

Quoted 2 lines

drivers/clk/Kconfig +1 -0

+	default m

default n

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 304

Quoted 6 lines

drivers/clk/Kconfig +6 -0

+	help
+	  This enables support for the clock and reset controller embedded
+	  in the Toshiba TC9564 (and Qualcomm QPS615) SoC.  The state of
+	  clock and reset lines is controlled by MMIO to a region managed
+	  by a system controller; this ensures access to the region is
+	  coordinated between this and other drivers.

Rather than 'other drivers', outline specifically which other drivers.

Quoted 26 lines

drivers/clk/Kconfig +1 -0

+
  config CLK_TWL
  	tristate "Clock driver for the TWL PMIC family"
  	depends on TWL4030_CORE

drivers/clk/Makefile +1 -0

index b18af485d7f03..a98ea8ff92066 100644
@@ -110,6 +110,7 @@ obj-$(CONFIG_COMMON_CLK_SI570)		+= clk-si570.o
  obj-$(CONFIG_COMMON_CLK_SP7021)		+= clk-sp7021.o
  obj-$(CONFIG_COMMON_CLK_STM32F)		+= clk-stm32f4.o
  obj-$(CONFIG_COMMON_CLK_STM32H7)	+= clk-stm32h7.o
+obj-$(CONFIG_COMMON_CLK_TC9564)		+= clk-tc9564.o
  obj-$(CONFIG_COMMON_CLK_TPS68470)      += clk-tps68470.o
  obj-$(CONFIG_CLK_TWL6040)		+= clk-twl6040.o
  obj-$(CONFIG_CLK_TWL)			+= clk-twl.o

drivers/clk/clk-tc9564.c new file +4 -0

new file mode 100644
index 0000000000000..4f900bc8994a7
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.

drivers/clk/clk-tc9564.c line 10

Quoted 6 lines

drivers/clk/clk-tc9564.c new file +6 -0

+ */
+
+#include <linux/bits.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mod_devicetable.h>

Uwe already pointed out removing this.

Quoted 59 lines

drivers/clk/clk-tc9564.c new file +58 -0

+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+#include <dt-bindings/clock/toshiba,tc9564.h>
+
+#define CLK_CTRL0_OFFSET	0x1004
+#define RST_CTRL0_OFFSET	0x1008
+#define CLK_CTRL1_OFFSET	0x100c
+#define RST_CTRL1_OFFSET	0x1010
+
+struct tc9564_clock_init {
+	const char *name;	/* NULL means unused entry */
+	u32 offset;
+	u32 mask;
+};
+
+struct tc9564_clock {
+	struct clk_hw hw;
+	u32 which;
+	u32 offset;		/* CLK_CTRL0_OFFSET or CLK_CTRL1_OFFSET */
+	u32 mask;		/* Zero means undefined clock */
+};
+
+struct tc9564_reset {
+	u32 offset;		/* RST_CTRL0_OFFSET or RST_CTRL1_OFFSET */
+	u32 mask;		/* Zero means undefined reset */
+};
+
+struct tc9564_clocks {
+	struct device *dev;
+	struct regmap *regmap;
+	struct reset_controller_dev rcdev;
+	size_t clock_count;
+	struct tc9564_clock clocks[] __counted_by(clock_count);
+};
+
+#define TC9564_CLOCK_INIT0(_name, _bit)	__TC9564_CLOCK_INIT(_name, 0, _bit)
+#define TC9564_CLOCK_INIT1(_name, _bit)	__TC9564_CLOCK_INIT(_name, 1, _bit)
+
+#define __TC9564_CLOCK_INIT(_name, _reg, _bit)		\
+	[CLOCK_##_name] = {				\
+		.name	= #_name,			\
+		.offset	= CLK_CTRL ## _reg ## _OFFSET,	\
+		.mask	= BIT(_bit),			\
+	}
+
+#define TC9564_RESET_INIT0(_name, _bit)	__TC9564_RESET_INIT(_name, 0, _bit)
+#define TC9564_RESET_INIT1(_name, _bit)	__TC9564_RESET_INIT(_name, 1, _bit)
+
+#define __TC9564_RESET_INIT(_name, _reg, _bit)		\
+	[RESET_##_name] = {				\
+		.offset	= RST_CTRL ## _reg ## _OFFSET,	\
+		.mask = BIT(_bit),			\
+	}
+
+static const struct tc9564_clock_init tc9564_clock_init[] = {

drivers/clk/clk-tc9564.c line 72

Quoted 4 lines

drivers/clk/clk-tc9564.c new file +4 -0

+	TC9564_CLOCK_INIT0(MCU, 0),
+	TC9564_CLOCK_INIT0(INTC, 4),
+	/* TC9564_CLOCK_INIT0(PCIE, 9), */
+	/* TC9564_CLOCK_INIT0(I2C, 12), */

A comment would be useful here to outline why these are commented out. Is the PCIE one comment out because of what's outlined in the commit message?

drivers/clk/clk-tc9564.c line 78

Quoted 7 lines

drivers/clk/clk-tc9564.c new file +6 -0

+	TC9564_CLOCK_INIT0(SRAM, 13),
+	TC9564_CLOCK_INIT0(UART, 16),
+	TC9564_CLOCK_INIT0(MSIGEN, 18),
+	TC9564_CLOCK_INIT0(PLL, 24),
+	TC9564_CLOCK_INIT0(SGMII, 25),
+	TC9564_CLOCK_INIT0(REFCLKO, 26),

drivers/clk/clk-tc9564.c line 285

Quoted 3 lines

drivers/clk/clk-tc9564.c new file +3 -0

+static const struct reset_control_ops tc9564_reset_control_ops = {
+	.assert		= tc9564_reset_assert,
+	.deassert	= tc9564_reset_deassert,

I'd rather not have the extra spaces because sometimes these get out of line with new members that need more space. Also tc9564_clk_ops above doesn't have the extra spaces.

Quoted 52 lines

drivers/clk/clk-tc9564.c new file +51 -0

+};
+
+static void tc9564_reset_assert_all(struct tc9564_clocks *clocks)
+{
+	for (u32 id = 0; id < TC9564_RESET_COUNT; id++)
+		if (tc9564_reset[id].mask)
+			tc9564_reset_manage(&clocks->rcdev, id, true);
+}
+
+static int tc9564_reset_init(struct tc9564_clocks *clocks)
+{
+	struct reset_controller_dev *rcdev = &clocks->rcdev;
+
+	rcdev->ops = &tc9564_reset_control_ops;
+	rcdev->owner = THIS_MODULE;
+	rcdev->dev = clocks->dev;
+	rcdev->of_node = dev_of_node(clocks->dev);
+	rcdev->nr_resets = TC9564_RESET_COUNT;
+
+	return devm_reset_controller_register(clocks->dev, rcdev);
+}
+
+static int tc9564_clk_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct tc9564_clocks *clocks;
+	int ret;
+
+	if (!dev_of_node(dev))
+		return dev_err_probe(dev, -EINVAL, "no devicetree node\n");
+
+	clocks = tc9564_clk_init(dev);
+	if (IS_ERR(clocks))
+		return dev_err_probe(dev, PTR_ERR(clocks),
+				     "failed to initialize clocks\n");
+
+	ret = tc9564_reset_init(clocks);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to initialize resets\n");
+
+	/* Force all resets to be initially asserted */
+	tc9564_reset_assert_all(clocks);
+
+	/* Force all clocks to be initially disabled */
+	tc9564_clock_disable_all(clocks);
+
+	platform_set_drvdata(pdev, clocks);
+
+	return 0;
+}
+

drivers/clk/clk-tc9564.c line 342

Quoted 6 lines

drivers/clk/clk-tc9564.c new file +6 -0

+static void tc9564_clk_remove(struct platform_device *pdev)
+{
+	struct tc9564_clocks *clocks = platform_get_drvdata(pdev);
+
+	/* Leave all resets to be deasserted when done */
+	tc9564_reset_assert_all(clocks);

The comment says deasserted but the code calls assert_all.

Brian

Quoted 27 lines

drivers/clk/clk-tc9564.c new file +24 -0

+
+	/* Leave all clocks disabled when done */
+	tc9564_clock_disable_all(clocks);
+}
+
+static const struct of_device_id tc9564_clk_ids[] = {
+	{ .compatible = "toshiba,tc9564-clock" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, tc9564_clk_ids);
+
+static struct platform_driver tc9564_clk_driver = {
+	.probe	= tc9564_clk_probe,
+	.remove	= tc9564_clk_remove,
+	.driver	= {
+		.name		= KBUILD_MODNAME,
+		.of_match_table = tc9564_clk_ids,
+		.probe_type	= PROBE_PREFER_ASYNCHRONOUS,
+	},
+};
+module_platform_driver(tc9564_clk_driver);
+
+MODULE_DESCRIPTION("Toshiba TC9564 Clock and Reset Driver");
+MODULE_LICENSE("GPL");

Signature · 1 line

2.53.0

Quoted 51 lines · Brian Masney

Hi Alex,

Quoted 48 lines · Alex Elder

Define a new platform driver that manages clock and reset signals within the TC9564 SoC. There are 21 clocks, which can only be enabled and disabled, as well as 13 reset signals.

Two registers manage the state of the clocks and two others manage the state of the resets. The registers are accessed via a regmap supplied by a system controller, which coordinates access to a region of memory that will be shared with another driver.

Access to the memory region is provided via a BAR on a PCIe endpoint function embedded in the TC9564 SoC. For that reason, neither the PCIe clock nor PCIe reset can be manipulated by this driver (they are assumed always on and deasserted, respectively).

Similarly, control is not available for the I2C clock and reset, because the PCIe subsystem on the TC9564 relies on I2C

Co-developed-by Daniel Thompson <[email protected]>

Signed-off-by Daniel Thompson <[email protected]>

Signed-off-by Alex Elder <[email protected]>

---
  MAINTAINERS              |   1 +
  drivers/clk/Kconfig      |  11 ++
  drivers/clk/Makefile     |   1 +
  drivers/clk/clk-tc9564.c | 366 +++++++++++++++++++++++++++++++++++++++
  4 files changed, 379 insertions(+)

create mode 100644 drivers/clk/clk-tc9564.c

MAINTAINERS +1 -0

index 66d0e7e65adcb..39346a5cd9a7f 100644
@@ -27675,6 +27675,7 @@ M:	Alex Elder <[email protected]>
  M:	Daniel Thompson <[email protected]>
  S:	Maintained
  F:	Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
+F:	drivers/clk/clk-tc9564.c
  F:	include/dt-bindings/clock/toshiba,tc9564.h
 
  TOSHIBA TC9564 PCI DRIVER

drivers/clk/Kconfig +0 -0

index f9592fd9ec2bb..50efa10d48450 100644
@@ -292,6 +292,17 @@ config COMMON_CLK_S2MPS11
  	  clock. These multi-function devices have two (S2MPS14) or three
  	  (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
 

Quoted 5 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 297

Quoted 3 lines

drivers/clk/Kconfig +3 -0

+config COMMON_CLK_TC9564
+	tristate "Toshiba TC9564 clock support"
+	depends on TC9564_PCI

select RESET_CONTROLLER

Thank you. The reset and clock drivers were previously separate and the reset only became available if RESET_CONTROLLER was enabled. Combining them means I need this. I will add it.

I also need to select MFD_SYSCON to get syscon_node_to_regmap() (or perhaps something similar, depending on the answers to my questions about the proper way to define the syscon).

Quoted 4 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 298

Quoted 2 lines

drivers/clk/Kconfig +1 -0

+	default m

default n

This depends on TC9564_PCI, and if TC9564_PCI is enabled I would like this to (automatically) be available (at least as a module).

Why do you recommend "n"?

Quoted 8 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 304

Quoted 6 lines

drivers/clk/Kconfig +6 -0

+	help
+	  This enables support for the clock and reset controller embedded
+	  in the Toshiba TC9564 (and Qualcomm QPS615) SoC.  The state of
+	  clock and reset lines is controlled by MMIO to a region managed
+	  by a system controller; this ensures access to the region is
+	  coordinated between this and other drivers.

Rather than 'other drivers', outline specifically which other drivers.

I was intentionally vague at this point because the one other driver has not yet gone out for upstream review for this iteration of the code. But I do agree with you, so I'll change this to say:

... between this and the XGMAC (stmmac) driver.

Then it will be correct without modification once that driver goes out for review. Is that better, or do you suggest something else?

Quoted 26 lines

Quoted 26 lines

drivers/clk/Kconfig +1 -0

+
  config CLK_TWL
  	tristate "Clock driver for the TWL PMIC family"
  	depends on TWL4030_CORE

drivers/clk/Makefile +1 -0

index b18af485d7f03..a98ea8ff92066 100644
@@ -110,6 +110,7 @@ obj-$(CONFIG_COMMON_CLK_SI570)		+= clk-si570.o
  obj-$(CONFIG_COMMON_CLK_SP7021)		+= clk-sp7021.o
  obj-$(CONFIG_COMMON_CLK_STM32F)		+= clk-stm32f4.o
  obj-$(CONFIG_COMMON_CLK_STM32H7)	+= clk-stm32h7.o
+obj-$(CONFIG_COMMON_CLK_TC9564)		+= clk-tc9564.o
  obj-$(CONFIG_COMMON_CLK_TPS68470)      += clk-tps68470.o
  obj-$(CONFIG_CLK_TWL6040)		+= clk-twl6040.o
  obj-$(CONFIG_CLK_TWL)			+= clk-twl.o

drivers/clk/clk-tc9564.c new file +4 -0

new file mode 100644
index 0000000000000..4f900bc8994a7
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.

Quoted 8 lines

drivers/clk/clk-tc9564.c line 10

Quoted 6 lines

drivers/clk/clk-tc9564.c new file +6 -0

+ */
+
+#include <linux/bits.h>
+#include <linux/clk-provider.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mod_devicetable.h>

Uwe already pointed out removing this.

Yes, done.

Quoted 59 lines

Quoted 59 lines

drivers/clk/clk-tc9564.c new file +58 -0

+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+#include <dt-bindings/clock/toshiba,tc9564.h>
+
+#define CLK_CTRL0_OFFSET	0x1004
+#define RST_CTRL0_OFFSET	0x1008
+#define CLK_CTRL1_OFFSET	0x100c
+#define RST_CTRL1_OFFSET	0x1010
+
+struct tc9564_clock_init {
+	const char *name;	/* NULL means unused entry */
+	u32 offset;
+	u32 mask;
+};
+
+struct tc9564_clock {
+	struct clk_hw hw;
+	u32 which;
+	u32 offset;		/* CLK_CTRL0_OFFSET or CLK_CTRL1_OFFSET */
+	u32 mask;		/* Zero means undefined clock */
+};
+
+struct tc9564_reset {
+	u32 offset;		/* RST_CTRL0_OFFSET or RST_CTRL1_OFFSET */
+	u32 mask;		/* Zero means undefined reset */
+};
+
+struct tc9564_clocks {
+	struct device *dev;
+	struct regmap *regmap;
+	struct reset_controller_dev rcdev;
+	size_t clock_count;
+	struct tc9564_clock clocks[] __counted_by(clock_count);
+};
+
+#define TC9564_CLOCK_INIT0(_name, _bit)	__TC9564_CLOCK_INIT(_name, 0, _bit)
+#define TC9564_CLOCK_INIT1(_name, _bit)	__TC9564_CLOCK_INIT(_name, 1, _bit)
+
+#define __TC9564_CLOCK_INIT(_name, _reg, _bit)		\
+	[CLOCK_##_name] = {				\
+		.name	= #_name,			\
+		.offset	= CLK_CTRL ## _reg ## _OFFSET,	\
+		.mask	= BIT(_bit),			\
+	}
+
+#define TC9564_RESET_INIT0(_name, _bit)	__TC9564_RESET_INIT(_name, 0, _bit)
+#define TC9564_RESET_INIT1(_name, _bit)	__TC9564_RESET_INIT(_name, 1, _bit)
+
+#define __TC9564_RESET_INIT(_name, _reg, _bit)		\
+	[RESET_##_name] = {				\
+		.offset	= RST_CTRL ## _reg ## _OFFSET,	\
+		.mask = BIT(_bit),			\
+	}
+
+static const struct tc9564_clock_init tc9564_clock_init[] = {

Quoted 8 lines

drivers/clk/clk-tc9564.c line 72

Quoted 4 lines

drivers/clk/clk-tc9564.c new file +4 -0

+	TC9564_CLOCK_INIT0(MCU, 0),
+	TC9564_CLOCK_INIT0(INTC, 4),
+	/* TC9564_CLOCK_INIT0(PCIE, 9), */
+	/* TC9564_CLOCK_INIT0(I2C, 12), */

A comment would be useful here to outline why these are commented out. Is the PCIE one comment out because of what's outlined in the commit message?

Yes, that is why. We are downstream of PCIe, and PCIe in this case depends on I2C. So we don't want to mess with these two clocks or their reset counterparts.

I only provide this for the benefit of documentation. If someone happens to see bit 9 set in this register, it means the PCIe clock is enabled.

Anyway, others have suggested simply removing these comments. So I'll do what you suggest, but I'm interested to know whether you would favor just deleting them instead.

Quoted 7 lines

drivers/clk/clk-tc9564.c line 78

Quoted 7 lines

drivers/clk/clk-tc9564.c new file +6 -0

+	TC9564_CLOCK_INIT0(SRAM, 13),
+	TC9564_CLOCK_INIT0(UART, 16),
+	TC9564_CLOCK_INIT0(MSIGEN, 18),
+	TC9564_CLOCK_INIT0(PLL, 24),
+	TC9564_CLOCK_INIT0(SGMII, 25),
+	TC9564_CLOCK_INIT0(REFCLKO, 26),

. . .

Quoted 7 lines

drivers/clk/clk-tc9564.c line 285

Quoted 3 lines

drivers/clk/clk-tc9564.c new file +3 -0

+static const struct reset_control_ops tc9564_reset_control_ops = {
+	.assert		= tc9564_reset_assert,
+	.deassert	= tc9564_reset_deassert,

I'd rather not have the extra spaces because sometimes these get out of line with new members that need more space. Also tc9564_clk_ops above doesn't have the extra spaces.

That's OK with me. I normally align assignments like this for readability, but it's obviously an arbitrary stylistic choice. I'll just use one space, no alignment (just as the clk_ops do above). I'll do the same in the platform driver structure assignments.

Quoted 52 lines

Quoted 52 lines

drivers/clk/clk-tc9564.c new file +51 -0

+};
+
+static void tc9564_reset_assert_all(struct tc9564_clocks *clocks)
+{
+	for (u32 id = 0; id < TC9564_RESET_COUNT; id++)
+		if (tc9564_reset[id].mask)
+			tc9564_reset_manage(&clocks->rcdev, id, true);
+}
+
+static int tc9564_reset_init(struct tc9564_clocks *clocks)
+{
+	struct reset_controller_dev *rcdev = &clocks->rcdev;
+
+	rcdev->ops = &tc9564_reset_control_ops;
+	rcdev->owner = THIS_MODULE;
+	rcdev->dev = clocks->dev;
+	rcdev->of_node = dev_of_node(clocks->dev);
+	rcdev->nr_resets = TC9564_RESET_COUNT;
+
+	return devm_reset_controller_register(clocks->dev, rcdev);
+}
+
+static int tc9564_clk_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct tc9564_clocks *clocks;
+	int ret;
+
+	if (!dev_of_node(dev))
+		return dev_err_probe(dev, -EINVAL, "no devicetree node\n");
+
+	clocks = tc9564_clk_init(dev);
+	if (IS_ERR(clocks))
+		return dev_err_probe(dev, PTR_ERR(clocks),
+				     "failed to initialize clocks\n");
+
+	ret = tc9564_reset_init(clocks);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to initialize resets\n");
+
+	/* Force all resets to be initially asserted */
+	tc9564_reset_assert_all(clocks);
+
+	/* Force all clocks to be initially disabled */
+	tc9564_clock_disable_all(clocks);
+
+	platform_set_drvdata(pdev, clocks);
+
+	return 0;
+}
+

Quoted 8 lines

drivers/clk/clk-tc9564.c line 342

Quoted 6 lines

drivers/clk/clk-tc9564.c new file +6 -0

+static void tc9564_clk_remove(struct platform_device *pdev)
+{
+	struct tc9564_clocks *clocks = platform_get_drvdata(pdev);
+
+	/* Leave all resets to be deasserted when done */
+	tc9564_reset_assert_all(clocks);

The comment says deasserted but the code calls assert_all.

Oops. Will fix. Thank you very much for your review Brian.

-Alex

Quoted 32 lines

Brian

Quoted 27 lines

drivers/clk/clk-tc9564.c new file +24 -0

+
+	/* Leave all clocks disabled when done */
+	tc9564_clock_disable_all(clocks);
+}
+
+static const struct of_device_id tc9564_clk_ids[] = {
+	{ .compatible = "toshiba,tc9564-clock" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, tc9564_clk_ids);
+
+static struct platform_driver tc9564_clk_driver = {
+	.probe	= tc9564_clk_probe,
+	.remove	= tc9564_clk_remove,
+	.driver	= {
+		.name		= KBUILD_MODNAME,
+		.of_match_table = tc9564_clk_ids,
+		.probe_type	= PROBE_PREFER_ASYNCHRONOUS,
+	},
+};
+module_platform_driver(tc9564_clk_driver);
+
+MODULE_DESCRIPTION("Toshiba TC9564 Clock and Reset Driver");
+MODULE_LICENSE("GPL");

Signature · 1 line

2.53.0

Quoted 12 lines

Quoted 12 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 297

Quoted 11 lines

drivers/clk/Kconfig +3 -0

index f9592fd9ec2bb..50efa10d48450 100644
@@ -292,6 +292,17 @@ config COMMON_CLK_S2MPS11
   	  clock. These multi-function devices have two (S2MPS14) or three
   	  (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
 
+config COMMON_CLK_TC9564
+	tristate "Toshiba TC9564 clock support"
+	depends on TC9564_PCI

select RESET_CONTROLLER

Quoted 3 lines

Thank you. The reset and clock drivers were previously separate and the reset only became available if RESET_CONTROLLER was enabled. Combining them means I need this. I will add it.

Why did you combine them ?

it would be a lot better if the reset were handled in drivers/reset rather than in clock. There has already been some work to move reset from clock back to reset. This often involve auxiliary drivers.

Quoted 12 lines · Jerome Brunet

Quoted 12 lines

Quoted 12 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 297

Quoted 11 lines

drivers/clk/Kconfig +3 -0

index f9592fd9ec2bb..50efa10d48450 100644
@@ -292,6 +292,17 @@ config COMMON_CLK_S2MPS11
   	  clock. These multi-function devices have two (S2MPS14) or three
   	  (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
 
+config COMMON_CLK_TC9564
+	tristate "Toshiba TC9564 clock support"
+	depends on TC9564_PCI

select RESET_CONTROLLER

Quoted 8 lines

Quoted 3 lines

Thank you. The reset and clock drivers were previously separate and the reset only became available if RESET_CONTROLLER was enabled. Combining them means I need this. I will add it.

Why did you combine them ?

it would be a lot better if the reset were handled in drivers/reset rather than in clock. There has already been some work to move reset from clock back to reset. This often involve auxiliary drivers.

To be honest, I got a suggestion from someone to combine them, but I said "no, I got feedback last year that separating them was better." But then a second person told me that these are often combined, so I took that as "two against one" and decided to merge them.

The other reason is that four registers are used:

   #define CLK_CTRL0_OFFSET	0x1004
   #define RST_CTRL0_OFFSET	0x1008
   #define CLK_CTRL1_OFFSET	0x100c
   define RST_CTRL1_OFFSET	0x1010

They alternate between clock and reset. The previous separated drivers specified the two offsets for each driver in the reg property. But somehow these interleaved registers seemed a little off, so I thought the combined driver cleaned that up a little.

I don't have any strong preference one way or another. If you think they're better separate, I don't mind separating them again. The two drivers are extremely simple.

-Alex

Quoted 44 lines · Brian Masney

Quoted 43 lines · Alex Elder

Define a new platform driver that manages clock and reset signals within the TC9564 SoC. There are 21 clocks, which can only be enabled and disabled, as well as 13 reset signals.

Two registers manage the state of the clocks and two others manage the state of the resets. The registers are accessed via a regmap supplied by a system controller, which coordinates access to a region of memory that will be shared with another driver.

Access to the memory region is provided via a BAR on a PCIe endpoint function embedded in the TC9564 SoC. For that reason, neither the PCIe clock nor PCIe reset can be manipulated by this driver (they are assumed always on and deasserted, respectively).

Similarly, control is not available for the I2C clock and reset, because the PCIe subsystem on the TC9564 relies on I2C

Co-developed-by Daniel Thompson <[email protected]>

Signed-off-by Daniel Thompson <[email protected]>

Signed-off-by Alex Elder <[email protected]>

---
  MAINTAINERS              |   1 +
  drivers/clk/Kconfig      |  11 ++
  drivers/clk/Makefile     |   1 +
  drivers/clk/clk-tc9564.c | 366 +++++++++++++++++++++++++++++++++++++++
  4 files changed, 379 insertions(+)

create mode 100644 drivers/clk/clk-tc9564.c

MAINTAINERS +1 -0

index 66d0e7e65adcb..39346a5cd9a7f 100644
@@ -27675,6 +27675,7 @@ M:	Alex Elder <[email protected]>
  M:	Daniel Thompson <[email protected]>
  S:	Maintained
  F:	Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
+F:	drivers/clk/clk-tc9564.c
  F:	include/dt-bindings/clock/toshiba,tc9564.h
  TOSHIBA TC9564 PCI DRIVER

drivers/clk/Kconfig +0 -0

index f9592fd9ec2bb..50efa10d48450 100644

Quoted 8 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 296

Quoted 6 lines

drivers/clk/Kconfig +3 -0

@@ -292,6 +292,17 @@ config COMMON_CLK_S2MPS11
  	  clock. These multi-function devices have two (S2MPS14) or three
  	  (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
+config COMMON_CLK_TC9564
+	tristate "Toshiba TC9564 clock support"
+	depends on TC9564_PCI

select RESET_CONTROLLER

Thank you. The reset and clock drivers were previously separate and the reset only became available if RESET_CONTROLLER was enabled. Combining them means I need this. I will add it.

I also need to select MFD_SYSCON to get syscon_node_to_regmap() (or perhaps something similar, depending on the answers to my questions about the proper way to define the syscon).

Quoted 1 line

Quoted 3 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 298

Quoted 1 line

drivers/clk/Kconfig +1 -0

+	default m

default n

This depends on TC9564_PCI, and if TC9564_PCI is enabled I would like this to (automatically) be available (at least as a module).

Why do you recommend "n"?

Quoted 8 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 304

Quoted 6 lines

drivers/clk/Kconfig +6 -0

+	help
+	  This enables support for the clock and reset controller embedded
+	  in the Toshiba TC9564 (and Qualcomm QPS615) SoC.  The state of
+	  clock and reset lines is controlled by MMIO to a region managed
+	  by a system controller; this ensures access to the region is
+	  coordinated between this and other drivers.

Rather than 'other drivers', outline specifically which other drivers.

I was intentionally vague at this point because the one other driver has not yet gone out for upstream review for this iteration of the code. But I do agree with you, so I'll change this to say:

... between this and the XGMAC (stmmac) driver.

Then it will be correct without modification once that driver goes out for review. Is that better, or do you suggest something else?

Quoted 9 lines

drivers/clk/Kconfig config COMMON_CLK_S2MPS11 · line 308

Quoted 5 lines

drivers/clk/Kconfig +5 -0

+static const struct tc9564_clock_init tc9564_clock_init[] = {
+	TC9564_CLOCK_INIT0(MCU, 0),
+	TC9564_CLOCK_INIT0(INTC, 4),
+	/* TC9564_CLOCK_INIT0(PCIE, 9), */
+	/* TC9564_CLOCK_INIT0(I2C, 12), */

A comment would be useful here to outline why these are commented out. Is the PCIE one comment out because of what's outlined in the commit message?

Yes, that is why. We are downstream of PCIe, and PCIe in this case depends on I2C. So we don't want to mess with these two clocks or their reset counterparts.

I only provide this for the benefit of documentation. If someone happens to see bit 9 set in this register, it means the PCIe clock is enabled.

Anyway, others have suggested simply removing these comments. So I'll do what you suggest, but I'm interested to know whether you would favor just deleting them instead.