Mew, first #rtw8723cs push in a while, just small changes requested in review.
There’s one larger change I still need to make before sending a v2 patch set: Parse PHY status for received packages using a struct instead of getting bits using macros (basically treating the raw u8*
as a struct rtw8703b_phy_status*
or similar). Other rtw88 chip drivers use the macro style but the maintainer wants to get rid of it, so the request not to add more code in that style is fair.
And then I need to figure out the right order for Signed-off-by, Tested-by, and Acked-by entries people have offered.
@pavel Right, I misremembered what a maintainer had written there. What confused me was that the docs describe the order for s-o-b in detail, but not for the other tags, and looking at examples in the logs the order seems to be all over the place.
@krzk @pavel That might need some work then, I didn’t see any mention of b4
in https://www.kernel.org/doc/html/latest/process/submitting-patches.html, or in https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches. Automatically filling CC would definitely be helpful, I used scripts/get_maintainer.pl
and manually made a list from there.
Mew, responded to review comments I got so far. Two minor changes, one explanation why I’d rather keep it that way (I don’t like if headers must be #include
d in particular order, and Clangd doesn’t either), and one question about related chips. So… Nothing major so far! #rtw8723cs
I’ve rebased my rtw88_8723cs
and rtw88_8723cs-optimize
branches on megi’s 6.8-rc6 variant, plus equally rebased @postmarketOS patches (it looks like they’ll be able to drop a few with 6.8). There was no need to change the #rtw8723cs patches otherwise. https://github.com/airtower-luna/linux/commits/rtw88_8723cs/
The biggest remaining issue is that the chip/firmware sticks to pretty low RX data rates with #rtw8723cs. I don’t know why yet, what I know is that the firmware handles rate negotiation, but also uses some information from the driver to do that (e.g. the driver sends EVM average to the firmware via H2C messages). My current guess is that something RTL8703B needs doesn’t match what the generic rtw88 infrastructure does, but that’ll need more research.
Sent out v3 of the initial #rtw8723cs patch set. The changes from v2 are minor and exactly as requested in review, so I hope it's good to merge now. https://lore.kernel.org/linux-wireless/20240309115650.367204-1-fiona.klute@gmx.de/T/
And now there’s #rtw8723cs v4 with one minor (reasonable) change, and I rebased my Git branches on megi’s v6.8 tree. When it gets merged rebasing any further work will get so much easier…
For anyone using the rtw88_8723cs-optimize
branch, note that it now also includes a few patches for the old 8723cs driver. One of them is required to build it with LLVM, the others just get rid of some warnings.
#rtw8723cs is now on wireless-next, merged just a few minutes ago! Yaaaay! 🎉 https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/log/
@airtower Congratulations! That's a huge step forward for mainline on the PinePhone. I'm really excited for linux 6.10!