Thread (13 messages) 13 messages, 3 authors, 2025-03-31

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

From: Mihalcea Laurentiu <hidden>
Date: 2025-03-31 11:45:22
Also in: imx, linux-devicetree, lkml

On 31.03.2025 09:41, Marco Felsch wrote:
On 25-03-28, Mihalcea Laurentiu wrote:
quoted
On 25.03.2025 05:23, Rob Herring wrote:
quoted
On Mon, Mar 24, 2025 at 12:25:52PM -0400, Laurentiu Mihalcea wrote:
quoted
From: Laurentiu Mihalcea <redacted>

Add documentation for IMX AIPSTZ bridge.

Co-developed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Laurentiu Mihalcea <redacted>
---
 .../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
quoted
quoted
+maintainers:
+  - Laurentiu Mihalcea [off-list ref]
+
+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.
quoted
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.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help