The differentiation is more in microcode running on the radio chip than in anything that runs on the CPU. The microcode is what chip vendors are really paranoid about; I work on wireless AP firmware, and while we have the source code for all our wireless chips, vendors are very firm about never letting us see the source for microcode. If we need to debug a microcode issue, we file a case with them, and in emergencies they'll send an engineer on-site. We get binary blobs, the driver loads binary blobs, the driver sends config options for the advertised checklist of features to these binary blobs, and that's all we know.
The protectiveness of the driver seems more lawyer-driven. They're willing to hand out the source to pretty much everyone who asks to build a device, just under proprietary licenses.
Even when stuff does get open-sourced, the code takes quite a bit of work to pass muster for e.g. the Linux kernel. It's just so low-quality, regardless of vendor, that a lot of time and effort on the device-maker's end goes into debugging driver issues - work that is of course duplicated in a dozen or more companies. I've never personally looked at Marvell drivers, but OpenWRT's claim that it doesn't meet their standards is completely unsurprising to me.
The protectiveness of the driver seems more lawyer-driven. They're willing to hand out the source to pretty much everyone who asks to build a device, just under proprietary licenses.
Even when stuff does get open-sourced, the code takes quite a bit of work to pass muster for e.g. the Linux kernel. It's just so low-quality, regardless of vendor, that a lot of time and effort on the device-maker's end goes into debugging driver issues - work that is of course duplicated in a dozen or more companies. I've never personally looked at Marvell drivers, but OpenWRT's claim that it doesn't meet their standards is completely unsurprising to me.