Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: IgorMitsyanko <hidden>
Date: 2016-11-29 09:11:00
Possibly related (same subject, not in this thread)
- 2016-11-09 · Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device · Johannes Berg <johannes@sipsolutions.net>
On 11/29/2016 06:49 AM, Oleksij Rempel wrote:
Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:quoted
On 11/28/2016 08:33 PM, Oleksij Rempel wrote:quoted
Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:quoted
Am 28.11.2016 um 17:34 schrieb Kyle McMartin:quoted
On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko [off-list ref] wrote:quoted
Hi Ben, Kyle, could you please share what is the position of linux-firmware regarding firmware binaries that include GPL components? Does it require entire GPL components codebase be present in linux-firmware tree, or maybe having this clause in license file is enough: +Open Source Software. The Software may include components that are licensed +pursuant to open source software (“Open Source Components”). Information +regarding the Open Source Components included with the Software is available +upon request to oslegal@quantenna.com. To the extent such Open Source +Components are required to be licensed to you under the terms of a separate +license (such as an open source license) then such other terms shall apply, and +nothing herein shall be deemed or interpreted to limit any rights you may have +under any such applicable license. From technical perspective, size of the codebase used to build Quantenna firmware is a few hundred MBs, it seems too much to include into linux-firmware tree.I don't have strong feelings one way or another. I'd prefer not having several hundred MB of source that's unlikely to change included in the linux-firmware git tree. I'm also not a lawyer, so I can't help you decide what would satisfy the distribution clause of the GPLv2. We already have one GPL firmware (carl9170fw) which includes the source, but just references a seperate toolchain for downloading, so it's only approximately 1MB in size in the tree. Is your firmware source really that large, or is it just including the entire build toolchain with it? regards, --KyleWe also have open BSD licensed open-ath9k-htc-firmware. Which is locate out of source too. https://github.com/qca/open-ath9k-htc-firmware and here is location of carl firmware: https://github.com/chunkeey/carl9170fw So, what is actual problem with Quantenna QSR10G FW? I would be really interesting to take a look on it. Is it somewhere available? Are there some devices to get hand on?After seeing specs of this device i have strong feeling that "some open source part" is actual linux kernel.Oleksij, yes, that's correct, it includes entire Linux environment; the reasoning is that it allows to hide all WiFi-related logic inside device itself, and emulate simple Ethernet device for external system (therefore, freeing external system resources). This approach was working really well for us until recently, but now that company is expanding, we want to have more flexible and standardize interface available for external system to manage wireless connection, and FullMAC driver seems to be the best solution here.you mean, this driver will not use mac80211 framework provided by kernel?
Yes, this driver is FullMAC - converting Quantenna drivers codebase to mac80211 framework will require significant effort from developers and QA, but I think in the future it will have to be done anyway.
quoted
For the availability of FW sources, QSR10G-based products are still under development at this moment (not in the market yet), but many products based on previous generation chipset QSR1000 are available. For example, Asus has a retail design with QSR1000 chipset, and has all GPL sourcecode available on their website (including what Quantenna has provided): http://www.asus.com/Networking/RTAC87U/HelpDesk_Download/ Quantenna provided code is in, for example, "GPL of ASUS RT-AC87U for firmware 3.0.0.4.378.7410" archive. It's basically the same as used for QSR10G.Will Quantenna provide documentation for at least old chipsats? Playing fair with OSS developer community has some advantages :)
Will forward the request. I agree with this, though this is more about protecting from other wifi vendors on a highly competitive market rather than hiding something from community) QSR1000 chipset that I mentioned is actually "current" chipset while QSR10G can be considered future chipset.