[PATCH v2 0/3] clk: introduce TC9564 clock support

[PATCH v2 0/3] clk: introduce TC9564 clock support

[Alex Elder]

This series adds support for the clock controller present within
the Toshiba TC9564 SoC.

This SoC attaches to a host system via PCIe.  It includes a PCIe
switch with three downstream ports.  To one of these ports an
embedded PCIe endpoint is attached, and it implements two PCI
functions.  BAR 4 for both PCI functions provides access to the
registers that enable or disable a set of clocks.

Both TC9564 PCI functions provide PCI endpoint buses via devicetree.
Each PCI endpoint bus provides access to one of the function's BARs.
Subordinate devices (like the clock controller) can then be defined
as nodes accessible on the endpoint bus.

Only one of the two PCI functions is permitted to define the clock
device node.

					-Alex

NOTE:
    This series is built upon linux-next, with this patch applied:
      https://lore.kernel.org/lkml/20261002181849.790275-1-elder@riscstar.com/
    It is available in this git branch:
      https://github.com/alexelder/linux/tree/outgoing/clock-v2

Between version 1 and version 2:
  - Previously, this driver also included reset functionality.  That
    is now in a separate reset (only) driver, which will be sent for
    review separately
  - Dropped the "config syscon" devicetree binding
  - Reworded the clock binding description to focus on hardware only
  - Clock IDs are now consecutive (no more commented-out values)
  - Get the definition of of_device_id from <linux/device_id/of.h>
    rather than <linux/platform_device.h>
  - Dropped a comma that followed a ternminating empty array entry
  - Config option COMMON_CLK_TC9564 now selects MFD_SYSCON
  - Clarified in config help text that the reset and stmmac drivers
    are the "others" that use the config syscon
  - Moved the clock devicetree node to be a peer (rather than a child) of
    the syscon node.

Version 1 is available here:
  https://lore.kernel.org/lkml/20260918165234.687224-1-elder@riscstar.com/

Alex Elder (3):
  dt-bindings: clock: introduce toshiba,tc9564-clock.yaml
  clk: toshiba: introduce a TC9564 SoC clock driver
  arm64: dts: qcom: qcs6490-rb3gen2: add the clock controller

 .../bindings/clock/toshiba,tc9564-clock.yaml  |  54 ++++
 MAINTAINERS                                   |   8 +
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts  |  16 +-
 drivers/clk/Kconfig                           |  12 +
 drivers/clk/Makefile                          |   1 +
 drivers/clk/clk-tc9564.c                      | 262 ++++++++++++++++++
 include/dt-bindings/clock/toshiba,tc9564.h    |  34 +++
 7 files changed, 386 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
 create mode 100644 drivers/clk/clk-tc9564.c
 create mode 100644 include/dt-bindings/clock/toshiba,tc9564.h


base-commit: e8e67c48ac5cd9b0e7ba4ba2cef9decfa7327833
-- 
2.53.0

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

[Alex Elder]

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>
---
v2: - Only define clock information, not reset information
    - Reworded description to avoid talking about software
    - Clock IDs are now consecutive (no more commented-out values)

 .../bindings/clock/toshiba,tc9564-clock.yaml  | 54 +++++++++++++++++++
 MAINTAINERS                                   |  7 +++
 include/dt-bindings/clock/toshiba,tc9564.h    | 34 ++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
 create mode 100644 include/dt-bindings/clock/toshiba,tc9564.h

diff --git a/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
new file mode 100644
index 0000000000000..329b8f002cf2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/toshiba,tc9564-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC9564 Clock Controller
+
+maintainers:
+  - 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 (including a clock controller) via its BARs.
+
+  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.
+
+  Clock ids are defined in <dt-bindings/clock/toshiba,tc9564.h>.
+
+properties:
+  compatible:
+    const: toshiba,tc9564-clock
+
+  toshiba,config-syscon:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      Phandle for the configuration space system controller.
+
+  "#clock-cells":
+    const: 1
+
+required:
+  - compatible
+  - toshiba,config-syscon
+  - "#clock-cells"
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/toshiba,tc9564.h>
+
+    clock {
+        compatible = "toshiba,tc9564-clock";
+        toshiba,config-syscon = <&tc9564_config_syscon0>;
+        #clock-cells = <1>;
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index ff3bfd42d3f3a..860cf437574cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28128,6 +28128,13 @@ F:	Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.yaml
 F:	drivers/media/i2c/tc358743*
 F:	include/media/i2c/tc358743.h
 
+TOSHIBA TC9564 CLOCK DRIVER
+M:	Alex Elder <elder@kernel.org>
+M:	Daniel Thompson <danielt@kernel.org>
+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 <elder@kernel.org>
 M:	Daniel Thompson <danielt@kernel.org>
diff --git a/include/dt-bindings/clock/toshiba,tc9564.h b/include/dt-bindings/clock/toshiba,tc9564.h
new file mode 100644
index 0000000000000..2106e4199ed45
--- /dev/null
+++ b/include/dt-bindings/clock/toshiba,tc9564.h
@@ -0,0 +1,34 @@
+/* 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__
+
+/* Clock IDs */
+
+#define CLOCK_MCU		0
+#define CLOCK_INTC		1
+#define CLOCK_SRAM		2
+#define CLOCK_UART		3
+#define CLOCK_MSIGEN		4
+#define CLOCK_PLL		5
+#define CLOCK_SGMII		6
+#define CLOCK_REFCLKO		7
+
+#define CLOCK_MAC0_TX		8
+#define CLOCK_MAC0_RX		9
+#define CLOCK_MAC0_125M		10
+#define CLOCK_MAC0_312_5M	11
+#define CLOCK_MAC0_ALL		12
+
+#define CLOCK_MAC1_TX		13
+#define CLOCK_MAC1_RX		14
+#define CLOCK_MAC1_RMII		15
+#define CLOCK_MAC1_125M		16
+#define CLOCK_MAC1_312_5M	17
+#define CLOCK_MAC1_ALL		18
+
+#endif /* __CLOCK_TOSHIBA_TC9564_H__*/
-- 
2.53.0

[PATCH v2 2/3] clk: toshiba: introduce a TC9564 SoC clock driver

[Alex Elder]

Define a new platform driver that manages clocks implemented by the
Toshiba TC9564 SoC.  There are 21 clocks that can be enabled and
disabled.  Two of these are reserved, so only 19 can be managed.

Two registers manage the state of the clocks.  The registers are
accessed via a regmap supplied by a system controller, because the
region of memory accessed is shared with other drivers.

Access to the memory region is provided via a BAR on a PCIe endpoint
function embedded in the TC9564 SoC.  For that reason the PCIe clock
cannot be manipulated by this driver (it is assumed to be enabled).
Similarly, control is not available for the I2C clock, because the
PCIe subsystem on the TC9564 relies on I2C.

Co-developed-by: Daniel Thompson <daniel@riscstar.com>
Signed-off-by: Daniel Thompson <daniel@riscstar.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
---
v2: - Only implement clock functionality, not reset functionality
    - Get the definition of of_device_id from <linux/device_id/of.h>
    - Dropped a comma that followed a ternminating empty array entry
    - Config option COMMON_CLK_TC9564 now selects MFD_SYSCON
    - Clarified in config help text that the reset and stmmac drivers
      also use the config syscon

 MAINTAINERS              |   1 +
 drivers/clk/Kconfig      |  12 ++
 drivers/clk/Makefile     |   1 +
 drivers/clk/clk-tc9564.c | 262 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 276 insertions(+)
 create mode 100644 drivers/clk/clk-tc9564.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 860cf437574cf..18139dc2add92 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28133,6 +28133,7 @@ M:	Alex Elder <elder@kernel.org>
 M:	Daniel Thompson <danielt@kernel.org>
 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
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 37a8e35d41783..928fff40597ee 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -293,6 +293,18 @@ 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 MFD_SYSCON
+	default TC9564_PCI
+	help
+	  This enables support for the clock controller embedded in the
+	  Toshiba TC9564 SoC.  The state of each clock is controlled via
+	  MMIO to a region managed by a system controller; this ensures
+	  access to the region is coordinated between this and the reset
+	  and XGMAC (stmmac) drivers.
+
 config CLK_TWL
 	tristate "Clock driver for the TWL PMIC family"
 	depends on TWL4030_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 52d138d4ffc88..a11a8326d79cb 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -111,6 +111,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
diff --git a/drivers/clk/clk-tc9564.c b/drivers/clk/clk-tc9564.c
new file mode 100644
index 0000000000000..2e90e85b6215f
--- /dev/null
+++ b/drivers/clk/clk-tc9564.c
@@ -0,0 +1,262 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */
+
+#include <linux/bits.h>
+#include <linux/clk-provider.h>
+#include <linux/device-id/of.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/string_choices.h>
+
+#include <dt-bindings/clock/toshiba,tc9564.h>
+
+#define CLK_CTRL0_OFFSET	0x1004
+#define CLK_CTRL1_OFFSET	0x100c
+
+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_clocks {
+	struct device *dev;
+	struct regmap *regmap;
+	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),			\
+	}
+
+/*
+ * The PCIe and I2C clocks are controllable, but we depend on PCIe
+ * and that relies on I2C, so we don't allow them to be disabled.
+ */
+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), */
+	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_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(clocks->dev, "invalid clock (%s id %u)\n",
+			str_enable_disable(enable), 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 (u32 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;
+	u32 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;
+	struct regmap *regmap;
+	size_t clocks_size;
+	int ret;
+
+	regmap = syscon_regmap_lookup_by_phandle(dev_of_node(dev),
+						 "toshiba,config-syscon");
+	if (IS_ERR(regmap)) {
+		dev_err(dev, "failed to get config regmap\n");
+		return ERR_CAST(regmap);
+	}
+
+	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->regmap = regmap;
+	clocks->clock_count = TC9564_CLOCK_COUNT;
+
+	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 int tc9564_clk_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct tc9564_clocks *clocks;
+
+	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");
+
+	/* Force all clocks to be initially disabled */
+	tc9564_clock_disable_all(clocks);
+
+	platform_set_drvdata(pdev, clocks);
+
+	return 0;
+}
+
+static void tc9564_clk_remove(struct platform_device *pdev)
+{
+	struct tc9564_clocks *clocks = platform_get_drvdata(pdev);
+
+	/* 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 Driver");
+MODULE_LICENSE("GPL");
-- 
2.53.0

[PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: add the clock controller

[Alex Elder]

The clock controller within the TC9564 SoC is accessed via a PCI
endpoint bus through BAR 4 of the first embedded PCIe function.
A syscon node is created to provide access to a range of memory
that is used by the clock controller and shared with other devices.

Co-developed-by: Daniel Thompson <daniel@riscstar.com>
Signed-off-by: Daniel Thompson <daniel@riscstar.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
---
v2: - Moved the clock devicetree node to be a peer (rather than a child) of
      the syscon node

 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index 0e3bbdaf4661f..06246d185b50f 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -9,6 +9,7 @@
 #define PM7250B_SID 8
 #define PM7250B_SID1 9
 
+#include <dt-bindings/clock/toshiba,tc9564.h>
 #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
 #include <dt-bindings/iio/qcom,spmi-adc7-pm7325.h>
 #include <dt-bindings/leds/common.h>
@@ -961,7 +962,7 @@ dev@0,0 {
 				#size-cells = <2>;
 				ranges;	/* This will be updated dynamically */
 
-				pci-ep-bus@4 {
+				pcie_s1b5d0f0_bar4_bus: pci-ep-bus@4 {
 					compatible = "simple-bus";
 					#address-cells = <1>;
 					#size-cells = <1>;
@@ -989,6 +990,19 @@ pci-ep-bus@4 {
 	};
 };
 
+&pcie_s1b5d0f0_bar4_bus {
+	tc9564_config_syscon0: syscon@0 {
+		compatible = "syscon";
+		reg = <0x0 0x2000>;
+	};
+
+	tc9564_clock0: clock {
+		compatible = "toshiba,tc9564-clock";
+		toshiba,config-syscon = <&tc9564_config_syscon0>;
+		#clock-cells = <1>;
+	};
+};
+
 &pm7325_gpios {
 	kypd_vol_up_n: kypd-vol-up-n-state {
 		pins = "gpio6";
-- 
2.53.0

Re: [PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: add the clock controller

[Alex Elder]

On 10/5/26 6:09 PM, Alex Elder wrote:
> The clock controller within the TC9564 SoC is accessed via a PCI
> endpoint bus through BAR 4 of the first embedded PCIe function.
> A syscon node is created to provide access to a range of memory
> that is used by the clock controller and shared with other devices.
> 
> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
> v2: - Moved the clock devicetree node to be a peer (rather than a child) of
>        the syscon node

Whoops.  I dropped the "reg" property, and that means
the change mentioned above leads to a warning.

Either make them peers, but keep the clock node "reg"
property, or drop "reg" and make the clock node
subordinate to the syscon.

I will address this in version 3 of this series, but
(unless someone suggests otherwise) I'll wait to get
feedback on the rest of the series before I send that.

					-Alex

> 
>   arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 16 +++++++++++++++-
>   1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index 0e3bbdaf4661f..06246d185b50f 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -9,6 +9,7 @@
>   #define PM7250B_SID 8
>   #define PM7250B_SID1 9
>   
> +#include <dt-bindings/clock/toshiba,tc9564.h>
>   #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
>   #include <dt-bindings/iio/qcom,spmi-adc7-pm7325.h>
>   #include <dt-bindings/leds/common.h>
> @@ -961,7 +962,7 @@ dev@0,0 {
>   				#size-cells = <2>;
>   				ranges;	/* This will be updated dynamically */
>   
> -				pci-ep-bus@4 {
> +				pcie_s1b5d0f0_bar4_bus: pci-ep-bus@4 {
>   					compatible = "simple-bus";
>   					#address-cells = <1>;
>   					#size-cells = <1>;
> @@ -989,6 +990,19 @@ pci-ep-bus@4 {
>   	};
>   };
>   
> +&pcie_s1b5d0f0_bar4_bus {
> +	tc9564_config_syscon0: syscon@0 {
> +		compatible = "syscon";
> +		reg = <0x0 0x2000>;
> +	};
> +
> +	tc9564_clock0: clock {
> +		compatible = "toshiba,tc9564-clock";
> +		toshiba,config-syscon = <&tc9564_config_syscon0>;
> +		#clock-cells = <1>;
> +	};
> +};
> +
>   &pm7325_gpios {
>   	kypd_vol_up_n: kypd-vol-up-n-state {
>   		pins = "gpio6";

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

[Krzysztof Kozlowski]

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>
> ---
> v2: - Only define clock information, not reset information
>     - Reworded description to avoid talking about software
>     - Clock IDs are now consecutive (no more commented-out values)
> 
>  .../bindings/clock/toshiba,tc9564-clock.yaml  | 54 +++++++++++++++++++
>  MAINTAINERS                                   |  7 +++
>  include/dt-bindings/clock/toshiba,tc9564.h    | 34 ++++++++++++
>  3 files changed, 95 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
>  create mode 100644 include/dt-bindings/clock/toshiba,tc9564.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
> new file mode 100644
> index 0000000000000..329b8f002cf2d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/toshiba,tc9564-clock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba TC9564 Clock Controller
> +
> +maintainers:
> +  - 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 (including a clock controller) via its BARs.
> +
> +  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.
> +
> +  Clock ids are defined in <dt-bindings/clock/toshiba,tc9564.h>.
> +
> +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's more, I still do not see any usage of these clocks outside. And I
still did not receive actual answers (or I missed them) how these clocks
are routed OUTSIDE of the connector. You said for example:
"Ultimately the TC9564 SoC has a single 25 MHz input clock,"

but that is input. I did not ask how this device receives clocks. I
asked how the host receives the clocks from this device.

> +
> +  "#clock-cells":
> +    const: 1
> +
> +required:
> +  - compatible
> +  - toshiba,config-syscon
> +  - "#clock-cells"
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/toshiba,tc9564.h>

Looks unused.

> +
> +    clock {

Anyway, if this stays, that's a clock-controller.

Best regards,
Krzysztof

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

[Alex Elder]

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>

I'm just about to send version 3 of this series (and
then a new reset series derived from the code that was
previously combined with the clock code).  Some things
related to what you mention have changed.  I show that
below, but also respond to your other comments, and try
to advocate for the approach used.
>> ---
>> v2: - Only define clock information, not reset information
>>      - Reworded description to avoid talking about software
>>      - Clock IDs are now consecutive (no more commented-out values)
>>
>>   .../bindings/clock/toshiba,tc9564-clock.yaml  | 54 +++++++++++++++++++
>>   MAINTAINERS                                   |  7 +++
>>   include/dt-bindings/clock/toshiba,tc9564.h    | 34 ++++++++++++
>>   3 files changed, 95 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
>>   create mode 100644 include/dt-bindings/clock/toshiba,tc9564.h
>>
>> diff --git a/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
>> new file mode 100644
>> index 0000000000000..329b8f002cf2d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
>> @@ -0,0 +1,54 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/toshiba,tc9564-clock.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Toshiba TC9564 Clock Controller
>> +
>> +maintainers:
>> +  - 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 (including a clock controller) via its BARs.
>> +
>> +  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.
>> +
>> +  Clock ids are defined in <dt-bindings/clock/toshiba,tc9564.h>.
>> +
>> +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));

> What's more, I still do not see any usage of these clocks outside. And I
> still did not receive actual answers (or I missed them) how these clocks
> are routed OUTSIDE of the connector. You said for example:
> "Ultimately the TC9564 SoC has a single 25 MHz input clock,"
> 
> but that is input. I did not ask how this device receives clocks. I
> asked how the host receives the clocks from this device.

I was explaining that the clock input gets split into a number
of "output" clocks derived from that one input.  However you're
right, almost all of these clocks are connected to blocks
internal to the SoC.  There is only one 25 MHz clock that is
exposed externally (CLOCK_REFCLKO).

I think your point (or one of them) is that, even if pci-ep-bus
is used, the only things that warrant being described with
devicetree are those that can affect things outside the chip.
Everything else is not really variable from the perspective of
the platform, and inner details can be determined (and controlled)
by software.


Our original version of this code incorporated clock and reset
control inside the networking driver.  Rob commented that the
DWMAC driver should bind to the PCI functions and "everything
else...should be under the PCIe switch upstream node in a
pci-ep.bus".

The only driver associated with the switch inside the TC9564
is the special power control driver, accessed via I2C.  The
PCI switch functionality is otherwise provided without any
special handling, or is handled by generic code.

What *is* available is the PCI endpoint functions and their
BARs, so the endpoint buses use those.

PCI endpoint bus makes available things that devicetree
does that are very useful (including a standard way of
describing connections between blocks in the SoC).


I know that doesn't address the "exposed clocks" issue,
but it provides some background on why things were done
the way they were.


The single exposed clock *might* justify presenting the
clock controller device in devicetree.  There are also
resets exposed externally via GPIOs, and these control
external entities (PHYs).

But I'll reiterate how *nice* it is to use devicetree to
model the inner structure and of this SoC and the connections
between its various parts.  The DWMAC device driver can use
standard Linux clock (and reset, etc.) interfaces to manage
them--as if they were provided externally, or as if they
*could* be provided by something outside the TC9564.

There was no need to implement "unrelated" clock driver code
inside the DWMAC driver.  Granted, enabling/disabling the
clocks amounts to trivial register updates.  But supporting
two separate PCI functions that share access to those clocks
requires adding reference counting logic for every clock,
and it's just a lot nicer to benefit from the core Linux
code that already does that very well.


This is part of why I asked about the use of devicetree
overlays.  Can devicetree be used to describe an SoC (as
if it were an attached board)?  Would separating the DTS
portion into an overlay make this more palatable?


(Is this what the RPi RP1 does?)
>> +
>> +  "#clock-cells":
>> +    const: 1
>> +
>> +required:
>> +  - compatible
>> +  - toshiba,config-syscon
>> +  - "#clock-cells"
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/toshiba,tc9564.h>
> 
> Looks unused.

You're right, it's unused in the example.  I'll remove this.


> 
>> +
>> +    clock {
> 
> Anyway, if this stays, that's a clock-controller.

OK.  I'm still going to send version 3 shortly.

					-Alex

> 
> Best regards,
> Krzysztof

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

[Krzysztof Kozlowski]

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>
> 
> I'm just about to send version 3 of this series (and
> then a new reset series derived from the code that was
> previously combined with the clock code).  Some things
> related to what you mention have changed.  I show that
> below, but also respond to your other comments, and try
> to advocate for the approach used.
>>> ---
>>> v2: - Only define clock information, not reset information
>>>      - Reworded description to avoid talking about software
>>>      - Clock IDs are now consecutive (no more commented-out values)
>>>
>>>   .../bindings/clock/toshiba,tc9564-clock.yaml  | 54 +++++++++++++++++++
>>>   MAINTAINERS                                   |  7 +++
>>>   include/dt-bindings/clock/toshiba,tc9564.h    | 34 ++++++++++++
>>>   3 files changed, 95 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
>>>   create mode 100644 include/dt-bindings/clock/toshiba,tc9564.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
>>> new file mode 100644
>>> index 0000000000000..329b8f002cf2d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
>>> @@ -0,0 +1,54 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/clock/toshiba,tc9564-clock.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Toshiba TC9564 Clock Controller
>>> +
>>> +maintainers:
>>> +  - 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 (including a clock controller) via its BARs.
>>> +
>>> +  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.
>>> +
>>> +  Clock ids are defined in <dt-bindings/clock/toshiba,tc9564.h>.
>>> +
>>> +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?

> 
>> What's more, I still do not see any usage of these clocks outside. And I
>> still did not receive actual answers (or I missed them) how these clocks
>> are routed OUTSIDE of the connector. You said for example:
>> "Ultimately the TC9564 SoC has a single 25 MHz input clock,"
>>
>> but that is input. I did not ask how this device receives clocks. I
>> asked how the host receives the clocks from this device.
> 
> I was explaining that the clock input gets split into a number
> of "output" clocks derived from that one input.  However you're
> right, almost all of these clocks are connected to blocks
> internal to the SoC.  There is only one 25 MHz clock that is
> exposed externally (CLOCK_REFCLKO).
> 
> I think your point (or one of them) is that, even if pci-ep-bus
> is used, the only things that warrant being described with
> devicetree are those that can affect things outside the chip.
> Everything else is not really variable from the perspective of
> the platform, and inner details can be determined (and controlled)
> by software.
> 
> 
> Our original version of this code incorporated clock and reset
> control inside the networking driver.  Rob commented that the
> DWMAC driver should bind to the PCI functions and "everything
> else...should be under the PCIe switch upstream node in a
> pci-ep.bus".
> 
> The only driver associated with the switch inside the TC9564
> is the special power control driver, accessed via I2C.  The
> PCI switch functionality is otherwise provided without any
> special handling, or is handled by generic code.
> 
> What *is* available is the PCI endpoint functions and their
> BARs, so the endpoint buses use those.
> 
> PCI endpoint bus makes available things that devicetree
> does that are very useful (including a standard way of
> describing connections between blocks in the SoC).
> 
> 
> I know that doesn't address the "exposed clocks" issue,
> but it provides some background on why things were done
> the way they were.
> 
> 
> The single exposed clock *might* justify presenting the
> clock controller device in devicetree.  There are also
> resets exposed externally via GPIOs, and these control
> external entities (PHYs).

I cannot find any of these exposed. Please point me to DTS code showing
this.


Best regards,
Krzysztof

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

[Alex Elder]

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.

The clock controller uses two registers, 0x1004 and 0x100c,
to manage whether a set of clock signals are enabled or not.
(The reset controller uses two adjacent registers, 0x1008
and 0x1010, to manage whether a set of reset signals are
asserted or not.)

You said "no resources except a small address space" and I
guess it's not clear to me what size is "big enough" to
warrant representing something as a separate device.

*One* of the managed clocks is a 25 MHz clock, exposed
through a pin on the SoC.  That one clock signal is
therefore usable by the platform (although on the RB3gen2
it's not used).

Rather than expose the register addresses in the clock
node, a syscon is defined, covering 8 KB, and the actual
offsets used are just defined in the clock and reset
driver source code.

If that's not the right thing to do, please say that.

>>> What's more, I still do not see any usage of these clocks outside. And I
>>> still did not receive actual answers (or I missed them) how these clocks
>>> are routed OUTSIDE of the connector. You said for example:
>>> "Ultimately the TC9564 SoC has a single 25 MHz input clock,"
. . .

>> The single exposed clock *might* justify presenting the
>> clock controller device in devicetree.  There are also
>> resets exposed externally via GPIOs, and these control
>> external entities (PHYs).
> 
> I cannot find any of these exposed. Please point me to DTS code showing
> this.

It is not used by this platform, but is available for other
platforms to use.  Its name is "REFCLKO" and is exposed on
ball C17 of the SoC, if a platform designer decided to use it.

I only mention its existence as a reason to justify defining
the clock as a separate device, but I realize you are arguing
that I should do it somehow differently.

					-Alex

> 
> Best regards,
> Krzysztof

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

[Jerome Brunet]

On ven. 09 oct. 2026 at 09:23, Alex Elder <elder@riscstar.com> 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.
>
> The clock controller uses two registers, 0x1004 and 0x100c,
> to manage whether a set of clock signals are enabled or not.
> (The reset controller uses two adjacent registers, 0x1008
> and 0x1010, to manage whether a set of reset signals are
> asserted or not.)
>
> You said "no resources except a small address space" and I
> guess it's not clear to me what size is "big enough" to
> warrant representing something as a separate device.
>
> *One* of the managed clocks is a 25 MHz clock, exposed
> through a pin on the SoC.  That one clock signal is
> therefore usable by the platform (although on the RB3gen2
> it's not used).
>
> Rather than expose the register addresses in the clock
> node, a syscon is defined, covering 8 KB, and the actual
> offsets used are just defined in the clock and reset
> driver source code.
>
> If that's not the right thing to do, please say that.
>
>>>> What's more, I still do not see any usage of these clocks outside. And I
>>>> still did not receive actual answers (or I missed them) how these clocks
>>>> are routed OUTSIDE of the connector. You said for example:
>>>> "Ultimately the TC9564 SoC has a single 25 MHz input clock,"
> . . .
>
>>> The single exposed clock *might* justify presenting the
>>> clock controller device in devicetree.  There are also
>>> resets exposed externally via GPIOs, and these control
>>> external entities (PHYs).
>> 
>> I cannot find any of these exposed. Please point me to DTS code showing
>> this.
>
> It is not used by this platform, but is available for other
> platforms to use.  Its name is "REFCLKO" and is exposed on
> ball C17 of the SoC, if a platform designer decided to use it.
>
> I only mention its existence as a reason to justify defining
> the clock as a separate device, but I realize you are arguing
> that I should do it somehow differently.
>
> 					-Alex

While on the topic of description, I'm little bit concerned that this
controller does not any input ? Does it have an on-board oscillator
somehow ?

None of the clocks described in your driver take a parent from what I
can see. It is as if the clocks of this device are generated out of thin
air. Is it really how this works ?

>
>> 
>> Best regards,
>> Krzysztof
>

-- 
Jerome

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

[Krzysztof Kozlowski]

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.

> 
> The clock controller uses two registers, 0x1004 and 0x100c,
> to manage whether a set of clock signals are enabled or not.
> (The reset controller uses two adjacent registers, 0x1008
> and 0x1010, to manage whether a set of reset signals are
> asserted or not.)
> 
> You said "no resources except a small address space" and I
> guess it's not clear to me what size is "big enough" to
> warrant representing something as a separate device.
> 
> *One* of the managed clocks is a 25 MHz clock, exposed
> through a pin on the SoC.  That one clock signal is
> therefore usable by the platform (although on the RB3gen2
> it's not used).
> 
> Rather than expose the register addresses in the clock
> node, a syscon is defined, covering 8 KB, and the actual
> offsets used are just defined in the clock and reset
> driver source code.
> 
> If that's not the right thing to do, please say that.

Nodes should be squashed.

> 
>>>> What's more, I still do not see any usage of these clocks outside. And I
>>>> still did not receive actual answers (or I missed them) how these clocks
>>>> are routed OUTSIDE of the connector. You said for example:
>>>> "Ultimately the TC9564 SoC has a single 25 MHz input clock,"
> . . .
> 
>>> The single exposed clock *might* justify presenting the
>>> clock controller device in devicetree.  There are also
>>> resets exposed externally via GPIOs, and these control
>>> external entities (PHYs).
>>
>> I cannot find any of these exposed. Please point me to DTS code showing
>> this.
> 
> It is not used by this platform, but is available for other
> platforms to use.  Its name is "REFCLKO" and is exposed on
> ball C17 of the SoC, if a platform designer decided to use it.

Yeah, but you do not describe the SoC but PCI EP device, thus my claim
is that clocks cannot be used by the host. The SoC itself for different
hardware uses would have different binding, so that's not an argument to
have anything here, unless these different uses are also documented here.

Best regards,
Krzysztof

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

[Alex Elder]

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?

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.

					-Alex

>> The clock controller uses two registers, 0x1004 and 0x100c,
>> to manage whether a set of clock signals are enabled or not.
>> (The reset controller uses two adjacent registers, 0x1008
>> and 0x1010, to manage whether a set of reset signals are
>> asserted or not.)
>>
>> You said "no resources except a small address space" and I
>> guess it's not clear to me what size is "big enough" to
>> warrant representing something as a separate device.
>>
>> *One* of the managed clocks is a 25 MHz clock, exposed
>> through a pin on the SoC.  That one clock signal is
>> therefore usable by the platform (although on the RB3gen2
>> it's not used).
>>
>> Rather than expose the register addresses in the clock
>> node, a syscon is defined, covering 8 KB, and the actual
>> offsets used are just defined in the clock and reset
>> driver source code.
>>
>> If that's not the right thing to do, please say that.
> 
> Nodes should be squashed.
> 
>>
>>>>> What's more, I still do not see any usage of these clocks outside. And I
>>>>> still did not receive actual answers (or I missed them) how these clocks
>>>>> are routed OUTSIDE of the connector. You said for example:
>>>>> "Ultimately the TC9564 SoC has a single 25 MHz input clock,"
>> . . .
>>
>>>> The single exposed clock *might* justify presenting the
>>>> clock controller device in devicetree.  There are also
>>>> resets exposed externally via GPIOs, and these control
>>>> external entities (PHYs).
>>>
>>> I cannot find any of these exposed. Please point me to DTS code showing
>>> this.
>>
>> It is not used by this platform, but is available for other
>> platforms to use.  Its name is "REFCLKO" and is exposed on
>> ball C17 of the SoC, if a platform designer decided to use it.
> 
> Yeah, but you do not describe the SoC but PCI EP device, thus my claim
> is that clocks cannot be used by the host. The SoC itself for different
> hardware uses would have different binding, so that's not an argument to
> have anything here, unless these different uses are also documented here.
> 
> Best regards,
> Krzysztof

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

[Alex Elder]

On 10/9/26 9:38 AM, Jerome Brunet wrote:
> On ven. 09 oct. 2026 at 09:23, Alex Elder <elder@riscstar.com> 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.
>>
>> The clock controller uses two registers, 0x1004 and 0x100c,
>> to manage whether a set of clock signals are enabled or not.
>> (The reset controller uses two adjacent registers, 0x1008
>> and 0x1010, to manage whether a set of reset signals are
>> asserted or not.)
>>
>> You said "no resources except a small address space" and I
>> guess it's not clear to me what size is "big enough" to
>> warrant representing something as a separate device.
>>
>> *One* of the managed clocks is a 25 MHz clock, exposed
>> through a pin on the SoC.  That one clock signal is
>> therefore usable by the platform (although on the RB3gen2
>> it's not used).
>>
>> Rather than expose the register addresses in the clock
>> node, a syscon is defined, covering 8 KB, and the actual
>> offsets used are just defined in the clock and reset
>> driver source code.
>>
>> If that's not the right thing to do, please say that.
>>
>>>>> What's more, I still do not see any usage of these clocks outside. And I
>>>>> still did not receive actual answers (or I missed them) how these clocks
>>>>> are routed OUTSIDE of the connector. You said for example:
>>>>> "Ultimately the TC9564 SoC has a single 25 MHz input clock,"
>> . . .
>>
>>>> The single exposed clock *might* justify presenting the
>>>> clock controller device in devicetree.  There are also
>>>> resets exposed externally via GPIOs, and these control
>>>> external entities (PHYs).
>>>
>>> I cannot find any of these exposed. Please point me to DTS code showing
>>> this.
>>
>> It is not used by this platform, but is available for other
>> platforms to use.  Its name is "REFCLKO" and is exposed on
>> ball C17 of the SoC, if a platform designer decided to use it.
>>
>> I only mention its existence as a reason to justify defining
>> the clock as a separate device, but I realize you are arguing
>> that I should do it somehow differently.
>>
>> 					-Alex
> 
> While on the topic of description, I'm little bit concerned that this
> controller does not any input ? Does it have an on-board oscillator
> somehow ?

No, it has an external fixed 25 MHz input, and this is a good
point, that should be represented.

> None of the clocks described in your driver take a parent from what I
> can see. It is as if the clocks of this device are generated out of thin
> air. Is it really how this works ?

No, you're right to point this out.  Thank you.

					-Alex
>>>
>>> Best regards,
>>> Krzysztof
>>
>