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
