Re: [PATCH v2 2/3] misc: fastrpc: Add support for new DSP IOVA formatting

[Krzysztof Kozlowski <krzk@kernel.org>]

On 23/10/2025 10:35, Kumari Pallavi wrote:
> 
> 
> On 10/18/2025 10:54 PM, Krzysztof Kozlowski wrote:
>> On 15/10/2025 06:57, Kumari Pallavi wrote:
>>>   static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
>>>   {
>>>   	struct device *rdev = &rpdev->dev;
>>> @@ -2291,6 +2319,22 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
>>>   	const char *domain;
>>>   	bool secure_dsp;
>>>   	unsigned int vmids[FASTRPC_MAX_VMIDS];
>>> +	struct device_node *root;
>>> +	const struct of_device_id *match;
>>> +	const struct fastrpc_soc_data *soc_data = NULL;
>>> +
>>> +	root = of_find_node_by_path("/");
>>> +	if (!root)
>>> +		return -ENODEV;
>>> +
>>> +	match = of_match_node(qcom_soc_match_table, root);
>>
>> This is really odd way of doing things. You want to check machine, not
>> some node. Use proper API for that.
>>
>> OTOH, I don't understand why you are checking machine in the first
>> place. If your device is different, then please follow writing bindings
>> - it explains exactly this case here.
>>
> 
> On the Kaanapali SoC, enabling ADSP and CDSP functionality requires new 
> DSP IOVA formatting and hardware-specific configuration. Going forward, 
> SoC will support the updated IOVA format.
> To handle this, we referred to the implementation in
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/soc/qcom/qcom_pd_mapper.c, 

Please don't point random files...

> which aligns well with the requirements and serves as a suitable 
> reference for our use case.

Nor use corpo language.

> If there are alternative approaches or suggestions for handling this 
> more effectively, we’re happy to discuss and consider them.

See writing bindings. They cover this case.

Best regards,
Krzysztof