Date: Mon, 13 Jul 2020 17:25:26 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: "Bjoern A. Zeeb" <bz@FreeBSD.org> Cc: driesm.michiels@gmail.com, freebsd-wireless@freebsd.org Subject: Re: Current state of recent wireless cards Message-ID: <20200713172526.81bb91a04198792ce8695322@bidouilliste.com> In-Reply-To: <778A3FF0-905B-49ED-ABDE-913C3451AB16@FreeBSD.org> References: <000501d655e3$90c40170$b24c0450$@gmail.com> <CAFC648B-1A32-4FF3-AC98-23A2B93732D5@FreeBSD.org> <20200710233308.b27284cd15dec5849fb5cc32@bidouilliste.com> <778A3FF0-905B-49ED-ABDE-913C3451AB16@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Jul 2020 10:34:51 +0000 "Bjoern A. Zeeb" <bz@FreeBSD.org> wrote: > On 10 Jul 2020, at 21:33, Emmanuel Vadot wrote: >=20 > > That's a bit optimistic that attach and firmware loading is half of > > the work no ? > > I don't know how much linuxkpi layer is needed for 80211 compat but I > > guess it's "a lot" ? >=20 > Part of that ?lot? is that as Adrian also indicates the net80211=20 > parts also > need doing as otherwise you cannot write the compat on top and that=20 > makes > it hard to estimate how much will be compat or native yet. I though that your plan was to have every compat needed in linuxkpi to port/update drivers more easily. Also I'm not really talking about AC here, just doing linuxkpi compat for what's already needed for G is still a lot (and needed for iwlwifi). > Also given along with ath10k this is the ?first? bits to do this in=20 > FreeBSD > it?ll always take longer than doing a 2nd or 3rd driver. >=20 > > IIRC Linux have multiple 80211 framework no ? >=20 > Well kind-of layered: mac80211 / cfg80211 and the user space config > stuff in nl80211 and I?d almost thought intermangled add the entire > regdomain parts. > https://wireless.wiki.kernel.org has at least some overview there. >=20 >=20 > > I guess your work only focus on one (used by iwlwifi), do you know=20 > > how > > many drivers used the same one ? What about FullMAC drivers like the > > SDIO broadcom one used in many ARM SBC, is that using the same > > framework ? >=20 > The Broadcom driver could be a great deal easier to port than it is. > It will be easier to port with this as some parts are already covered > as a result of this and more will be. The SDIO parts for the fmac are > not part of this as the Intel work is PCI-only but those were done last > year already.=20 So you have linuxkpi code for linux mmcstack -> mmccam ? Or are you just talking about mmccam sdio functionality ? > I am currently trying to get my hands-on a PCI card as > well as I hope that might speed up some things. >=20 > On another note, I was able to get the rtw88 driver compile in under a > day based on the iwlwifi. That?s kind-of an ideal case, other=20 > drivers > would need more time (and it?ll highly depend on whether that is other > Linux or other WiFi bits). Compile and working ? Because that's easy to compile code if you add a lot of dummy stub functions. >=20 > I had done a comparison after the initial iwlwifi work based on compile > time errors for a few Dual BSD-GPL or ISC or similarly friendly licensed > drivers: the order was iwlwifi < rtw88 < ath11k < ath10k < brcmfmac in > terms of individual errors and functions missing/to implement. I also > had numbers of how much the iwlwifi work had reduced all this but they > are outdated. >=20 > I also looked at the mt7601u GPL driver (as the hope is that some of=20 > these > could also be ported more quickly and possibly live outside the tree but > at least be avail) and it wasn?t too bad either. A handful of extra=20 > WiFi > constants and 6 or so functions and then the usual Linux noise on top. >=20 >=20 > /bz --=20 Emmanuel Vadot <manu@bidouilliste.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200713172526.81bb91a04198792ce8695322>