RE: [PATCH rtw-next v2 0/4] wifi: rtl8xxxu: keep RX requests available across transient errors

Ping-Ke Shih posted 4 patches 4 days, 17 hours ago
Only 0 patches received!
RE: [PATCH rtw-next v2 0/4] wifi: rtl8xxxu: keep RX requests available across transient errors
Posted by Ping-Ke Shih 4 days, 17 hours ago
Kim Wooseok <5mghybrid@khu.ac.kr> wrote:
> Hi Ping-Ke,
> 
> Here are the test conditions and results to help with the v3 review. I
> have listed the 13 tests reported previously first, followed by the v3
> results.
> 
> The tests used an RTL8192EU USB adapter on a Raspberry Pi. I adapted the
> RX changes to the Pi's existing Linux 6.18.46 RT kernel so they could be
> tested on the device.
> 
> For the recovery tests below, I checked that all 32 URBs were retained,
> reception resumed without restarting the interface, and stop freed the
> URBs. The RX completion counts are from after the injected errors ended.
> 
> 1. clean-fixed-regression

Are these test items generated by LLM? and how did you make plan to test
these?  (Just curious.)

> 
> V3 passed 52 tests: 42 from the main test plan, one matched-input
> comparison, and nine first-start failure tests after a fresh module
> load. Two interrupt-URB tests were not run because the RTL8192EU does
> not use that path.

The new 52 or 42 tests I have lack information for them, but I don't
actually need them. I think you want to say "this patchset is fully
tested", right?

Ping-Ke

Re: [PATCH rtw-next v2 0/4] wifi: rtl8xxxu: keep RX requests available across transient errors
Posted by Kim Wooseok 4 days, 12 hours ago
Hi Ping-Ke,

> Are these test items generated by LLM? and how did you make plan to test
> these?  (Just curious.)

Yes, an LLM helped put the test results together.

I based the plan on the failure points in the paths affected by the
changes: the start() error paths covered in my reply to patch 2/3,
completion errors, further submission failures during recovery, and
stop while RX work was pending or running.

The tests were designed to inject failures at those points and exercise
the actual driver paths on the RTL8192EU. For each path, the checks
followed what had already been allocated or submitted, whether it was
released or retained for retry, and whether RX recovered or stop left
any work or requests outstanding. Resource counts and work activity
were recorded to check those outcomes.

> I think you want to say "this patchset is fully tested", right?

Yes, that was what I intended to convey. I consider the series
thoroughly tested.

Thanks,
Kim Wooseok