Hi Ben,
I took a little extra time to look at my series I pointed out during the call
This one might be interesting for your use case, depending on the relationship between the devices. https://github.com/arnopo/linux/commit/be55672841631d539a723f141422f06b3dca1...
ST Restricted
-----Original Message----- From: ben levinsky via Openamp-rp openamp-rp@lists.openampproject.org Sent: mercredi 2 novembre 2022 19:00 To: openamp-rp@lists.openampproject.org Subject: [Openamp-rp] Items for OpenAMP RP call
Hi All,
I have 2 items for discussion for the community call tomorrow:
For the Remoteproc-core API rproc_get_by_child
I have a use case where I would like to call this on the current rproc->device.
2 things:
- At
https://github.com/torvalds/linux/blob/master/drivers/remoteproc/remot epro c_core.c#L2644 There may be a bug here in that if the device is copied, then device->type comparison will fail.
Can we change this to “if (!strncmp(dev->type->name, (&rproc_type)->name, strlen((&rproc_type)->name)) ? That way even if the device is copied the check will work.
- For the same API, is it Ok to extend the for loop so it supports
search on the ‘current’ device passed in?
That is change https://github.com/torvalds/linux/blob/master/drivers/remoteproc/remot epro c_core.c#L2643
“for (dev = dev->parent; dev; dev = dev->parent) {“
to
“for (; dev; dev = dev->parent) {“
This way we can account for the current device having the rproc dev.
The reasoning for why this arises is that I have a use case where a driver is trying to call rproc_boot() to establish an RPMsg connection.
(1) comes up because a device structure is copied so the comparison will not work as currently constructed.
(2) comes up in our use case because the rproc structure device in an internal driver doesn’t yet have a child to iterate up from. (2) is solved in our use case by starting at the current device.
Thanks,
Ben