Re: [PATCHv2] usb: typec: qcom-pmic-typec: simplify allocation

From: Rosen Penev

Date: Wed Mar 11 2026 - 20:13:00 EST


On Wed, Mar 11, 2026 at 4:37 PM Bryan O'Donoghue
<bryan.odonoghue@xxxxxxxxxx> wrote:
>
> On 11/03/2026 23:23, Rosen Penev wrote:
> > Change kzalloc + kcalloc to just kzalloc with a flexible array member.
> >
> > Add __counted_by for extra runtime analysis when requested.
> >
> > Move counting assignment immediately after allocation as required by
> > __counted_by.
> >
> > Signed-off-by: Rosen Penev <rosenp@xxxxxxxxx>
>
> Hi Rosen.
>
> Thanks for your patch.
>
> I have the same feedback as Greg gave you previously on this.
>
> Each line-item in your log should really be its own patch i.e. v3 should
> be three patches
>
> [PATCH v3 1/3] Change kzalloc + kcalloc to just kzalloc with a flexible
> array member.
This is probably the only one worth anything. I'm getting requests
elsewhere to add __counted_by though.
>
> [PATCH v3 2/3] Add __counted_by for extra runtime analysis when requested.
>
> [PATCH v3 3/3] Move counting assignment immediately after allocation as
> required by __counted_by.
2 and 3 as you laid out should be the same. 2 without 3 breaks runtime analysis.
>
> Or something pretty close to that.
>
> There are several reasons for that
>
> 1. Bisectability
> The ability to more easily bisect patches.
>
> 2. Logical separation
> If a change deserves its own line-item in a patch
> then that change almost certainly deserves its own patch.
>
> 3. Mixing stuff up in a big patch is confusing
calling

20 insertions(+), 25 deletions(-)

big is wild.
> I look at a commit log and see lots of things going on in one go.
> I as a reviewer or say someone tracking -stable and deciding which
> patches to pull into my tree can't look at a patch a "just know" what
> it is doing.
>
> So v3 should please
>
> - Have a cover letter
> - Contain three patches one for each logical change
Maybe some other time.
>
> Oh and reason 4 is the most important !
>
> Patch count bragging rights !
That's just pointless churn.
>
> ---
> bod