Companies tend to do a good job with new drivers but slack hard when it comes to supporting older legacy drivers as there is a monetary lack of incentive to continue dedicating resources towards legacy drivers. Companies are used to dealing with drivers this way as drivers tend to just be obsoleted and dropped for support. With Linux we need companies to think differently and take advantage of the fact that we have skilled folks willing to help upkeep a driver.
To help with this companies need to start considering evaluation their own chipset / firmware documentation and release more documentation to the community. As a chipset becomes old, it should be easier to release more documentation about the chipset. Some community members are even willing to accept receiving documentation under NDA and the Linux foundation has partnerships set up for this if companies need intermediaries. Companies simply do not have processes today to review and categorize documentation. If companies want to take advantage of the development model on Linux they should invest resources to review and categorize documentation so that after a specific period of time some documentation becomes public, some can be given under NDA, and developers can contact a company for this documentation, and all this is kept track of.
In the ideal situation a company would release both documentation and even source code to firmware for legacy chipsets. Open firmware can help the community fix bugs a company may never have had resources to address and in some cases even enhance legacy drivers further. This is possible today and a perfect example of a success story for this is the carl9170 driver, which has its own open GPLv2 carl9170.fw firmware.
If you are not working on wireless-testing.git you are likely going to run into many development issues. If your driver is no upstream on the wireless-testing.git, you are likely in the worst possible situation for company.
To better understand how things work refer to our development process documentation.
We are currently dropping broadcast / multicast frames when doing a bgscan and going to power save. We need to ensure we wait for all broadcast / multicast data is received before going to power save. ath9k already has code for this, this should just be moved to mac80211. This has been added to the power save TODO section.
We also need the same enhancements when doing roaming, we should follow the DTIM count, not just assume we are always on the DTIM count. In the worst case scenario of a DTIM of 1 we will loose frames though, specially if we have to scan on a passive scan channel, it means we may wait on the passive scan channel longer than 1 beacon internal so we have no option but to loose broadcast / multicast frames. We can enhance this by simply avoiding bgscan unless required. For this we'll need a force scan command, so that we know if we are willing to afford loosing frames when doing a bgscan. This command can also be used to also notify userspace when we hit a deadzone: when we can RX data from an AP but cannot TX to it. This is caused by the AP typically being able to transmit at a higher power than STAs. We can notify userspace we hit a deadzone when the beacon monitor is OK but the connection monitor in mac80211 is not OK. Userspace can then decide it wants to force us to roam off to another BSS on the ESS and use this new force scan command.
Other enhancements can be taken into consideration for offchannel operation like BA tweaks.
All these enhancements have now been documented on the wireless TODO list.