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

[Konrad Dybcio]

On 18-Feb-26 14:21, Krzysztof Kozlowski wrote:
> On 18/02/2026 13:26, Konrad Dybcio wrote:
>>
>>
>> On 18-Feb-26 12:56, Krzysztof Kozlowski wrote:
>>> On 18/02/2026 12:05, Konrad Dybcio wrote:
>>>> On 2/17/26 9:25 PM, Krzysztof Kozlowski wrote:
>>>>> On Tue, Feb 17, 2026 at 02:30:31PM +0100, Konrad Dybcio wrote:
>>>>>> From: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
>>>>>>
>>>>>> The IP Accelerator hardware/firmware owns a sizeable region within the
>>>>>> IMEM, named 'modem-tables', containing various packet processing
>>>>>> configuration data.
>>>>>>
>>>>>> It's not actually accessed by the OS, although we have to IOMMU-map it
>>>>>> with the IPA device, so that presumably the firmware can act upon it.
>>>>>>
>>>>>> Allow it as a subnode of IMEM.
>>>>>
>>>>> You do not have compatible, so rely on the node name as ABI, which is
>>>>> fine in general but... I do not see usage of it in the driver. Why do
>>>>> you need to define modem-tables child then?
>>>>
>>>> I don't really *need* the node name to be an ABI. However, the current
>>>> binding for IMEM only allows a named "pil-reloc@.." subnode (which is
>>>> consumed via of_find_compatible_node() in the remoteproc subsystem) so I
>>>> figured the intention was to keep the list of allowed subnodes strictly
>>>> moderated
>>>>
>>>> If you'd prefer a blanket pattern declaration with say '^[a-z]@[0-9a-z]+$'
>>>> with just a reg requirement inside, I'm fine with that too
>>>
>>> No, the problem is that you do not use the ABI here at all. Neither
>>> would you use the blanket pattern, so my question stays: why adding ABI
>>> which is not used?
>>
>> The subnode I'm trying to introduce is going to be consumed (via a
>> phandle reference) from the IPA node, as done by the remaining 2
>> patches in this series.
> 
> And that's the problem - I do not see consuming child. I see
> of_parse_phandle to sram node, not the child.

Ah, I just realized this series has no DT examples..

The property I proposed to add into the IPA node&code is indeed
named 'sram', but my intention is to pass a phandle to the *child*
(similarly like we pass a phandle to the child of a nvmem provider
rather than to the provider device itself)

i.e. the design I envisioned is:

imem@foo {
	...

	ipa_modem_tables: modem-tables@1234 {
		reg = <0x1234 0x1234>;
	};
};

...

ipa@foobar {
	...

	sram = <&ipa_modem_tables>;
}

Konrad