[PATCH 0/2] reset: introduce TC9564 reset support

[PATCH 0/2] reset: introduce TC9564 reset support

[Alex Elder]

This series adds support for the reset controller present within
the Toshiba TC9564 SoC.  It is being considered the first version
of the series despite being previously posted as part of a combined
clock/reset driver:
  https://lore.kernel.org/lkml/20260918165234.687224-1-elder@riscstar.com/

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 resets.

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

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

Note:
  Other TC9564 drivers have been posted together with DTS file
  updates for the Qualcomm RB3gen2.  To allow this (and a few
  other) drivers to be considered in isolation, I'm omiting
  that here.  (I can add it to future versions if requested.)
      

					-Alex

Alex Elder (2):
  dt-bindings: reset: introduce toshiba,tc9564-reset.yaml
  reset: toshiba: introduce a TC9564 SoC reset driver

 .../bindings/reset/toshiba,tc9564-reset.yaml  |  56 +++++
 MAINTAINERS                                   |   8 +
 drivers/reset/Kconfig                         |  12 ++
 drivers/reset/Makefile                        |   1 +
 drivers/reset/reset-tc9564.c                  | 192 ++++++++++++++++++
 include/dt-bindings/reset/toshiba,tc9564.h    |  26 +++
 6 files changed, 295 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
 create mode 100644 drivers/reset/reset-tc9564.c
 create mode 100644 include/dt-bindings/reset/toshiba,tc9564.h


base-commit: becb95e45ef0dda9ffb35156d909d3da7a2789c3
-- 
2.53.0

[PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[Alex Elder]

Define the binding for the reset controller functionality present in
the Toshiba TC9564 SoC.

Co-developed-by: Daniel Thompson <daniel@riscstar.com>
Signed-off-by: Daniel Thompson <daniel@riscstar.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
---
 .../bindings/reset/toshiba,tc9564-reset.yaml  | 56 +++++++++++++++++++
 MAINTAINERS                                   |  7 +++
 include/dt-bindings/reset/toshiba,tc9564.h    | 26 +++++++++
 3 files changed, 89 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
 create mode 100644 include/dt-bindings/reset/toshiba,tc9564.h

diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
new file mode 100644
index 0000000000000..1908e9539abac
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/toshiba,tc9564-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC9564 Reset 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 reset controller) via its BARs.
+
+  A total of 13 resets are implemented, though two of these are not
+  controllable.  Access to the reset controller relies on PCIe being
+  functional, so the PCIe reset is assumed to be deasserted.  Similarly,
+  the PCIe controller relies on I2C, so the I2C reset is also assumed
+  to be deasserted.
+
+  Reset ids are defined in <dt-bindings/reset/toshiba,tc9564.h>.
+
+  The reset controller uses registers within the same page as a
+  clock controller, so both devices are defined as children of a
+  "config" syscon.
+
+properties:
+  compatible:
+    const: toshiba,tc9564-reset
+
+  "#reset-cells":
+    const: 1
+
+required:
+  - compatible
+  - "#reset-cells"
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/reset/toshiba,tc9564.h>
+
+    syscon@0 {
+        compatible = "syscon", "simple-mfd";
+        reg = <0x0 0x2000>;
+
+        reset {
+            compatible = "toshiba,tc9564-reset";
+            #reset-cells = <1>;
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 252b6d7ee1638..d0eb44079fe17 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28180,6 +28180,13 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/misc/pci1179,0220.yaml
 F:	drivers/misc/tc9564-pci.c
 
+TOSHIBA TC9564 RESET DRIVER
+M:	Alex Elder <elder@kernel.org>
+M:	Daniel Thompson <danielt@kernel.org>
+S:	Maintained
+F:	Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
+F:	include/dt-bindings/reset/toshiba,tc9564.h
+
 TOSHIBA WMI HOTKEYS DRIVER
 M:	Azael Avalos <coproscefalo@gmail.com>
 L:	platform-driver-x86@vger.kernel.org
diff --git a/include/dt-bindings/reset/toshiba,tc9564.h b/include/dt-bindings/reset/toshiba,tc9564.h
new file mode 100644
index 0000000000000..5fcc9a06d4ff6
--- /dev/null
+++ b/include/dt-bindings/reset/toshiba,tc9564.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */
+
+#ifndef __RESET_TOSHIBA_TC9564_H__
+#define __RESET_TOSHIBA_TC9564_H__
+
+/* Reset IDs */
+
+#define RESET_MCU		0
+#define RESET_MCU1		1
+#define RESET_MSIGEN		2
+#define RESET_INTC		3
+#define RESET_UART		4
+
+#define RESET_MAC0_MAC		5
+#define RESET_MAC0_PMA		6
+#define RESET_MAC0_XPCS		7
+
+#define RESET_MAC1_MAC		8
+#define RESET_MAC1_PMA		9
+#define RESET_MAC1_XPCS		10
+
+#endif /* __RESET_TOSHIBA_TC9564_H__*/
-- 
2.53.0

Re: [PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: syscon missing hardware-specific compatible in example
- [Low] dt-bindings: incorrect node name 'reset' instead of 'reset-controller'
--

commit 86eb967be387fadac7b22aba279d8ed01983af26
Author: Alex Elder <elder@riscstar.com>

dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

This commit defines the binding for the reset controller functionality present
in the Toshiba TC9564 SoC. It includes a new YAML schema, a header file for
the reset IDs, and updates the MAINTAINERS file.

> diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml

[ ... ]

> +examples:
> +  - |
> +    #include <dt-bindings/reset/toshiba,tc9564.h>
> +
> +    syscon@0 {
> +        compatible = "syscon", "simple-mfd";

[Severity: Low]
Does this example fail dt_binding_check validation? The core syscon.yaml
schema typically requires a hardware-specific compatible string to precede
generic fallbacks like "syscon" and "simple-mfd".

> +        reg = <0x0 0x2000>;
> +
> +        reset {

[Severity: Low]
Should this node be named "reset-controller" instead of "reset"? The core
reset.yaml schema enforces the ^reset-controller(@.*)?$ naming convention
for nodes providing resets (identified by the #reset-cells property).

> +            compatible = "toshiba,tc9564-reset";
> +            #reset-cells = <1>;
> +        };
> +    };

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

Re: [PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[Alex Elder]

On 10/12/26 11:48 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] dt-bindings: syscon missing hardware-specific compatible in example
> - [Low] dt-bindings: incorrect node name 'reset' instead of 'reset-controller'
> --
> 
> commit 86eb967be387fadac7b22aba279d8ed01983af26
> Author: Alex Elder <elder@riscstar.com>
> 
> dt-bindings: reset: introduce toshiba,tc9564-reset.yaml
> 
> This commit defines the binding for the reset controller functionality present
> in the Toshiba TC9564 SoC. It includes a new YAML schema, a header file for
> the reset IDs, and updates the MAINTAINERS file.
> 
>> diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>> new file mode 100644
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> 
> [ ... ]
> 
>> +examples:
>> +  - |
>> +    #include <dt-bindings/reset/toshiba,tc9564.h>


Unfortunately I hadn't noticed this before I sent it.
Krzysztof pointed out in the clock series, including this
here is unnecessary, because its contents are not actually
used in the example.  I will remove this for version 2.

>> +
>> +    syscon@0 {
>> +        compatible = "syscon", "simple-mfd";
> 
> [Severity: Low]
> Does this example fail dt_binding_check validation? The core syscon.yaml
> schema typically requires a hardware-specific compatible string to precede
> generic fallbacks like "syscon" and "simple-mfd".

It did not fail dt_binding_check validation for me, however I
am rarely surprised to discover there are errors in my bindings...

>> +        reg = <0x0 0x2000>;
>> +
>> +        reset {
> 
> [Severity: Low]
> Should this node be named "reset-controller" instead of "reset"? The core
> reset.yaml schema enforces the ^reset-controller(@.*)?$ naming convention
> for nodes providing resets (identified by the #reset-cells property).

Yes it should.  I corrected this in my private DTS file but
neglected to correct it in the binding example.  I will fix
this when I send version 2.

					-Alex

>> +            compatible = "toshiba,tc9564-reset";
>> +            #reset-cells = <1>;
>> +        };
>> +    };
> 

Re: [PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 4761 bytes --]

On Mon, Oct 12, 2026 at 11:43:52AM -0500, Alex Elder wrote:
> Define the binding for the reset controller functionality present in
> the Toshiba TC9564 SoC.
> 
> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> ---
>  .../bindings/reset/toshiba,tc9564-reset.yaml  | 56 +++++++++++++++++++
>  MAINTAINERS                                   |  7 +++
>  include/dt-bindings/reset/toshiba,tc9564.h    | 26 +++++++++
>  3 files changed, 89 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>  create mode 100644 include/dt-bindings/reset/toshiba,tc9564.h
> 
> diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> new file mode 100644
> index 0000000000000..1908e9539abac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/toshiba,tc9564-reset.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba TC9564 Reset 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 reset controller) via its BARs.
> +
> +  A total of 13 resets are implemented, though two of these are not
> +  controllable.  Access to the reset controller relies on PCIe being
> +  functional, so the PCIe reset is assumed to be deasserted.  Similarly,
> +  the PCIe controller relies on I2C, so the I2C reset is also assumed
> +  to be deasserted.
> +
> +  Reset ids are defined in <dt-bindings/reset/toshiba,tc9564.h>.
> +
> +  The reset controller uses registers within the same page as a
> +  clock controller, so both devices are defined as children of a
> +  "config" syscon.
> +
> +properties:
> +  compatible:
> +    const: toshiba,tc9564-reset

Why does this need to exist as a standalone device, rather than be
rolled up into the parent syscon node? It doesn't have any resources, so
it should be doable.

This kind of thing for a syscon is always difficult to review when only
one element is present - where is the rest of the syscon's
functionality?

Thanks,
Conor.

> +
> +  "#reset-cells":
> +    const: 1
> +
> +required:
> +  - compatible
> +  - "#reset-cells"
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/reset/toshiba,tc9564.h>
> +
> +    syscon@0 {
> +        compatible = "syscon", "simple-mfd";
> +        reg = <0x0 0x2000>;
> +
> +        reset {
> +            compatible = "toshiba,tc9564-reset";
> +            #reset-cells = <1>;
> +        };
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 252b6d7ee1638..d0eb44079fe17 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -28180,6 +28180,13 @@ S:	Maintained
>  F:	Documentation/devicetree/bindings/misc/pci1179,0220.yaml
>  F:	drivers/misc/tc9564-pci.c
>  
> +TOSHIBA TC9564 RESET DRIVER
> +M:	Alex Elder <elder@kernel.org>
> +M:	Daniel Thompson <danielt@kernel.org>
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> +F:	include/dt-bindings/reset/toshiba,tc9564.h
> +
>  TOSHIBA WMI HOTKEYS DRIVER
>  M:	Azael Avalos <coproscefalo@gmail.com>
>  L:	platform-driver-x86@vger.kernel.org
> diff --git a/include/dt-bindings/reset/toshiba,tc9564.h b/include/dt-bindings/reset/toshiba,tc9564.h
> new file mode 100644
> index 0000000000000..5fcc9a06d4ff6
> --- /dev/null
> +++ b/include/dt-bindings/reset/toshiba,tc9564.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +/*
> + * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
> + */
> +
> +#ifndef __RESET_TOSHIBA_TC9564_H__
> +#define __RESET_TOSHIBA_TC9564_H__
> +
> +/* Reset IDs */
> +
> +#define RESET_MCU		0
> +#define RESET_MCU1		1
> +#define RESET_MSIGEN		2
> +#define RESET_INTC		3
> +#define RESET_UART		4
> +
> +#define RESET_MAC0_MAC		5
> +#define RESET_MAC0_PMA		6
> +#define RESET_MAC0_XPCS		7
> +
> +#define RESET_MAC1_MAC		8
> +#define RESET_MAC1_PMA		9
> +#define RESET_MAC1_XPCS		10
> +
> +#endif /* __RESET_TOSHIBA_TC9564_H__*/
> -- 
> 2.53.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[Alex Elder]

On 10/12/26 1:51 PM, Conor Dooley wrote:
> On Mon, Oct 12, 2026 at 11:43:52AM -0500, Alex Elder wrote:
>> Define the binding for the reset controller functionality present in
>> the Toshiba TC9564 SoC.
>>
>> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> ---
>>   .../bindings/reset/toshiba,tc9564-reset.yaml  | 56 +++++++++++++++++++
>>   MAINTAINERS                                   |  7 +++
>>   include/dt-bindings/reset/toshiba,tc9564.h    | 26 +++++++++
>>   3 files changed, 89 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>>   create mode 100644 include/dt-bindings/reset/toshiba,tc9564.h
>>
>> diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>> new file mode 100644
>> index 0000000000000..1908e9539abac
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>> @@ -0,0 +1,56 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/reset/toshiba,tc9564-reset.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Toshiba TC9564 Reset 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 reset controller) via its BARs.
>> +
>> +  A total of 13 resets are implemented, though two of these are not
>> +  controllable.  Access to the reset controller relies on PCIe being
>> +  functional, so the PCIe reset is assumed to be deasserted.  Similarly,
>> +  the PCIe controller relies on I2C, so the I2C reset is also assumed
>> +  to be deasserted.
>> +
>> +  Reset ids are defined in <dt-bindings/reset/toshiba,tc9564.h>.
>> +
>> +  The reset controller uses registers within the same page as a
>> +  clock controller, so both devices are defined as children of a
>> +  "config" syscon.
>> +
>> +properties:
>> +  compatible:
>> +    const: toshiba,tc9564-reset
> 
> Why does this need to exist as a standalone device, rather than be
> rolled up into the parent syscon node? It doesn't have any resources, so
> it should be doable.

This is along the lines of what Krzysztof has mentioned, and it
seems clear I must be missing something.

> This kind of thing for a syscon is always difficult to review when only
> one element is present - where is the rest of the syscon's
> functionality?

The reason a syscon was used was simply for the benefit of
having a shared regmap that the reset, clock, and DWMAC drivers
can use.  All three of those drivers use registers that reside
within a single page of addressible MMIO space.  And I don't
know that I can guarantee their probe order.

There is otherwise no "system controller" that is treated as
a logical entity within the SoC.

What is the proper way for me to represent this?  It's fairly
simple; and I mainly want to ensure all three of those drivers
can safely access their addresses.

Thanks.

					-Alex


> Thanks,
> Conor.
> 
>> +
>> +  "#reset-cells":
>> +    const: 1
>> +
>> +required:
>> +  - compatible
>> +  - "#reset-cells"
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/reset/toshiba,tc9564.h>
>> +
>> +    syscon@0 {
>> +        compatible = "syscon", "simple-mfd";
>> +        reg = <0x0 0x2000>;
>> +
>> +        reset {
>> +            compatible = "toshiba,tc9564-reset";
>> +            #reset-cells = <1>;
>> +        };
>> +    };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 252b6d7ee1638..d0eb44079fe17 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -28180,6 +28180,13 @@ S:	Maintained
>>   F:	Documentation/devicetree/bindings/misc/pci1179,0220.yaml
>>   F:	drivers/misc/tc9564-pci.c
>>   
>> +TOSHIBA TC9564 RESET DRIVER
>> +M:	Alex Elder <elder@kernel.org>
>> +M:	Daniel Thompson <danielt@kernel.org>
>> +S:	Maintained
>> +F:	Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>> +F:	include/dt-bindings/reset/toshiba,tc9564.h
>> +
>>   TOSHIBA WMI HOTKEYS DRIVER
>>   M:	Azael Avalos <coproscefalo@gmail.com>
>>   L:	platform-driver-x86@vger.kernel.org
>> diff --git a/include/dt-bindings/reset/toshiba,tc9564.h b/include/dt-bindings/reset/toshiba,tc9564.h
>> new file mode 100644
>> index 0000000000000..5fcc9a06d4ff6
>> --- /dev/null
>> +++ b/include/dt-bindings/reset/toshiba,tc9564.h
>> @@ -0,0 +1,26 @@
>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>> +
>> +/*
>> + * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
>> + */
>> +
>> +#ifndef __RESET_TOSHIBA_TC9564_H__
>> +#define __RESET_TOSHIBA_TC9564_H__
>> +
>> +/* Reset IDs */
>> +
>> +#define RESET_MCU		0
>> +#define RESET_MCU1		1
>> +#define RESET_MSIGEN		2
>> +#define RESET_INTC		3
>> +#define RESET_UART		4
>> +
>> +#define RESET_MAC0_MAC		5
>> +#define RESET_MAC0_PMA		6
>> +#define RESET_MAC0_XPCS		7
>> +
>> +#define RESET_MAC1_MAC		8
>> +#define RESET_MAC1_PMA		9
>> +#define RESET_MAC1_XPCS		10
>> +
>> +#endif /* __RESET_TOSHIBA_TC9564_H__*/
>> -- 
>> 2.53.0
>>

Re: [PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 7170 bytes --]

On Mon, Oct 12, 2026 at 02:10:01PM -0500, Alex Elder wrote:
> On 10/12/26 1:51 PM, Conor Dooley wrote:
> > On Mon, Oct 12, 2026 at 11:43:52AM -0500, Alex Elder wrote:
> > > Define the binding for the reset controller functionality present in
> > > the Toshiba TC9564 SoC.
> > > 
> > > Co-developed-by: Daniel Thompson <daniel@riscstar.com>
> > > Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> > > Signed-off-by: Alex Elder <elder@riscstar.com>
> > > ---
> > >   .../bindings/reset/toshiba,tc9564-reset.yaml  | 56 +++++++++++++++++++
> > >   MAINTAINERS                                   |  7 +++
> > >   include/dt-bindings/reset/toshiba,tc9564.h    | 26 +++++++++
> > >   3 files changed, 89 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> > >   create mode 100644 include/dt-bindings/reset/toshiba,tc9564.h
> > > 
> > > diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> > > new file mode 100644
> > > index 0000000000000..1908e9539abac
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> > > @@ -0,0 +1,56 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/reset/toshiba,tc9564-reset.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Toshiba TC9564 Reset 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 reset controller) via its BARs.
> > > +
> > > +  A total of 13 resets are implemented, though two of these are not
> > > +  controllable.  Access to the reset controller relies on PCIe being
> > > +  functional, so the PCIe reset is assumed to be deasserted.  Similarly,
> > > +  the PCIe controller relies on I2C, so the I2C reset is also assumed
> > > +  to be deasserted.
> > > +
> > > +  Reset ids are defined in <dt-bindings/reset/toshiba,tc9564.h>.
> > > +
> > > +  The reset controller uses registers within the same page as a
> > > +  clock controller, so both devices are defined as children of a
> > > +  "config" syscon.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: toshiba,tc9564-reset
> > 
> > Why does this need to exist as a standalone device, rather than be
> > rolled up into the parent syscon node? It doesn't have any resources, so
> > it should be doable.
> 
> This is along the lines of what Krzysztof has mentioned, and it
> seems clear I must be missing something.
> 
> > This kind of thing for a syscon is always difficult to review when only
> > one element is present - where is the rest of the syscon's
> > functionality?
> 
> The reason a syscon was used was simply for the benefit of
> having a shared regmap that the reset, clock, and DWMAC drivers
> can use.  All three of those drivers use registers that reside
> within a single page of addressible MMIO space.

What does the dwmac use the region for? I assume it's for some misc
register and you don't mean that the dwmac lies within the region?

There's nothing inherently wrong with the act of using of a syscon here,
what I am actually complaining about is how you are using it.
In cases where a syscon region contains clock and reset, the typical way
we want people to do this is via something like

syscon@f00 {
	compatible = "toshiba,tc9564-bla-syscon", "syscon", "simple-mfd";
	reg = <0x0 0x2000>;
	#reset-cells = <1>;
	#clock-cells = <1>;
};

because the child node exists for no other reason than to access linux
driver probing in the most trivial way. If there's some features that
actually need a child node, that's fine, but those will end up being
things with significantly more properties or things with competing
property use (e.g. if there were devices with buses that need
address/size cells).

> And I don't know that I can guarantee their probe order.

I am assuming this is moot, since I am not objecting to using a syscon?

> There is otherwise no "system controller" that is treated as
> a logical entity within the SoC.
> 
> What is the proper way for me to represent this?  It's fairly
> simple; and I mainly want to ensure all three of those drivers
> can safely access their addresses.

What else does this region actually contain?

Cheers,
Conor.

> > > +
> > > +  "#reset-cells":
> > > +    const: 1
> > > +
> > > +required:
> > > +  - compatible
> > > +  - "#reset-cells"
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/reset/toshiba,tc9564.h>
> > > +
> > > +    syscon@0 {
> > > +        compatible = "syscon", "simple-mfd";
> > > +        reg = <0x0 0x2000>;
> > > +
> > > +        reset {
> > > +            compatible = "toshiba,tc9564-reset";
> > > +            #reset-cells = <1>;
> > > +        };
> > > +    };
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 252b6d7ee1638..d0eb44079fe17 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -28180,6 +28180,13 @@ S:	Maintained
> > >   F:	Documentation/devicetree/bindings/misc/pci1179,0220.yaml
> > >   F:	drivers/misc/tc9564-pci.c
> > > +TOSHIBA TC9564 RESET DRIVER
> > > +M:	Alex Elder <elder@kernel.org>
> > > +M:	Daniel Thompson <danielt@kernel.org>
> > > +S:	Maintained
> > > +F:	Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> > > +F:	include/dt-bindings/reset/toshiba,tc9564.h
> > > +
> > >   TOSHIBA WMI HOTKEYS DRIVER
> > >   M:	Azael Avalos <coproscefalo@gmail.com>
> > >   L:	platform-driver-x86@vger.kernel.org
> > > diff --git a/include/dt-bindings/reset/toshiba,tc9564.h b/include/dt-bindings/reset/toshiba,tc9564.h
> > > new file mode 100644
> > > index 0000000000000..5fcc9a06d4ff6
> > > --- /dev/null
> > > +++ b/include/dt-bindings/reset/toshiba,tc9564.h
> > > @@ -0,0 +1,26 @@
> > > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > > +
> > > +/*
> > > + * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
> > > + */
> > > +
> > > +#ifndef __RESET_TOSHIBA_TC9564_H__
> > > +#define __RESET_TOSHIBA_TC9564_H__
> > > +
> > > +/* Reset IDs */
> > > +
> > > +#define RESET_MCU		0
> > > +#define RESET_MCU1		1
> > > +#define RESET_MSIGEN		2
> > > +#define RESET_INTC		3
> > > +#define RESET_UART		4
> > > +
> > > +#define RESET_MAC0_MAC		5
> > > +#define RESET_MAC0_PMA		6
> > > +#define RESET_MAC0_XPCS		7
> > > +
> > > +#define RESET_MAC1_MAC		8
> > > +#define RESET_MAC1_PMA		9
> > > +#define RESET_MAC1_XPCS		10
> > > +
> > > +#endif /* __RESET_TOSHIBA_TC9564_H__*/
> > > -- 
> > > 2.53.0
> > > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[Alex Elder]

On 10/12/26 4:22 PM, Conor Dooley wrote:
> On Mon, Oct 12, 2026 at 02:10:01PM -0500, Alex Elder wrote:
>> On 10/12/26 1:51 PM, Conor Dooley wrote:
>>> On Mon, Oct 12, 2026 at 11:43:52AM -0500, Alex Elder wrote:
>>>> Define the binding for the reset controller functionality present in
>>>> the Toshiba TC9564 SoC.
>>>>
>>>> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
>>>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>>>> Signed-off-by: Alex Elder <elder@riscstar.com>
>>>> ---
>>>>    .../bindings/reset/toshiba,tc9564-reset.yaml  | 56 +++++++++++++++++++
>>>>    MAINTAINERS                                   |  7 +++
>>>>    include/dt-bindings/reset/toshiba,tc9564.h    | 26 +++++++++
>>>>    3 files changed, 89 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>>>>    create mode 100644 include/dt-bindings/reset/toshiba,tc9564.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>>>> new file mode 100644
>>>> index 0000000000000..1908e9539abac
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>>>> @@ -0,0 +1,56 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/reset/toshiba,tc9564-reset.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Toshiba TC9564 Reset 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 reset controller) via its BARs.
>>>> +
>>>> +  A total of 13 resets are implemented, though two of these are not
>>>> +  controllable.  Access to the reset controller relies on PCIe being
>>>> +  functional, so the PCIe reset is assumed to be deasserted.  Similarly,
>>>> +  the PCIe controller relies on I2C, so the I2C reset is also assumed
>>>> +  to be deasserted.
>>>> +
>>>> +  Reset ids are defined in <dt-bindings/reset/toshiba,tc9564.h>.
>>>> +
>>>> +  The reset controller uses registers within the same page as a
>>>> +  clock controller, so both devices are defined as children of a
>>>> +  "config" syscon.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: toshiba,tc9564-reset
>>>
>>> Why does this need to exist as a standalone device, rather than be
>>> rolled up into the parent syscon node? It doesn't have any resources, so
>>> it should be doable.
>>
>> This is along the lines of what Krzysztof has mentioned, and it
>> seems clear I must be missing something.
>>
>>> This kind of thing for a syscon is always difficult to review when only
>>> one element is present - where is the rest of the syscon's
>>> functionality?
>>
>> The reason a syscon was used was simply for the benefit of
>> having a shared regmap that the reset, clock, and DWMAC drivers
>> can use.  All three of those drivers use registers that reside
>> within a single page of addressible MMIO space.
> 
> What does the dwmac use the region for? I assume it's for some misc
> register and you don't mean that the dwmac lies within the region?

That's right.  There is one register (per DWMAC--there are two)
that contains one bit (bit 21) that is used to signal that 
initialization of the PMA is done.  We assert reset, set up
clocks, then deassert, and finally wait for this bit to be set.
The DWMAC code uses a phandle property to refer to the syscon,
like:
     toshiba,config-syscon = <&tc9564_config_syscon0 0x1070>

So again, the purpose of the syscon was to get the automatic
regmap for managing the region, which contains registers used
for distinct purposes.

After making the syscon be the parent of both the reset and
clock nodes, I *removed* the "reg" properties and just defined
those offsets in the driver.  Maybe that was a mistake.
> There's nothing inherently wrong with the act of using of a syscon here,
> what I am actually complaining about is how you are using it.
> In cases where a syscon region contains clock and reset, the typical way
> we want people to do this is via something like
> 
> syscon@f00 {
> 	compatible = "toshiba,tc9564-bla-syscon", "syscon", "simple-mfd";
> 	reg = <0x0 0x2000>;
> 	#reset-cells = <1>;
> 	#clock-cells = <1>;
> };

In this case it seems I must create a syscon driver that provides
combined reset and clock functionality.  Is that right?  (This
series is the result of separating the reset code from the clock
code in a combined driver.)

To be honest I don't have a lot of experience with proper use of
syscons.  I have no problem writing or restructuring the code,
it just seems I need help knowing what the final structure should
look like.

> because the child node exists for no other reason than to access linux
> driver probing in the most trivial way. If there's some features that
> actually need a child node, that's fine, but those will end up being
> things with significantly more properties or things with competing
> property use (e.g. if there were devices with buses that need
> address/size cells).

I'm not sure I understand this statement (and that might be part
of the problem).

There are other devices (currently just two DWMACs, plus an
interrupt controller that generates MSIs for each PCI function)
that use the reset and clock signals.  I haven't yet
posted the reworked DWMAC code but I just sent the first version
of the interrupt driver yesterday.
   https://lore.kernel.org/lkml/20261012190245.3988619-1-elder@riscstar.com/

>> And I don't know that I can guarantee their probe order.
> 
> I am assuming this is moot, since I am not objecting to using a syscon?
> 
>> There is otherwise no "system controller" that is treated as
>> a logical entity within the SoC.
>>
>> What is the proper way for me to represent this?  It's fairly
>> simple; and I mainly want to ensure all three of those drivers
>> can safely access their addresses.
> 
> What else does this region actually contain?

At this point I've described everything we now use.  Two
registers control a set of resets; two registers enable and
disable a set of clocks; and two registers each contain a
bit to signal readiness of a DWMAC device.

There are other registers in this region, but at this time
we don't use them.

					-Alex

> 
> Cheers,
> Conor.
> 
>>>> +
>>>> +  "#reset-cells":
>>>> +    const: 1
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - "#reset-cells"
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +    #include <dt-bindings/reset/toshiba,tc9564.h>
>>>> +
>>>> +    syscon@0 {
>>>> +        compatible = "syscon", "simple-mfd";
>>>> +        reg = <0x0 0x2000>;
>>>> +
>>>> +        reset {
>>>> +            compatible = "toshiba,tc9564-reset";
>>>> +            #reset-cells = <1>;
>>>> +        };
>>>> +    };
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 252b6d7ee1638..d0eb44079fe17 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -28180,6 +28180,13 @@ S:	Maintained
>>>>    F:	Documentation/devicetree/bindings/misc/pci1179,0220.yaml
>>>>    F:	drivers/misc/tc9564-pci.c
>>>> +TOSHIBA TC9564 RESET DRIVER
>>>> +M:	Alex Elder <elder@kernel.org>
>>>> +M:	Daniel Thompson <danielt@kernel.org>
>>>> +S:	Maintained
>>>> +F:	Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
>>>> +F:	include/dt-bindings/reset/toshiba,tc9564.h
>>>> +
>>>>    TOSHIBA WMI HOTKEYS DRIVER
>>>>    M:	Azael Avalos <coproscefalo@gmail.com>
>>>>    L:	platform-driver-x86@vger.kernel.org
>>>> diff --git a/include/dt-bindings/reset/toshiba,tc9564.h b/include/dt-bindings/reset/toshiba,tc9564.h
>>>> new file mode 100644
>>>> index 0000000000000..5fcc9a06d4ff6
>>>> --- /dev/null
>>>> +++ b/include/dt-bindings/reset/toshiba,tc9564.h
>>>> @@ -0,0 +1,26 @@
>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>>>> +
>>>> +/*
>>>> + * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
>>>> + */
>>>> +
>>>> +#ifndef __RESET_TOSHIBA_TC9564_H__
>>>> +#define __RESET_TOSHIBA_TC9564_H__
>>>> +
>>>> +/* Reset IDs */
>>>> +
>>>> +#define RESET_MCU		0
>>>> +#define RESET_MCU1		1
>>>> +#define RESET_MSIGEN		2
>>>> +#define RESET_INTC		3
>>>> +#define RESET_UART		4
>>>> +
>>>> +#define RESET_MAC0_MAC		5
>>>> +#define RESET_MAC0_PMA		6
>>>> +#define RESET_MAC0_XPCS		7
>>>> +
>>>> +#define RESET_MAC1_MAC		8
>>>> +#define RESET_MAC1_PMA		9
>>>> +#define RESET_MAC1_XPCS		10
>>>> +
>>>> +#endif /* __RESET_TOSHIBA_TC9564_H__*/
>>>> -- 
>>>> 2.53.0
>>>>
>>

Re: [PATCH 1/2] dt-bindings: reset: introduce toshiba,tc9564-reset.yaml

[Krzysztof Kozlowski]

On Mon, Oct 12, 2026 at 07:51:18PM +0100, Conor Dooley wrote:
> On Mon, Oct 12, 2026 at 11:43:52AM -0500, Alex Elder wrote:
> > Define the binding for the reset controller functionality present in
> > the Toshiba TC9564 SoC.
> > 
> > Co-developed-by: Daniel Thompson <daniel@riscstar.com>
> > Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> > Signed-off-by: Alex Elder <elder@riscstar.com>
> > ---
> >  .../bindings/reset/toshiba,tc9564-reset.yaml  | 56 +++++++++++++++++++
> >  MAINTAINERS                                   |  7 +++
> >  include/dt-bindings/reset/toshiba,tc9564.h    | 26 +++++++++
> >  3 files changed, 89 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> >  create mode 100644 include/dt-bindings/reset/toshiba,tc9564.h
> > 
> > diff --git a/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> > new file mode 100644
> > index 0000000000000..1908e9539abac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
> > @@ -0,0 +1,56 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/reset/toshiba,tc9564-reset.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Toshiba TC9564 Reset 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 reset controller) via its BARs.
> > +
> > +  A total of 13 resets are implemented, though two of these are not
> > +  controllable.  Access to the reset controller relies on PCIe being
> > +  functional, so the PCIe reset is assumed to be deasserted.  Similarly,
> > +  the PCIe controller relies on I2C, so the I2C reset is also assumed
> > +  to be deasserted.
> > +
> > +  Reset ids are defined in <dt-bindings/reset/toshiba,tc9564.h>.
> > +
> > +  The reset controller uses registers within the same page as a
> > +  clock controller, so both devices are defined as children of a
> > +  "config" syscon.
> > +
> > +properties:
> > +  compatible:
> > +    const: toshiba,tc9564-reset
> 
> Why does this need to exist as a standalone device, rather than be
> rolled up into the parent syscon node? It doesn't have any resources, so
> it should be doable.

I am asking to fold into the parent for multiple revisions now.

> 
> This kind of thing for a syscon is always difficult to review when only
> one element is present - where is the rest of the syscon's
> functionality?
> 
> Thanks,
> Conor.
> 
> > +
> > +  "#reset-cells":
> > +    const: 1
> > +
> > +required:
> > +  - compatible
> > +  - "#reset-cells"
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/reset/toshiba,tc9564.h>
> > +
> > +    syscon@0 {
> > +        compatible = "syscon", "simple-mfd";

Such combination is not allowed. Bindings produce a warning, probably.
Anyway, node is pointless here.

Best regards,
Krzysztof

[PATCH 2/2] reset: toshiba: introduce a TC9564 SoC reset driver

[Alex Elder]

Define a new platform driver that manages reset signals implemented by
the Toshiba TC9564 SoC.  There are 13 reset signals available, although
only 11 can be controlled.

Two registers manage the state of the resets.  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 reset
cannot be manipulated by this driver (it is assumed to be deasserted).
Similarly, control is not available for the I2C reset, 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>
---
 MAINTAINERS                  |   1 +
 drivers/reset/Kconfig        |  12 +++
 drivers/reset/Makefile       |   1 +
 drivers/reset/reset-tc9564.c | 192 +++++++++++++++++++++++++++++++++++
 4 files changed, 206 insertions(+)
 create mode 100644 drivers/reset/reset-tc9564.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d0eb44079fe17..a8f4982ed1a43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28185,6 +28185,7 @@ M:	Alex Elder <elder@kernel.org>
 M:	Daniel Thompson <danielt@kernel.org>
 S:	Maintained
 F:	Documentation/devicetree/bindings/reset/toshiba,tc9564-reset.yaml
+F:	drivers/reset/reset-tc9564.c
 F:	include/dt-bindings/reset/toshiba,tc9564.h
 
 TOSHIBA WMI HOTKEYS DRIVER
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index eda9c698a95f3..b40736368894c 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -358,6 +358,18 @@ config RESET_SUNXI
 	help
 	  This enables the reset driver for Allwinner SoCs.
 
+config RESET_TC9564
+	tristate "Toshiba TC9564 reset support"
+	depends on TC9564_PCI
+	select MFD_SYSCON
+	default TC9564_PCI
+	help
+	  This enables support for the reset controller embedded in the
+	  Toshiba TC9564 SoC.  The state of reset lines is controlled
+	  via MMIO to a region managed by a system controller; this
+	  ensures access to the region is coordinated between this and
+	  the clock and XGMAC (stmmac) drivers.
+
 config RESET_TENSTORRENT_ATLANTIS
 	tristate "Tenstorrent atlantis reset driver"
 	depends on ARCH_TENSTORRENT || COMPILE_TEST
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 489fafd6bbe3f..6ddded26309ef 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_RESET_SKY1_AUDSS) += reset-sky1-audss.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_RESET_SUNPLUS) += reset-sunplus.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_RESET_TC9564) += reset-tc9564.o
 obj-$(CONFIG_RESET_TENSTORRENT_ATLANTIS) += reset-tenstorrent-atlantis.o
 obj-$(CONFIG_RESET_TH1520) += reset-th1520.o
 obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
diff --git a/drivers/reset/reset-tc9564.c b/drivers/reset/reset-tc9564.c
new file mode 100644
index 0000000000000..0243c2e0efd54
--- /dev/null
+++ b/drivers/reset/reset-tc9564.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation.  All rights reserved.
+ */
+
+#include <linux/bits.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/reset-controller.h>
+
+#include <dt-bindings/reset/toshiba,tc9564.h>
+
+#define RST_CTRL0_OFFSET	0x1008
+#define RST_CTRL1_OFFSET	0x1010
+
+struct tc9564_reset {
+	u32 offset;		/* RST_CTRL0_OFFSET or RST_CTRL1_OFFSET */
+	u32 mask;		/* Zero means undefined reset */
+};
+
+struct tc9564_resets {
+	struct regmap *regmap;
+	struct reset_controller_dev rcdev;
+};
+
+#define TC9564_RESET_INIT0(_name, _bit)	__TC9564_RESET_INIT(_name, 0, _bit)
+#define TC9564_RESET_INIT1(_name, _bit)	__TC9564_RESET_INIT(_name, 1, _bit)
+
+#define __TC9564_RESET_INIT(_name, _reg, _bit)		\
+	[RESET_##_name] = {				\
+		.offset	= RST_CTRL ## _reg ## _OFFSET,	\
+		.mask = BIT(_bit),			\
+	}
+
+/*
+ * The PCIe and I2C resets are controllable, but we depend on PCIe
+ * and that relies on I2C, so we don't allow them to be asserted.
+ */
+static const struct tc9564_reset tc9564_reset[] = {
+	TC9564_RESET_INIT0(MCU, 0),
+	TC9564_RESET_INIT0(MCU1, 1),
+	TC9564_RESET_INIT0(INTC, 4),
+	/* TC9564_RESET_INIT0(PCIE, 9), */
+	/* TC9564_RESET_INIT0(I2C, 12), */
+	TC9564_RESET_INIT0(UART, 16),
+	TC9564_RESET_INIT0(MSIGEN, 18),
+
+	TC9564_RESET_INIT0(MAC0_MAC, 7),
+	TC9564_RESET_INIT0(MAC0_PMA, 30),
+	TC9564_RESET_INIT0(MAC0_XPCS, 31),
+
+	TC9564_RESET_INIT1(MAC1_MAC, 7),
+	TC9564_RESET_INIT1(MAC1_PMA, 30),
+	TC9564_RESET_INIT1(MAC1_XPCS, 31),
+};
+#define TC9564_RESET_COUNT	ARRAY_SIZE(tc9564_reset)
+
+static const struct tc9564_resets *
+rcdev_to_tc9564_resets(struct reset_controller_dev *rcdev)
+{
+	return container_of_const(rcdev, struct tc9564_resets, rcdev);
+}
+
+static int tc9564_reset_manage(struct reset_controller_dev *rcdev,
+			       unsigned long id, bool assert)
+{
+	const struct tc9564_resets *resets = rcdev_to_tc9564_resets(rcdev);
+
+	if (id < rcdev->nr_resets) {
+		const struct tc9564_reset *reset = &tc9564_reset[id];
+		u32 mask = reset->mask;
+
+		if (mask)
+			return regmap_update_bits(resets->regmap,
+						  reset->offset, mask,
+						  assert ? mask : 0);
+	}
+
+	dev_err(rcdev->dev, "invalid reset (%s id %lu)\n",
+		assert ? "assert" : "deassert", id);
+
+	return -ENXIO;
+}
+
+static int tc9564_reset_assert(struct reset_controller_dev *rcdev,
+			       unsigned long id)
+{
+	return tc9564_reset_manage(rcdev, id, true);
+}
+
+static int tc9564_reset_deassert(struct reset_controller_dev *rcdev,
+				 unsigned long id)
+{
+	return tc9564_reset_manage(rcdev, id, false);
+}
+
+static const struct reset_control_ops tc9564_reset_control_ops = {
+	.assert = tc9564_reset_assert,
+	.deassert = tc9564_reset_deassert,
+};
+
+static void tc9564_reset_assert_all(struct tc9564_resets *resets)
+{
+	for (u32 id = 0; id < TC9564_RESET_COUNT; id++)
+		if (tc9564_reset[id].mask)
+			tc9564_reset_manage(&resets->rcdev, id, true);
+}
+
+static struct tc9564_resets *tc9564_reset_init(struct device *dev)
+{
+	struct reset_controller_dev *rcdev;
+	struct tc9564_resets *resets;
+	struct regmap *regmap;
+	int ret;
+
+	regmap = syscon_node_to_regmap(dev_of_node(dev->parent));
+	if (IS_ERR(regmap)) {
+		dev_err(dev, "failed to get config regmap\n");
+		return ERR_CAST(regmap);
+	}
+
+	resets = devm_kzalloc(dev, sizeof(*resets), GFP_KERNEL);
+	if (!resets)
+		return ERR_PTR(-ENOMEM);
+	resets->regmap = regmap;
+
+	rcdev = &resets->rcdev;
+	rcdev->ops = &tc9564_reset_control_ops;
+	rcdev->owner = THIS_MODULE;
+	rcdev->dev = dev;
+	rcdev->of_node = dev_of_node(dev);
+	rcdev->nr_resets = TC9564_RESET_COUNT;
+
+	ret = devm_reset_controller_register(dev, rcdev);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return resets;
+}
+
+static int tc9564_reset_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct tc9564_resets *resets;
+
+	if (!dev_of_node(dev))
+		return dev_err_probe(dev, -EINVAL, "no devicetree node\n");
+
+	resets = tc9564_reset_init(dev);
+	if (IS_ERR(resets))
+		return dev_err_probe(dev, PTR_ERR(resets),
+				     "failed to initialize resets\n");
+
+	/* Force all resets to be initially asserted */
+	tc9564_reset_assert_all(resets);
+
+	platform_set_drvdata(pdev, resets);
+
+	return 0;
+}
+
+static void tc9564_reset_remove(struct platform_device *pdev)
+{
+	struct tc9564_resets *resets = platform_get_drvdata(pdev);
+
+	/* Leave all resets asserted when done */
+	tc9564_reset_assert_all(resets);
+}
+
+static const struct of_device_id tc9564_reset_ids[] = {
+	{ .compatible = "toshiba,tc9564-reset" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, tc9564_reset_ids);
+
+static struct platform_driver tc9564_reset_driver = {
+	.probe = tc9564_reset_probe,
+	.remove = tc9564_reset_remove,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = tc9564_reset_ids,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
+	},
+};
+module_platform_driver(tc9564_reset_driver);
+
+MODULE_DESCRIPTION("Toshiba TC9564 Reset Driver");
+MODULE_LICENSE("GPL");
-- 
2.53.0

Re: [PATCH 2/2] reset: toshiba: introduce a TC9564 SoC reset driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] reset: tc9564: hardware state initialized after reset controller registration
- [High] reset: tc9564: active consumers forcibly reset during driver removal
--

commit 504236856b96e78b9064b4d58c3ef7ba166341e3
Author: Alex Elder <elder@riscstar.com>

reset: toshiba: introduce a TC9564 SoC reset driver

Defines a new platform driver that manages reset signals implemented by the
Toshiba TC9564 SoC. The state of the resets is controlled via MMIO to a
region managed by a system controller.

> diff --git a/drivers/reset/reset-tc9564.c b/drivers/reset/reset-tc9564.c
> new file mode 100644
> index 0000000000000..0243c2e0efd54
> --- /dev/null
> +++ b/drivers/reset/reset-tc9564.c

[ ... ]

> +static int tc9564_reset_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct tc9564_resets *resets;
> +
> +	if (!dev_of_node(dev))
> +		return dev_err_probe(dev, -EINVAL, "no devicetree node\n");
> +
> +	resets = tc9564_reset_init(dev);
> +	if (IS_ERR(resets))
> +		return dev_err_probe(dev, PTR_ERR(resets),
> +				     "failed to initialize resets\n");
> +
> +	/* Force all resets to be initially asserted */
> +	tc9564_reset_assert_all(resets);

[Severity: High]
Does this cause a race condition with consumer drivers?

tc9564_reset_init() globally registers the reset controller via
devm_reset_controller_register(). Once registered, consumers can
immediately probe and deassert their reset lines.

If a consumer driver deasserts its reset right after registration,
will this subsequent call to tc9564_reset_assert_all() overwrite the
consumer's hardware state and unexpectedly yank running hardware back
into reset?

> +
> +	platform_set_drvdata(pdev, resets);
> +
> +	return 0;
> +}
> +
> +static void tc9564_reset_remove(struct platform_device *pdev)
> +{
> +	struct tc9564_resets *resets = platform_get_drvdata(pdev);
> +
> +	/* Leave all resets asserted when done */
> +	tc9564_reset_assert_all(resets);

[Severity: High]
Does this unexpectedly assert resets for active consumers?

Since the reset controller is registered using devm_reset_controller_register(),
the devres subsystem will unregister the controller only after this remove
callback completes.

This means the controller is still active and consumers might be actively
using their deasserted reset lines when tc9564_reset_assert_all() is called
here. Should the driver coordinate with consumers or unregister itself first
before forcing all lines into reset?

[ ... ]

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

Re: [PATCH 2/2] reset: toshiba: introduce a TC9564 SoC reset driver

[Alex Elder]

On 10/12/26 11:54 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] reset: tc9564: hardware state initialized after reset controller registration
> - [High] reset: tc9564: active consumers forcibly reset during driver removal
> --
> 
> commit 504236856b96e78b9064b4d58c3ef7ba166341e3
> Author: Alex Elder <elder@riscstar.com>
> 
> reset: toshiba: introduce a TC9564 SoC reset driver
> 
> Defines a new platform driver that manages reset signals implemented by the
> Toshiba TC9564 SoC. The state of the resets is controlled via MMIO to a
> region managed by a system controller.
> 
>> diff --git a/drivers/reset/reset-tc9564.c b/drivers/reset/reset-tc9564.c
>> new file mode 100644
>> index 0000000000000..0243c2e0efd54
>> --- /dev/null
>> +++ b/drivers/reset/reset-tc9564.c
> 
> [ ... ]
> 
>> +static int tc9564_reset_probe(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct tc9564_resets *resets;
>> +
>> +	if (!dev_of_node(dev))
>> +		return dev_err_probe(dev, -EINVAL, "no devicetree node\n");
>> +
>> +	resets = tc9564_reset_init(dev);
>> +	if (IS_ERR(resets))
>> +		return dev_err_probe(dev, PTR_ERR(resets),
>> +				     "failed to initialize resets\n");
>> +
>> +	/* Force all resets to be initially asserted */
>> +	tc9564_reset_assert_all(resets);
> 
> [Severity: High]
> Does this cause a race condition with consumer drivers?

I hadn't thought of that, but yes, this is a good point.
We would like to ensure this is the initial state, but I will
rework this so that all defined resets will be asserted
initially by "directly" writing registers through the regmap,
rather than doing so using the reset API.

> 
> tc9564_reset_init() globally registers the reset controller via
> devm_reset_controller_register(). Once registered, consumers can
> immediately probe and deassert their reset lines.
> 
> If a consumer driver deasserts its reset right after registration,
> will this subsequent call to tc9564_reset_assert_all() overwrite the
> consumer's hardware state and unexpectedly yank running hardware back
> into reset?
> 
>> +
>> +	platform_set_drvdata(pdev, resets);
>> +
>> +	return 0;
>> +}
>> +
>> +static void tc9564_reset_remove(struct platform_device *pdev)
>> +{
>> +	struct tc9564_resets *resets = platform_get_drvdata(pdev);
>> +
>> +	/* Leave all resets asserted when done */
>> +	tc9564_reset_assert_all(resets);
> 
> [Severity: High]
> Does this unexpectedly assert resets for active consumers?

I suppose that's possible, and it's easy enough to simply
omit this remove callback (and the assert-all call).

I will adjust this for version 2.

					-Alex

> 
> Since the reset controller is registered using devm_reset_controller_register(),
> the devres subsystem will unregister the controller only after this remove
> callback completes.
> 
> This means the controller is still active and consumers might be actively
> using their deasserted reset lines when tc9564_reset_assert_all() is called
> here. Should the driver coordinate with consumers or unregister itself first
> before forcing all lines into reset?
> 
> [ ... ]
>