[PATCH v2 0/3] PCI: introduce TC9564 misc driver

[PATCH v2 0/3] PCI: introduce TC9564 misc driver

[Alex Elder]

The Toshiba TC9564 is specialized SoC that implements a PCIe switch as
well as an Ethernet AVB/TSN bridge.  It also implements other functions,
including a reset and clock controller, an address translation unit, and
a few other devices.  PCIe BARs provide access to registers that manage
these IP blocks, and the SoC is modeled using a PCI endpoint bus in
devicetree.  This allows the IP blocks to be bound to platform drivers
using MMIO through the PCI BARs.

This series introduces the simple PCI driver necessary to implement the
PCI endpoint bus.  It enables the device, enables master access, and
then scans the devicetree subnodes to discover any devices defined
within the endpoint buses.

The driver is placed in the "misc" directory, following the practice
of other PCI endpoint bus drivers.

					-Alex

Note: to work correctly, this series depends on this:
  https://lore.kernel.org/lkml/20260910021919.3421449-1-elder@riscstar.com/

Between version 1 and version 2:
- Updated the block diagram in the binding to include BAR2 and SRAM
- Use KBUILD_MODNAME for the driver name
- Removed bogus initialization of pci_driver->driver field
- Added the third patch, which defines pci-ep-bus DTS information.
- Now based on the Qualcomm for-next branch

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


Alex Elder (3):
  dt-bindings: misc: introduce pci1179,0220.yaml
  misc: tc9564: introduce base PCI driver
  arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses

 .../bindings/misc/pci1179,0220.yaml           | 154 ++++++++++++++++++
 MAINTAINERS                                   |   7 +
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts  |  30 ++++
 drivers/misc/Kconfig                          |  10 ++
 drivers/misc/Makefile                         |   1 +
 drivers/misc/tc9564-pci.c                     |  83 ++++++++++
 drivers/pci/quirks.c                          |   1 +
 7 files changed, 286 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/pci1179,0220.yaml
 create mode 100644 drivers/misc/tc9564-pci.c


base-commit: 27b3028b7d65cbc44fc5b60d2e977ce55cf186f1
-- 
2.53.0

[PATCH v2 1/3] dt-bindings: misc: introduce pci1179,0220.yaml

[Alex Elder]

Define the binding for the Toshiba TC9564 PCI endpoint function device.
The third downstream PCIe switch port within this chip has an embedded
PCIe controller, and that implements two of these PCIe functions.

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: - Added BAR2 and SRAM to the block diagram
    - Updated parent addresses in ranges properties

NOTE:
  Despite being a PCI device, this endpoint function device uses
  the devicetree "pci-ep-bus" model to represent sub-devices that
  are accessed via the function's BARs.

 .../bindings/misc/pci1179,0220.yaml           | 154 ++++++++++++++++++
 MAINTAINERS                                   |   6 +
 2 files changed, 160 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/pci1179,0220.yaml

diff --git a/Documentation/devicetree/bindings/misc/pci1179,0220.yaml b/Documentation/devicetree/bindings/misc/pci1179,0220.yaml
new file mode 100644
index 0000000000000..fca3d331097de
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/pci1179,0220.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/pci1179,0220.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC9564 internal PCI endpoint function
+
+maintainers:
+  - Alex Elder <elder@kernel.org>
+  - Daniel Thompson <danielt@kernel.org>
+
+description: >
+  The Toshiba TC9564 is specialized SoC that implements a PCIe switch
+  as well as an Ethernet AVB/TSN bridge.  In addition to these, the SoC
+  implements other functions, including a reset and clock controller,
+  an address translation unit, and a few other devices.
+
+  The PCI switch has three downstream ports.  The first two are exposed
+  externally, while the third is used by an internal PCIe endpoint.  The
+  internal endpoint implements two PCIe functions, and attached to each
+  of these is a 10 Gbps capable Synopsys Ethernet controller and an
+  interrupt controller that converts internal "wired" interrupts into
+  MSIs delivered to the host.
+
+  PCIe BARs provide access to registers that manage almost all IP blocks.
+  The SoC is modeled using a PCI endpoint bus.  The IP blocks are bound
+  to platform drivers that access the hardware using MMIO through the
+  PCI BARs.
+
+          ------------------------------------
+          |               Host               |
+          -----........---------------...-----
+              |        |             |   |
+              |  PCIe  |             |I2C|
+              |        |             |   |
+    ----------+........+-------------+...+-------------------------------
+    |         |upstream|          |          |       ----------------   |
+    | Toshiba | Port 0 |          |          +-------+ PCIe pwrctrl |   |
+    | TC9564  ----++----          |   I2C    |       ----------------   |
+    |  SoC        ||              |controller|       ----------------   |
+    |             ||              |          +-------+     GPIO     |   |
+    |             ||              |          |       |  controller  |   |
+    |       ------++------        ------------       ----------------   |
+    |       |     US     |                                              |
+    |       |            |    ----------------------------------------  |
+    |       |         DS3+====+          downstream port 3           |  |
+    |       |            |    |--------------------------------------|  |
+    |       |    PCIe    |    |        embedded PCIe endpoint        |  |
+    |       |   switch   |    |~~~~~~~~~~~~~~~~~~~++~~~~~~~~~~~~~~~~~|  |
+    |       |            |    |  PCIe function 0  || PCIe function 1 |  |
+    |       |            |    |-------------------||-----------------|  |
+    |       |            |    | BAR || BAR || BAR || BAR | BAR | BAR |  |
+    |       |            |    |  0  ||  2  ||  4  ||  0  |  2  |  4  |  |
+    |       | DS1    DS2 |    ---.------.------.--++--------------.---  |
+    |       --++------++--       :      :      :                  :     |
+    |         ||      ||         :   ---.--    :.......           :     |
+    |         ||      ||         :   |SRAM|    :      :           :     |
+    |         ||      ||         :   ------    :   ---.---        :     |
+    |         ||      ||         :         ....:   |clock|    ....:     |
+    |         ||      ||         :         :   :   -------    :   :     |
+    |         ||      ||   ------.----    -.-  :             -.-  :     |
+    |         ||      ||   |translate|    |M|  :.......      |M|  :     |
+    |         ||      ||   -----------    |S|  :      :      |S|  :     |
+    |         ||      ||                  |I|  :   ---.---   |I|  :     |
+    |         ||      ||                  |G|  :   |reset|   |G|  :     |
+    |         ||      ||                  |E|  :   -------   |E|  :     |
+    | --------++--  --++--------          |N|  :             |N|  :     |
+    | |downstream|  |downstream|         ------.----        ------.---- |
+    | |  port 1  |  |  port 2  |         | XGMAC 0 |        | XGMAC 1 | |
+    --+..........+--+..........+----------+.......+-----------+.....+----
+                                          |       |           |     |
+                                          |USXGMII|           |SGMII|
+                                          |       |           |     |
+                                        --+.......+--      ---+.....+---
+                                        | Ethernet  |      | Ethernet  |
+                                        |    PHY    |      |    PHY    |
+                                        -------------      -------------
+
+allOf:
+  - $ref: /schemas/pci/pci-ep-bus.yaml
+
+properties:
+  compatible:
+    const: pci1179,0220         # Toshiba TC9654 (a.k.a. Qualcomm QPS615)
+
+  reg:
+    maxItems: 1
+    description: PCI Bus/Device/Function config space address
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - '#address-cells'
+  - '#size-cells'
+  - ranges
+
+examples:
+  - |
+    pcie@0,0 {
+        reg = <0x0  0x0>;
+        #address-cells = <3>;
+        #size-cells = <2>;
+        device_type = "pci";
+        ranges = <0x83000000 0x0 0x0  0x0  0x0 0x1fd00000>;
+
+        dev@0,0 {
+            compatible = "pci1179,0220";
+            reg = <0x0 0x0 0x0 0x0 0x0>;
+            #address-cells = <3>;
+            #size-cells = <2>;
+            /* Ranges will be updated dynamically */
+            ranges = <0x0 0x0 0x0  0x83000000 0x0 0x0  0x0 0x4000>,
+                     <0x2 0x0 0x0  0x83000000 0x0 0x4000  0x0 0x80000>,
+                     <0x4 0x0 0x0  0x83000000 0x0 0x84000  0x0 0x200000>;
+
+            pci-ep-bus@0 {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                /* Map 0x0-0x3fff to BAR 0 */
+                ranges = <0x0  0x0 0x0 0x0  0x4000>;
+            };
+
+            pci-ep-bus@4 {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                /* Map 0x0-0x1fffff to BAR 4 */
+                ranges = <0x0  0x4 0x0 0x0  0x200000>;
+            };
+        };
+
+        dev@0,1 {
+            compatible = "pci1179,0220";
+            reg = <0x100 0x0 0x0 0x0 0x0>;
+            #address-cells = <3>;
+            #size-cells = <2>;
+            /* Ranges will be updated dynamically */
+            ranges = <0x0 0x0 0x0  0x83000100 0x0 0x0  0x0 0x4000>,
+                     <0x2 0x0 0x0  0x83000100 0x0 0x4000  0x0 0x80000>,
+                     <0x4 0x0 0x0  0x83000100 0x0 0x84000  0x0 0x200000>;
+
+            pci-ep-bus@4 {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                /* Map 0x0-0x1fffff to BAR 4 */
+                ranges = <0x0  0x4 0x0 0x0  0x200000>;
+            };
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 6096dab7121e8..aa6b805e1ab2b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27670,6 +27670,12 @@ F:	Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.txt
 F:	drivers/media/i2c/tc358743*
 F:	include/media/i2c/tc358743.h
 
+TOSHIBA TC9564 PCI DRIVER
+M:	Alex Elder <elder@kernel.org>
+M:	Daniel Thompson <danielt@kernel.org>
+S:	Maintained
+F:	Documentation/devicetree/bindings/misc/pci1179,0220.yaml
+
 TOSHIBA WMI HOTKEYS DRIVER
 M:	Azael Avalos <coproscefalo@gmail.com>
 L:	platform-driver-x86@vger.kernel.org
-- 
2.53.0

Re: [PATCH v2 1/3] dt-bindings: misc: introduce pci1179,0220.yaml

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: typo in compatible comment (TC9654 vs TC9564)
--

commit 8118db85b05b7b5ac32fd5abc0d4c0b807fa8de2
Author: Alex Elder <elder@riscstar.com>

dt-bindings: misc: introduce pci1179,0220.yaml

This commit introduces a new devicetree binding for the Toshiba TC9564
internal PCI endpoint function device. It uses the pci-ep-bus model to
represent sub-devices accessed via the function's BARs.

> diff --git a/Documentation/devicetree/bindings/misc/pci1179,0220.yaml b/Documentation/devicetree/bindings/misc/pci1179,0220.yaml
> new file mode 100644
> index 0000000000000..fca3d331097de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/pci1179,0220.yaml

[ ... ]

> +allOf:
> +  - $ref: /schemas/pci/pci-ep-bus.yaml
> +
> +properties:
> +  compatible:
> +    const: pci1179,0220         # Toshiba TC9654 (a.k.a. Qualcomm QPS615)

[Severity: Low]
Is TC9654 a typo in this properties.compatible comment? The device is
referred to as TC9564 in the commit message, the file title, and the
MAINTAINERS file.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915031038.1087264-1-elder@riscstar.com?part=1

Re: [PATCH v2 1/3] dt-bindings: misc: introduce pci1179,0220.yaml

[Alex Elder]

On 9/14/26 10:15 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] dt-bindings: typo in compatible comment (TC9654 vs TC9564)
> --
> 
> commit 8118db85b05b7b5ac32fd5abc0d4c0b807fa8de2
> Author: Alex Elder <elder@riscstar.com>
> 
> dt-bindings: misc: introduce pci1179,0220.yaml
> 
> This commit introduces a new devicetree binding for the Toshiba TC9564
> internal PCI endpoint function device. It uses the pci-ep-bus model to
> represent sub-devices accessed via the function's BARs.
> 
>> diff --git a/Documentation/devicetree/bindings/misc/pci1179,0220.yaml b/Documentation/devicetree/bindings/misc/pci1179,0220.yaml
>> new file mode 100644
>> index 0000000000000..fca3d331097de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/pci1179,0220.yaml
> 
> [ ... ]
> 
>> +allOf:
>> +  - $ref: /schemas/pci/pci-ep-bus.yaml
>> +
>> +properties:
>> +  compatible:
>> +    const: pci1179,0220         # Toshiba TC9654 (a.k.a. Qualcomm QPS615)
> 
> [Severity: Low]
> Is TC9654 a typo in this properties.compatible comment? The device is
> referred to as TC9564 in the commit message, the file title, and the
> MAINTAINERS file.

Again!  I fixed the previous typo with a new one.

If no one else offers any review comments this morning, I
will send out version 3 this afternoon, fixing this and a
few other things reported.

					-Alex

[PATCH v2 2/3] misc: tc9564: introduce base PCI driver

[Alex Elder]

The Toshiba TC9564 is small and highly-specialized SoC that implements
a PCIe switch as well as an Ethernet AVB/TSN bridge.  In addition to
these, the SoC implements other functions, including a reset and clock
controller, an address translation unit, and a few other devices.  PCIe
BARs provide access to registers that manage these IP blocks, and the
SoC is modeled using a PCI endpoint bus in devicetree.  This allows the
IP blocks to be bound to platform drivers using MMIO through the PCI BARs.

Create a new PCI driver under drivers/misc that binds with the embedded
PCI endpoint functions within the TC9564 SoC.  Because these functions
will use devicetree pci-ep-bus to provide access to other IP blocks
within the TC9564 chip, the main purpose of this driver is to do basic
PCI initialization, then call of_platform_default_populate() to scan for
the any endpoint bus children, and probe all devices defined therein.

Because we're using pci-ep-bus, we need to use the PCI quirks mechanism
to have of_pci_make_dev_node() be called for each endpoint device in
pci_bus_add_device() (via pci_fixup_device(pci_fixup_final, dev)).

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: - Use KBUILD_MODNAME for the driver name
    - Eliminate initializion pci_driver->driver

 MAINTAINERS               |  1 +
 drivers/misc/Kconfig      | 10 +++++
 drivers/misc/Makefile     |  1 +
 drivers/misc/tc9564-pci.c | 83 +++++++++++++++++++++++++++++++++++++++
 drivers/pci/quirks.c      |  1 +
 5 files changed, 96 insertions(+)
 create mode 100644 drivers/misc/tc9564-pci.c

diff --git a/MAINTAINERS b/MAINTAINERS
index aa6b805e1ab2b..cf846853fdc79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27675,6 +27675,7 @@ M:	Alex Elder <elder@kernel.org>
 M:	Daniel Thompson <danielt@kernel.org>
 S:	Maintained
 F:	Documentation/devicetree/bindings/misc/pci1179,0220.yaml
+F:	drivers/misc/tc9564-pci.c
 
 TOSHIBA WMI HOTKEYS DRIVER
 M:	Azael Avalos <coproscefalo@gmail.com>
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 7364931dad3a1..91950d2928f07 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -568,6 +568,16 @@ config MCHP_LAN966X_PCI
 	    - lan966x-miim (MDIO_MSCC_MIIM)
 	    - lan966x-switch (LAN966X_SWITCH)
 
+config TC9564_PCI
+	tristate "Toshiba TC9564 PCI function support"
+	depends on PCI
+	select REGMAP_MMIO
+	help
+	  This enables support for the two PCI functions implemented by
+	  the embedded PCIe endpoint in the Toshiba TC9564 SoC.  This
+	  driver uses a pci-ep-bus node in devicetree to provide MMIO
+	  access to other SoC devices through PCI function BARs.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e8d8d5d88c0df..7cc3d615d37a4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -71,3 +71,4 @@ obj-y				+= keba/
 obj-y				+= amd-sbi/
 obj-$(CONFIG_MISC_RP1)		+= rp1/
 obj-$(CONFIG_INTEL_SSEI)	+= issei/
+obj-$(CONFIG_TC9564_PCI)	+= tc9564-pci.o
diff --git a/drivers/misc/tc9564-pci.c b/drivers/misc/tc9564-pci.c
new file mode 100644
index 0000000000000..d7ebbd90d1584
--- /dev/null
+++ b/drivers/misc/tc9564-pci.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */
+
+/*
+ * The Toshiba TC9564 implements a PCIe Gen 3 switch that connects an
+ * upstream x4 port to three downstream PCIe ports.  Two of the downstream
+ * ports are external, and the third is internal, implementing a PCIe
+ * endpoint with implements two PCIe functions.  Each PCIe function drives
+ * a Synopsys XGMAC Ethernet interface capable of 10 Gbps operation.
+ *
+ * The TC9564 implements other functionality, including an embedded MCU,
+ * a UART, a GPIO controller, a reset controller, a clock controller, and
+ * interrupt handling.  These features are separate from (and in some
+ * cases used by) both Ethernet XGMACs.  Each Ethernet MAC must be
+ * attached to a working PHY for it to be functional, and for this
+ * reason either of them (or both!) might not be usable/used.
+ *
+ * This PCI driver binds to the Toshiba TC9564 (physical) PCI function
+ * (VID 0x1179, DID 0x0220).
+ */
+
+#include <linux/device.h>
+#include <linux/irqdomain.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+
+static int
+tc9564_function_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np;
+	int ret;
+
+	/* Despite being a PCI device, we require devicetree */
+	np = dev_of_node(dev);
+	if (!np)
+		return dev_err_probe(dev, -EINVAL, "no devicetree node\n");
+
+	ret = pcim_enable_device(pdev);
+	if (ret)
+		return ret;
+
+	pci_set_master(pdev);
+
+	/* Scan for pci-ep-bus nodes and probe their sub-devices */
+	ret = of_platform_default_populate(np, NULL, dev);
+	if (ret)
+		goto err_clear_master;
+
+	return 0;
+
+err_clear_master:
+	pci_clear_master(pdev);
+
+	return dev_err_probe(dev, ret, "failed to populate platform bus\n");
+}
+
+static void tc9564_function_remove(struct pci_dev *pdev)
+{
+	of_platform_depopulate(&pdev->dev);
+	pci_clear_master(pdev);
+}
+
+static const struct pci_device_id tc9564_function_id_table[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA, 0x0220), },
+	{ },
+};
+MODULE_DEVICE_TABLE(pci, tc9564_function_id_table);
+
+static struct pci_driver tc9564_function_driver = {
+	.name		= KBUILD_MODNAME,
+	.id_table	= tc9564_function_id_table,
+	.probe		= tc9564_function_probe,
+	.remove		= tc9564_function_remove,
+};
+module_pci_driver(tc9564_function_driver);
+
+MODULE_DESCRIPTION("Toshiba TC9564 PCIe Embedded Function Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index de9bbccda21fd..54e310c4153df 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6391,6 +6391,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5020, of_pci_make_dev_node);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5021, of_pci_make_dev_node);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REDHAT, 0x0005, of_pci_make_dev_node);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_EFAR, 0x9660, of_pci_make_dev_node);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_TOSHIBA, 0x0220, of_pci_make_dev_node);
 
 /*
  * Devices known to require a longer delay before first config space access
-- 
2.53.0

Re: [PATCH v2 2/3] misc: tc9564: introduce base PCI driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] misc: missing of_platform_depopulate() on probe error path
- [Low] kconfig: unused REGMAP_MMIO selection in TC9564_PCI
--

commit 526cbf40d582cb34a1f4613745e5ca7890f929d2
Author: Alex Elder <elder@riscstar.com>

misc: tc9564: introduce base PCI driver

This commit introduces a base PCI driver for the Toshiba TC9564 SoC, which
implements a PCIe switch and Ethernet AVB/TSN bridge. It performs basic PCI
initialization and uses of_platform_default_populate() to scan and probe
child devices defined in the devicetree.

> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 7364931dad3a1..91950d2928f07 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -568,6 +568,16 @@ config MCHP_LAN966X_PCI
>  	    - lan966x-miim (MDIO_MSCC_MIIM)
>  	    - lan966x-switch (LAN966X_SWITCH)
>  
> +config TC9564_PCI
> +	tristate "Toshiba TC9564 PCI function support"
> +	depends on PCI
> +	select REGMAP_MMIO

[Severity: Low]
Is the REGMAP_MMIO selection required for this driver?

Looking at drivers/misc/tc9564-pci.c, it does not seem to include
linux/regmap.h or use any regmap APIs. Could this lead to unnecessary
kernel bloat if the regmap infrastructure isn't selected by other
configurations?

[ ... ]
> diff --git a/drivers/misc/tc9564-pci.c b/drivers/misc/tc9564-pci.c
> new file mode 100644
> index 0000000000000..d7ebbd90d1584
> --- /dev/null
> +++ b/drivers/misc/tc9564-pci.c
[ ... ]
> +static int
> +tc9564_function_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> +{
[ ... ]
> +	/* Scan for pci-ep-bus nodes and probe their sub-devices */
> +	ret = of_platform_default_populate(np, NULL, dev);
> +	if (ret)
> +		goto err_clear_master;
> +
> +	return 0;
> +
> +err_clear_master:
> +	pci_clear_master(pdev);
> +
> +	return dev_err_probe(dev, ret, "failed to populate platform bus\n");
> +}

[Severity: High]
Does this error path need to call of_platform_depopulate() before returning?

When of_platform_default_populate() fails midway, it leaves any successfully
created child platform devices registered and sets the OF_POPULATED_BUS flag.
If we only call pci_clear_master() and return an error here, devres will
subsequently disable the PCI device completely via pcim_disable_device().

Since the orphaned child devices remain bound to their drivers, any later
attempt by those drivers to perform MMIO accesses on the disabled PCI
device could result in PCIe Unsupported Requests (UR), which can trigger a
fatal SError/MCE on many architectures.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915031038.1087264-1-elder@riscstar.com?part=2

Re: [PATCH v2 2/3] misc: tc9564: introduce base PCI driver

[Alex Elder]

On 9/14/26 10:20 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] misc: missing of_platform_depopulate() on probe error path
> - [Low] kconfig: unused REGMAP_MMIO selection in TC9564_PCI
> --
> 
> commit 526cbf40d582cb34a1f4613745e5ca7890f929d2
> Author: Alex Elder <elder@riscstar.com>
> 
> misc: tc9564: introduce base PCI driver
> 
> This commit introduces a base PCI driver for the Toshiba TC9564 SoC, which
> implements a PCIe switch and Ethernet AVB/TSN bridge. It performs basic PCI
> initialization and uses of_platform_default_populate() to scan and probe
> child devices defined in the devicetree.
> 
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 7364931dad3a1..91950d2928f07 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -568,6 +568,16 @@ config MCHP_LAN966X_PCI
>>   	    - lan966x-miim (MDIO_MSCC_MIIM)
>>   	    - lan966x-switch (LAN966X_SWITCH)
>>   
>> +config TC9564_PCI
>> +	tristate "Toshiba TC9564 PCI function support"
>> +	depends on PCI
>> +	select REGMAP_MMIO
> 
> [Severity: Low]
> Is the REGMAP_MMIO selection required for this driver?
> 
> Looking at drivers/misc/tc9564-pci.c, it does not seem to include
> linux/regmap.h or use any regmap APIs. Could this lead to unnecessary
> kernel bloat if the regmap infrastructure isn't selected by other
> configurations?

This was an oversight when making the conversion to the endpoint
bus.  This driver no longer uses regmap, so that dependency will
be removed when version 3 is posted.

> 
> [ ... ]
>> diff --git a/drivers/misc/tc9564-pci.c b/drivers/misc/tc9564-pci.c
>> new file mode 100644
>> index 0000000000000..d7ebbd90d1584
>> --- /dev/null
>> +++ b/drivers/misc/tc9564-pci.c
> [ ... ]
>> +static int
>> +tc9564_function_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>> +{
> [ ... ]
>> +	/* Scan for pci-ep-bus nodes and probe their sub-devices */
>> +	ret = of_platform_default_populate(np, NULL, dev);
>> +	if (ret)
>> +		goto err_clear_master;
>> +
>> +	return 0;
>> +
>> +err_clear_master:
>> +	pci_clear_master(pdev);
>> +
>> +	return dev_err_probe(dev, ret, "failed to populate platform bus\n");
>> +}
> 
> [Severity: High]
> Does this error path need to call of_platform_depopulate() before returning?

It looks like it does.  I now recognize that of_platform_populate()
(called by of_platform_default_populate()) does not unwind and clean
up its mess in the event of an error, so doing that is the caller's
responsibility.

I will fix this in version 3.

					-Alex

> 
> When of_platform_default_populate() fails midway, it leaves any successfully
> created child platform devices registered and sets the OF_POPULATED_BUS flag.
> If we only call pci_clear_master() and return an error here, devres will
> subsequently disable the PCI device completely via pcim_disable_device().
> 
> Since the orphaned child devices remain bound to their drivers, any later
> attempt by those drivers to perform MMIO accesses on the disabled PCI
> device could result in PCIe Unsupported Requests (UR), which can trigger a
> fatal SError/MCE on many architectures.
> 

[PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses

[Alex Elder]

The TC9564 SoC incorporates a PCIe switch, which is connected via
the second PCI segment (0001) on the RB3gen2 platform.  The third
downstream port of that switch (pcie@3,0) has an embedded PCIe
endpoint that implements two PCIe functions.

The SoC implements other peripherals, and they will be accessed via
PCI endpoint bus.  Define the devicetree nodes representing these
buses, including the mapping of each BAR's address range to its
local address space.

The endpoint's ranges property must be defined, but it will be
updated dynamically to include all BARs.  As a result of this update,
the parent address portion of each range will reflect the specific
address assigned to the BAR.

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: - Added this patch to the series

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

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index 3bb5fca8e2b13..59fbb0444d9b7 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -955,11 +955,41 @@ pcie@3,0 {
 			bus-range = <0x5 0xff>;
 
 			dev@0,0 {
+				compatible = "pci1179,0220";
 				reg = <0x50000 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				/* Ranges will be updated dynamically */
+				ranges = <0x0 0x0 0x0  0x83050000 0x0 0x0 0x0 0x4000>,
+					 <0x2 0x0 0x0  0x83050000 0x0 0x0 0x0 0x80000>,
+					 <0x4 0x0 0x0  0x83050000 0x0 0x0 0x0 0x200000>;
+
+				pci-ep-bus@4 {
+					compatible = "simple-bus";
+					#address-cells = <1>;
+					#size-cells = <1>;
+					/* Map 0x0-0x1fffff to BAR 4 */
+					ranges = <0x0  0x4 0x0 0x0  0x200000>;
+				};
 			};
 
 			dev@0,1 {
+				compatible = "pci1179,0220";
 				reg = <0x50100 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				/* Ranges will be updated dynamically */
+				ranges = <0x0 0x0 0x0  0x83050100 0x0 0x0 0x0 0x4000>,
+					 <0x2 0x0 0x0  0x83050100 0x0 0x0 0x0 0x80000>,
+					 <0x4 0x0 0x0  0x83050100 0x0 0x0 0x0 0x200000>;
+
+				pci-ep-bus@4 {
+					compatible = "simple-bus";
+					#address-cells = <1>;
+					#size-cells = <1>;
+					/* Map 0x0-0x1fffff to BAR 4 */
+					ranges = <0x0  0x4 0x0 0x0  0x200000>;
+				};
 			};
 		};
 	};
-- 
2.53.0

Re: [PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dts: pci: static ranges will not be updated dynamically due to existing DT node
- [Low] dts: pci-ep-bus node has unit address but no reg property
--

commit 1c7c7d7922bcd554a385a9dab10bfbe2a5cf71bb
Author: Alex Elder <elder@riscstar.com>

arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses

This commit adds endpoint buses for a PCIe switch connected via the second
PCI segment (0001) on the RB3gen2 platform. It defines devicetree nodes
representing these buses, including the mapping of each BAR's address
range to its local address space.

> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index 3bb5fca8e2b13..59fbb0444d9b7 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
[ ... ]
> @@ -955,11 +955,41 @@ pcie@3,0 {
>  			bus-range = <0x5 0xff>;
>  
>  			dev@0,0 {
> +				compatible = "pci1179,0220";
>  				reg = <0x50000 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				/* Ranges will be updated dynamically */
> +				ranges = <0x0 0x0 0x0  0x83050000 0x0 0x0 0x0 0x4000>,
> +					 <0x2 0x0 0x0  0x83050000 0x0 0x0 0x0 0x80000>,
> +					 <0x4 0x0 0x0  0x83050000 0x0 0x0 0x0 0x200000>;

[Severity: High]
Will these placeholder ranges actually be updated dynamically at runtime? 
Because the dev@0,0 node is statically defined in the devicetree, it appears
the PCI core's of_pci_make_dev_node() will find it during quirk processing
(via pci_device_to_OF_node()) and return early. 

If that happens, of_pci_add_properties() won't be called, leaving these
overlapping dummy physical addresses in place and potentially breaking MMIO
translation for child devices.

> +
> +				pci-ep-bus@4 {

[Severity: Low]
Does this node name trigger a dtc compiler warning? Defining a unit address
(@4) without a corresponding reg property violates the Devicetree
specification and will cause a unit_address_vs_reg warning.

> +					compatible = "simple-bus";
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +					/* Map 0x0-0x1fffff to BAR 4 */
> +					ranges = <0x0  0x4 0x0 0x0  0x200000>;
> +				};
>  			};
>  
>  			dev@0,1 {
> +				compatible = "pci1179,0220";
>  				reg = <0x50100 0x0 0x0 0x0 0x0>;
> +				#address-cells = <3>;
> +				#size-cells = <2>;
> +				/* Ranges will be updated dynamically */
> +				ranges = <0x0 0x0 0x0  0x83050100 0x0 0x0 0x0 0x4000>,
> +					 <0x2 0x0 0x0  0x83050100 0x0 0x0 0x0 0x80000>,
> +					 <0x4 0x0 0x0  0x83050100 0x0 0x0 0x0 0x200000>;

[Severity: High]
Similarly for dev@0,1, will this static definition prevent dynamic ranges
updates? If of_pci_add_properties() is skipped due to the node already
existing, the dummy physical addresses will remain and could cause register
corruption or crashes if child drivers probe here.

> +
> +				pci-ep-bus@4 {

[Severity: Low]
This node is also named with @4 but does not define a reg property, which
can trigger a dtc unit_address_vs_reg warning.

> +					compatible = "simple-bus";
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +					/* Map 0x0-0x1fffff to BAR 4 */
> +					ranges = <0x0  0x4 0x0 0x0  0x200000>;
> +				};
>  			};
>  		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915031038.1087264-1-elder@riscstar.com?part=3

Re: [PATCH v2 3/3] arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses

[Alex Elder]

On 9/14/26 10:20 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] dts: pci: static ranges will not be updated dynamically due to existing DT node
> - [Low] dts: pci-ep-bus node has unit address but no reg property
> --
> 
> commit 1c7c7d7922bcd554a385a9dab10bfbe2a5cf71bb
> Author: Alex Elder <elder@riscstar.com>
> 
> arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses
> 
> This commit adds endpoint buses for a PCIe switch connected via the second
> PCI segment (0001) on the RB3gen2 platform. It defines devicetree nodes
> representing these buses, including the mapping of each BAR's address
> range to its local address space.
> 
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> index 3bb5fca8e2b13..59fbb0444d9b7 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> [ ... ]
>> @@ -955,11 +955,41 @@ pcie@3,0 {
>>   			bus-range = <0x5 0xff>;
>>   
>>   			dev@0,0 {
>> +				compatible = "pci1179,0220";
>>   				reg = <0x50000 0x0 0x0 0x0 0x0>;
>> +				#address-cells = <3>;
>> +				#size-cells = <2>;
>> +				/* Ranges will be updated dynamically */
>> +				ranges = <0x0 0x0 0x0  0x83050000 0x0 0x0 0x0 0x4000>,
>> +					 <0x2 0x0 0x0  0x83050000 0x0 0x0 0x0 0x80000>,
>> +					 <0x4 0x0 0x0  0x83050000 0x0 0x0 0x0 0x200000>;

Looking at this now, I also realize I neglected to incorporate
another change before sending this...  It is erroneous to
specify the same parent address for all three of the ranges
as is done here.  These ranges are only representative
(because they *will* be dynamically updated), but the second
and third parent address entries will be 0x83050000 0x4000
and 0x83050000 0x84000, respectively.

I will update this when I post version 3 of this series.

> 
> [Severity: High]
> Will these placeholder ranges actually be updated dynamically at runtime?
> Because the dev@0,0 node is statically defined in the devicetree, it appears
> the PCI core's of_pci_make_dev_node() will find it during quirk processing
> (via pci_device_to_OF_node()) and return early.

This is a correct statement based on the current state of 
of_pci_make_dev_node().  Things change when another series
(which is a prerequisite for the present one) is in place:
   https://lore.kernel.org/lkml/20260910021919.3421449-1-elder@riscstar.com/

That series changes of_pci_make_dev_node() so that the
ranges property in the already-existing devicetree node
gets updated dynamically, taking into account the addresses
assigned to the BARs during PCI enumeration.

So although this is a good observation, it does not take
into account the other series that must be in place before
this one is accepted.

> If that happens, of_pci_add_properties() won't be called, leaving these
> overlapping dummy physical addresses in place and potentially breaking MMIO
> translation for child devices.
> 
>> +
>> +				pci-ep-bus@4 {
> 
> [Severity: Low]
> Does this node name trigger a dtc compiler warning? Defining a unit address
> (@4) without a corresponding reg property violates the Devicetree
> specification and will cause a unit_address_vs_reg warning.

I don't believe this caused a warning (though I've had problems
when checking bindings and DTBs in the past...).

There are two other examples of DTS files that use pci-ep-bus
(with a unit address, ans specified by the binding), but they
do not add a "reg" property.
   Documentation/devicetree/bindings/pci/pci-ep-bus.yaml
   drivers/misc/lan966x_pci.dtso
   arch/arm64/boot/dts/broadcom/rp1-common.dtsi

This suggestion makes sense, but I'd like to hear it from one
of the very human DT maintainers.

					-Alex

> 
>> +					compatible = "simple-bus";
>> +					#address-cells = <1>;
>> +					#size-cells = <1>;
>> +					/* Map 0x0-0x1fffff to BAR 4 */
>> +					ranges = <0x0  0x4 0x0 0x0  0x200000>;
>> +				};
>>   			};
>>   
>>   			dev@0,1 {
>> +				compatible = "pci1179,0220";
>>   				reg = <0x50100 0x0 0x0 0x0 0x0>;
>> +				#address-cells = <3>;
>> +				#size-cells = <2>;
>> +				/* Ranges will be updated dynamically */
>> +				ranges = <0x0 0x0 0x0  0x83050100 0x0 0x0 0x0 0x4000>,
>> +					 <0x2 0x0 0x0  0x83050100 0x0 0x0 0x0 0x80000>,
>> +					 <0x4 0x0 0x0  0x83050100 0x0 0x0 0x0 0x200000>;
> 
> [Severity: High]
> Similarly for dev@0,1, will this static definition prevent dynamic ranges
> updates? If of_pci_add_properties() is skipped due to the node already
> existing, the dummy physical addresses will remain and could cause register
> corruption or crashes if child drivers probe here.
> 
>> +
>> +				pci-ep-bus@4 {
> 
> [Severity: Low]
> This node is also named with @4 but does not define a reg property, which
> can trigger a dtc unit_address_vs_reg warning.
> 
>> +					compatible = "simple-bus";
>> +					#address-cells = <1>;
>> +					#size-cells = <1>;
>> +					/* Map 0x0-0x1fffff to BAR 4 */
>> +					ranges = <0x0  0x4 0x0 0x0  0x200000>;
>> +				};
>>   			};
>>   		};
>>   	};
>