[PATCH v3 1/5] dt-bindings: bus: add documentation for the IMX AIPSTZ bridge

[Mihalcea Laurentiu]

On 31.03.2025 09:41, Marco Felsch wrote:
> On 25-03-28, Mihalcea Laurentiu wrote:
>> On 25.03.2025 05:23, Rob Herring wrote:
>>> On Mon, Mar 24, 2025 at 12:25:52PM -0400, Laurentiu Mihalcea wrote:
>>>> From: Laurentiu Mihalcea <laurentiu.mihalcea at nxp.com>
>>>>
>>>> Add documentation for IMX AIPSTZ bridge.
>>>>
>>>> Co-developed-by: Daniel Baluta <daniel.baluta at nxp.com>
>>>> Signed-off-by: Daniel Baluta <daniel.baluta at nxp.com>
>>>> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea at nxp.com>
>>>> ---
>>>>  .../bindings/bus/fsl,imx8mp-aipstz.yaml       | 107 ++++++++++++++++++
>>>>  1 file changed, 107 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml b/Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml
>>>> new file mode 100644
>>>> index 000000000000..c0427dfcdaca
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml
>>>> @@ -0,0 +1,107 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/bus/fsl,imx8mp-aipstz.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Secure AHB to IP Slave bus (AIPSTZ) bridge
>>>> +
>>>> +description:
>>>> +  The secure AIPS bridge (AIPSTZ) acts as a bridge for AHB masters
>>>> +  issuing transactions to IP Slave peripherals. Additionally, this module
>>>> +  offers access control configurations meant to restrict which peripherals
>>>> +  a master can access.
>>> Wrap at 80 chars.
>>
>> fix in v4, thx
>>
>>>> +maintainers:
>>>> +  - Laurentiu Mihalcea <laurentiu.mihalcea at nxp.com>
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: fsl,imx8mp-aipstz
>>>> +
>>>> +  reg:
>>>> +    maxItems: 2
>>>> +
>>>> +  reg-names:
>>>> +    items:
>>>> +      - const: bus
>>>> +      - const: ac
>>>> +
>>>> +  power-domains:
>>>> +    maxItems: 1
>>>> +
>>>> +  "#address-cells":
>>>> +    const: 1
>>>> +
>>>> +  "#size-cells":
>>>> +    const: 1
>>>> +
>>>> +  "#access-controller-cells":
>>>> +    const: 0
>>> With 0 cells, how do you identify which device it is?
>> we don't atm. We're relying on the default configuration.
> I think Rob is speaking from DT API pov. What the driver is doing with
> additional information is up to the driver.
>
>> we don't have any APIs for AC configuration so I left the
>> cell number to 0 thinking that the cell number might depend
>> on the API.
>>
>> if need be, I can set it to the value I was initially thinking of in
>> v4.
> Which is?
>
> According the TRM it's a bit tricky to define the API since you need to
> describe two different types:
>  - master configuration
>  - peripheral configuration
>
> One which came up in my mind is:
>
>   <&phandle TYPE ID VALUE>;
>
> e.g.
>
>   <&aipstz AIPSTZ_MASTER 0 0xf>;
>   <&aipstz AIPSTZ_PERI 0 0xf>;
>
> One could use a defien for the magic value of 0xf of course.


so, my original idea was to use 2 cells: <&phandle ID VALUE>, where bit 0 of ID is used

to identify the IP type (master or slave/peripheral) and the rest of the bits are used to encode

the ID itself.


I think I like your idea a bit more though (i.e: have the TYPE as a separate cell)

because I think it's easier to deal with/understand from the DTS user's perspective.