Re: [PATCH RFC v2] wifi: ath10k: make in-order rx amsdu buffers persistent

On Thu, 2026-07-30 at 19:24 -0700, Jeff Johnson wrote:
> On 7/19/2026 2:45 PM, David Heidelberg via B4 Relay wrote:
> > From: Richard Acayan <[email protected]>
> >=20
> > The WCN3990 might split MSDUs among multiple "in-order" indications. Th=
e
> > driver needs information from previous indications to handle MPDUs that
> > are not started by the same indications that complete them. Move the
> > list that tracks unprocessed MSDUs to the driver state so the driver ca=
n
> > handle MPDUs that are split in this way and be less confused.

> I'm transcribing a few comments from my review agent (which may overlap
> Sashiko). I have not vetted them for correctness. Hopefully I placed them=
 at
> the correct spots!

I think this is one of those cases where just doing LLMs isn't all that
helpful?

I'm not at all familiar with this, but why does this really need all the
complexity of hanging on to the entire MPDU etc. when "[the] driver
needs information"? Couldn't it just hang on to the relevant information
and reduce the complexity here?

Also, the entire point of this is for the loop, so when the LLM says:

> > +	msdu =3D skb_peek(list);
> > +	rxd =3D HTT_RX_BUF_TO_RX_DESC(hw,
> > +				    (void *)msdu->data - hw->rx_desc_ops->rx_desc_size);
>=20
> Dead rxd computation before the loop =E2=80=94 VALID, MINOR

I feel like it's probably missing the point entirely - the in-loop
version should be removed?

johannes