Re: [PATCH net-next v2 1/3] dt-bindings: sram: qcom,imem: Allow modem-tables

[Krzysztof Kozlowski]

On 30/07/2025 14:07, Konrad Dybcio wrote:
>>>>>>
>>>>>> 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).


Then this might be not a syscon, IMO. I don't think mixing syscon and
SRAM is appropriate, even though Linux could treat it very similar.

syscon is for registers. mmio-sram is for SRAM or other parts of
non-volatile RAM.

Indeed you might need to move towards mmio-sram.

> 
>>
>> 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

Then it is not a simple-mfd...

Best regards,
Krzysztof