On 11/6/24 17:03, Simon Wunderlich wrote:
On Wednesday, November 6, 2024 3:12:59 PM CET Toke Høiland-Jørgensen wrote:
Sven Eckelmann <se@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxx>
Thank you!
Simon
Hi Toke,
I have tested this patch in mesh mode, and it functions as expected.
I conducted the test by placing one node inside a shield box and the
other outside, then verified whether a reset occurred due to RX path
inactivity.
Tested-by: Issam Hamdi <ih@xxxxxxxxxxxxxxxxxx>
Regards,
Issam
-
