Re: [PATCH v2 1/3] dt-bindings: soc: ti: Document the ti,tda54-mcu-scm-conf binding

[Krzysztof Kozlowski]

On Tue, Oct 27, 2026 at 02:06:58PM +0530, Moteen Shah wrote:
> TDA54's MCU domain exposes a shared scm_conf syscon region that other
> peripherals, including chipid, access into rather than owning a
> dedicated register window. Rather than a bare fallback entry in the
> generic syscon compatible list, give it a dedicated binding
> describing the region and the proxy/claim/lock arbitration scheme
> that gates write access to a subset of its registers.
> 

A nit, subject: drop second/last, redundant "binding". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23

> Some of the claimable registers are gate clock controls, so also
> document the required "#clock-cells" property that lets the node be
> referenced directly as a clock provider for those gates. The clock
> specifier selects the ePWM time-base gate by instance number.
> 
> Co-developed-by: Aniket Limaye <a-limaye@xxxxxx>
> Signed-off-by: Aniket Limaye <a-limaye@xxxxxx>
> Signed-off-by: Moteen Shah <m-shah@xxxxxx>
> ---
>  .../soc/ti/ti,tda54-mcu-scm-conf.yaml         | 78 +++++++++++++++++++
>  1 file changed, 78 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml b/Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml
> new file mode 100644
> index 0000000000000..111cbb739b5f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml
> @@ -0,0 +1,78 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/ti/ti,tda54-mcu-scm-conf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments TDA54 SoC MCU Domain System Control Module Configuration registers
> +
> +maintainers:
> +  - Aniket Limaye <a-limaye@xxxxxx>
> +  - Moteen Shah <m-shah@xxxxxx>
> +
> +description: |
> +  The TDA54 SoC's MCU domain exposes a System Control Module configuration
> +  register region (scm_conf) containing miscellaneous control and status
> +  registers for MCU domain peripherals, including the JTAGID/device
> +  identification registers, boot configuration and status registers, and
> +  device feature registers.
> +
> +  A subset of these registers is write-protected by a proxy/claim scheme:
> +  each register is mirrored across 8 proxy regions, and a host must unlock
> +  via LOCK_KICK. Any proxy other than proxy-0 must also claim a register
> +  through its CLAIM register before writing through that proxy. Proxy-0 is
> +  the default access proxy: its claim bits are tied low, so it needs no
> +  claim and can write any register that is not claimed by another proxy.
> +  For example: Proxy0's CLAIM0 register sits at offset 0x3100, while the
> +  same register mirrored at ProxyN sits at N * 0x4000 + 0x3100.
> +
> +  Each of the 8 proxy regions also has its own fault status and
> +  interrupt registers, but a fault can only be handled through proxy-0.
> +  Hence, interrupt/fault handling is not described by this binding.
> +
> +  Some of the claimable registers are gate clock controls (e.g. the
> +  ehrpwm_tbclk gates). This node is the clock provider for those gates;
> +  writes to them are still routed through the proxy claim scheme described
> +  above.
> +
> +properties:
> +  compatible:
> +    const: ti,tda54-mcu-scm-conf
> +
> +  reg:
> +    maxItems: 1
> +
> +  ti,proxy-id:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 7
> +    description:
> +      Proxy region (0-7) through which this node's clients access
> +      claimable registers and their fault status registers.

I don't get the need of this property. You have a one, specific device, so
why the proxy id would vary per board?

It also looks like re-implementing access controllers.

Best regards,
Krzysztof