Message-ID: <00f6d696-a8d2-41a5-819a-dc1ed87d35bb@kernel.org>
Date: Sun, 3 Aug 2025 11:20:59 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Alex Elder <elder@...nel.org>
Cc: Marijn Suijten <marijn.suijten@...ainline.org>,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 Alex Elder <elder@...cstar.com>
Subject: Re: [PATCH net-next v2 1/3] dt-bindings: sram: qcom,imem: Allow
 modem-tables

On 31/07/2025 11:47, Konrad Dybcio wrote:
> On 7/30/25 3:14 PM, Krzysztof Kozlowski wrote:
>> 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...
> 
> Indeed it's really not
> 
> I found out however that the computer history museum (i.e.
> qcom-apq8064-asus-nexus7-flo.dts and qcom-msm8974.dtsi) seems to
> have used simple-mfd, so that the subnode (syscon-reboot-mode) is
> matched against a driver
> 
> The same can be achieved if we stick an of_platform_populate() at
> the end of mmio-sram probe - thoughts?
You cannot (or should not) remove simple-mfd from existing binding. But
the point is that the list should not grow.

Maybe the binding should receive a comment next to compatible:
" # Do not grow this, if you add here new compatible, you agree to buy
round of drinks on next LPC to all upstream maintainers" ?

Best regards,
Krzysztof

Powered by blists - more mailing lists