Re: [PATCH v3] greybus: audio: Split gb_audio_gb_get_topology() into size query and data fetch

[Aditya Chari S]

On Sat, Jul 25, 2026 at 08:39:xx PM, Dan Carpenter wrote:
> These should be in chronological order.
> > ---
> Why are you sending a v3 of this? ...

Thanks for the review, Dan.

I sent v3 mainly to rebase against the latest staging-next as told in
the earlier version

I've now prepared v4 with the tag order corrected (Signed-off-by before
Reviewed-by) as you suggested, and included the full changelog in the
patch.

Regards,
Aditya

On Sat, Jul 25, 2026 at 8:39 PM Dan Carpenter <error27@xxxxxxxxx> wrote:
>
> On Sat, Jul 25, 2026 at 08:07:21PM +0530, Aditya Chari wrote:
> > `gb_audio_gb_get_topology()` combined three separate responsibilities into
> > a single call: querying the topology size, allocating a buffer for it, and
> > fetching the topology data into that buffer. This left callers with no
> > way to perform any of these steps independently, and forced the kzalloc()
> > allocation to live inside the protocol‑layer driver rather than the
> > caller, as already flagged by a FIXME comment at the call site
> > in `audio_module.c`.
> >
> > Split the function into two:
> > - `gb_audio_gb_get_topology_size()` – queries only the topology size
> > - `gb_audio_gb_get_topology()`      – fetches topology data into a
> >                                       caller‑supplied buffer
> >                                     of a given size
> >
> > Update the only caller, `gb_audio_probe()` in `audio_module.c`, to
> > query the size first, allocate the topology buffer itself,
> > then fetch the data into it, freeing the buffer via the existing
> > `free_topology` error path on failure. The topology size is now
> > stored as `size_t` and validated in the caller before allocation,
> > addressing the earlier TODO and FIXME comments.
> >
> > This resolves both the "TODO: Split into separate calls" comment
> > above the original function in `audio_gb.c` and the FIXME comment
> > at the call site in `audio_module.c`, both of which are removed
> > as part of this change.
> >
> > No functional change in behavior for the existing probe path.
> >
> > Reviewed-by: Dan Carpenter <error27@xxxxxxxxx>
> > Signed-off-by: Aditya Chari <adi25charis@xxxxxxxxx>
>
> These should be in chronological order.
>
> > ---
>
> Why are you sending a v3 of this?  Presumably I missed some
> critical stuff when I reviewed it but I can't be bothered to
> search my inbox to find out what...
>
> So partially laziness but also I would hate to miss this
> opportunity for SEO so it's also greed.
> https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
>
> regards,
> dan carpenter
>