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@xxxxxxxxxxxx>
> > Signed-off-by: Daniel Thompson <daniel@xxxxxxxxxxxx>
> > Signed-off-by: Alex Elder <elder@xxxxxxxxxxxx>
> > ---
> >  .../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@xxxxxxxxxxxx>
> > +  - Daniel Thompson <daniel@xxxxxxxxxxxx>
> > +
> > +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