Re: [PATCH] ath9k: fix another source of corrupt frames

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Tue, May 04, 2010 at 11:36:13AM -0700, John W. Linville wrote:
> On Tue, May 04, 2010 at 11:09:32AM -0700, Luis R. Rodriguez wrote:
> > On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> > > Atheros hardware supports receiving frames that span multiple
> > > descriptors and buffers. In this case, the rx status of every
> > > descriptor except for the last one is invalid and may contain random
> > > data. Because the driver does not support this, it needs to drop such
> > > frames.
> > >
> > > Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> > > ---
> > > --- a/drivers/net/wireless/ath/ath9k/common.c
> > > +++ b/drivers/net/wireless/ath/ath9k/common.c
> > > @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> > >         * rs_more indicates chained descriptors which can be used
> > >         * to link buffers together for a sort of scatter-gather
> > >         * operation.
> > > -        *
> > > +        * reject the frame, we don't support scatter-gather yet and
> > > +        * the frame is probably corrupt anyway
> > > +        */
> > > +       if (rx_stats->rs_more)
> > > +               return false;
> > 
> > Actually this is required by ath9k_htc, it does process these, but
> > ath9k doesn't so this could be done within ath9k itself.
> 
> I'm sorry, that is a bit unclear to me.  Are you NAKing the patch?

Yes, I am NAK'ing it, I should have been clearer about that, sorry.
The reason is that ath9k_htc *depends* on rs_more stuff because the
USB frames it receives *are* split up and to RX them we decouple
them. With this patch you'd break ath9k_htc considerably.

> Or saying that the patch is fine but another patch is needed on top?

My suggestion is that this change can be made but only on the
ath9k RX path, instead of the comon path so a separate patch would
be needed.

  Luis