Does anyone have a good introduction to how a #Linux #wireless driver is structured? The best I could find so far is https://www.kernel.org/doc/html/latest/driver-api/80211/index.html which is more reference than introduction. Or maybe there's a thoroughly commented mainline driver that could be an example? 
I'm trying to get an idea of what I'd need to do to replace the staging-in-megi's-tree-only rtl8723cs driver used for the #Pinephone. #LinuxMobile
What timing! Just saw today's Freefall http://freefall.purrsia.com/ff4100/fc04009.png and now I'm thinking maybe I should instead write "It's absolutely impossible to write a mainline driver for rtl8723cs!!!!" and hope someone does just to prove me wrong? 
After a closer look at #rtl8723cs I can say I'm not surprised there's still no upstream driver. That code is a horrible mess, and the options are a) fully untangle and clean up the mess for upstreaming or b) untangle enough to understand what you need to know to write a new, clean driver. Or maybe extend one of the existing mainline drivers? There seem to be some similarities with the rtw88 SDIO parts at least. I think I'll keep trying (leaning towards option b), but help would be very, very welcome. 
#MobileLinux #PinePhone
What I have so far:
Scaffolding for a driver based on rtw88. Rtw88 already supports a similar SDIO 802.11n chip, so it takes care of the SDIO communication, but I'll have to implement the chip operations and figure out initialization commands and values and similar. Right now it'd crash if you tried to run it because required chip operation function pointers are NULL, but it compiles.
A little tool that creates proper firmware files from the firmware arrays included in #rtl8723cs.
What's interesting is that the old driver calls the wifi chip RTL8703B, as part of the combined wifi/bluetooth RTL8723CS module. I'll probably share code when I have it so far that it doesn't crash and logs something about detecting the chip. 
8703B seems to have a happy amount of overlap with 8723D, which is already supported by rtw88. Not enough to just use that one, but being able to avoid reinventing things like the EFUSE data parsing is nice.
I said I'd share code when I have something that doesn't crash, and I do now: https://github.com/airtower-luna/linux/commit/5926d4aa22e6db72a3f7941e297a4b796f5746fb The "rfe 0 isn't supported" error is because data tables with transmit power and regulatory information are missing, so that'll have to be the next thing. Help with that or other parts welcome! 
For the required firmware, see here: https://github.com/airtower-luna/rtw8703b-fw-extractor
#rtw8783cs #Pinephone #MobileLinux
One thing that really worries me is if the firmware can be accepted into linux-firmware this way ("extracted from array in vendor driver files marked as GPL-2"), and if the driver could be accepted upstream (later, when it supports at least station mode) if not. Reading the README of the linux-firmware repository gives me doubts at least.
Does anyone know how that works? Or even better, has a contact at #Realtek who could see about getting the firmware released directly? Or at least at #Pine64 or some other Realtek customer who could poke them?
@airtower It likely needs to be Reversed in a Clean Room approach. I can look into it but I'm not the best with documentation and I have a bit more to do before my system is in a more usable state.
I'd be happy to help with this noble effort to further free something that I'm very proud of. Unfortunately it's a Realtek chip and I would doubt that Pine64 could get them to release more than they have.
I'll see what I can dig up but it will take time.
