On 7/15/25 8:37 AM, Krzysztof Kozlowski wrote:

On 14/07/2025 19:53, Konrad Dybcio wrote:

quoted

On 5/27/25 1:42 PM, Krzysztof Kozlowski wrote:

quoted

On 27/05/2025 13:36, Konrad Dybcio wrote:

quoted

quoted

quoted

diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index 2711f90d9664b70fcd1e2f7e2dfd3386ed5c1952..7c882819222dc04190db357ac6f9a3a35137cc9e 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml

@@ -51,6 +51,9 @@ properties:
     $ref: /schemas/power/reset/syscon-reboot-mode.yaml#
 
 patternProperties:
+  "^modem-tables@[0-9a-f]+$":
+    description: Region reserved for the IP Accelerator

Missing additionalProperties: false, which would point you that this is
incomplete (or useless because empty).

How do I describe a 'stupid' node that is just a reg?

With "reg" - similarly to many syscon bindings.

Is this sort of inline style acceptable, or should I introduce
a separate file?

It's fine, assuming that it is desired in general. We do not describe
individual memory regions of syscon nodes and this is a syscon.

If this is NVMEM (which it looks like), then could use NVMEM bindings to
describe its cells - individual regions. But otherwise we just don't.

It's volatile on-chip memory

There are many exceptions in other platforms, mostly old or even
unreviewed by DT maintainers, so they are not a recommended example.

This would need serious justification WHY you need to describe the
child. Why phandle to the main node is not enough for consumers.

It's simply a region of the SRAM, which needs to be IOMMU-mapped in a
specific manner (should IMEM move away from syscon+simple-mfd to
mmio-sram?). Describing slices is the DT way to pass them (like under
NVMEM providers).

If the reason is - to instantiate child device driver - then as well no.
This has been NAKed on the lists many times - you need resources if the
child should be a separate node. Address space is one resource but not
enough, because it can easily be obtained from the parent/main node.

There is no additional driver for this

Konrad