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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e0d328e0-bc54-4763-9c55-694c0fd93746@gmail.com>
Date: Mon, 31 Mar 2025 14:57:46 +0300
From: Mihalcea Laurentiu <laurentiumihalcea111@...il.com>
To: Marco Felsch <m.felsch@...gutronix.de>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
 Sascha Hauer <s.hauer@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
 Daniel Baluta <daniel.baluta@....com>, Shengjiu Wang
 <shengjiu.wang@....com>, Frank Li <Frank.li@....com>,
 Marc Kleine-Budde <mkl@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>, devicetree@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/5] dt-bindings: bus: add documentation for the IMX
 AIPSTZ bridge


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@....com>
>>>>
>>>> Add documentation for IMX AIPSTZ bridge.
>>>>
>>>> Co-developed-by: Daniel Baluta <daniel.baluta@....com>
>>>> Signed-off-by: Daniel Baluta <daniel.baluta@....com>
>>>> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@....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@....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.