On Tue, Mar 17, 2026 at 03:44:02PM +0800, Peng Fan wrote:
On Tue, Mar 10, 2026 at 06:40:28PM +0000, Cristian Marussi wrote:
quoted
SCMI core stack provides some common helpers to handle in a unified way
multipart message replies: such iterator-helpers, when run, currently
process by default the whole set of discovered resources.
Introduce an alternative way to run the initialized iterator on a limited
range of resources.
Note that the subset of resources that can be chosen is anyway limited by
the SCMI protocol specification, since you are only allowed to choose the
startindex on a multi-part enumeration NOT the end index, so that the
effective number of returned items by a bound iterators depends really
on platform side decisions.
Suggested-by: Etienne Carriere <redacted>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
+static void scmi_iterator_cleanup(void *iter)
+{
+ struct scmi_iterator *i = iter;
I see you use no_free_ptr for allocation,
Do we need to use __free for i or drop the __free usage in allocation?
Neither I think...iter is allocated by iterator_init() which do use
__free cleanups to simplify error paths, BUT if everything goes fine
iter is returned with no_free_ptr() as a normal pointer and all the
compiler-attached cleanup helpers are removed...
Then you can use in an iterator_run() or iterator_run_bound() and in
borth case it HAS to be manually cleanup by calling this scmi_iterator_cleanup
helper where...
Regards
Peng
quoted
+
+ i->ph->xops->xfer_put(i->ph, i->t);
+ kfree(i);
..it is finally freed explicitly...
...or I am getting something else wrong around the cleanup helpers :P ?
Thanks,
Cristian