Re: [PATCH] ath9k: Add RX inactivity detection and reset chip when it occurs

[Simon Wunderlich <sw@simonwunderlich.de>]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

On Wednesday, November 6, 2024 3:12:59 PM CET Toke Høiland-Jørgensen wrote:
> Sven Eckelmann <se@simonwunderlich.de> writes:
> > Hi,
> > 
> > Thank you for submitting the patch.
> > 
> > On Wednesday, 6 November 2024 13:41:44 CET Toke Høiland-Jørgensen wrote:
> >> Since this is based on ideas by all three people, but not actually
> >> directly derived from any of the patches, I'm including Suggested-by
> >> tags from Simon, Sven and Felix below, which should hopefully serve as
> >> proper credit.
> > 
> > At least for me, this is more than enough. Thanks.
> > 
> > I don't have the setup at the moment to test it again - maybe Issam can do
> > this. One concern I would have (because I don't find the notes regarding
> > this problem), is whether this check is now breaking because we count
> > more things. In the past, rxlp/rxok was used for the check. And now I
> > don't know whether the count for the other ones were still increasing.
> > 
> > * RXHP (rather sure that "high priority frame" wasn't increasing)
> > * RXEOL ("no RX descriptors available" - I would guess no, but I can't say
> > for> 
> >   sure)
> > 
> > * RXORN ("FIFO overrun" I would guess no, but I can't say for sure)
> > 
> > Reviewed-by: Sven Eckelmann <se@simonwunderlich.de>
> 
> Great, thanks for the review! I'll let it sit in patchwork for a little
> while to give people a chance to test it out before sending it over to
> Kalle to be applied :)
> 
> -Toke

Hi Toke,

this looks good to me in general. I'm not sure either about the particular RX 
interrupts. We can test this by putting the AP in a shield box and verify that 
the counters are actually increasing, and that should be good enough.

Acked-by: Simon Wunderlich <sw@simonwunderlich.de>

Thank you!
      Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]