Hi,
On 17-01-17 13:44, Bastien Nocera wrote:
On Tue, 2017-01-17 at 13:11 +0100, Hans de Goede wrote:
> Hi All,
>
> There are quite a few popular cheap x86 devices,
> such as the first gen Intel Compute Stick and
> many many ARM boards which have sdio wifi chips.
>
> Unfortunately the mainline kernel lacks drivers
> for almost all sdio wifi chips, so Fedora ends
> up not supporting wifi on these devices, making
> it unattractive to run Fedora on these devices.
>
> I want to fix this and I've been thinking about
> how to fix this. Options are:
>
> a) A copr with kmod-s, this is not a good answer
> for 3 reasons:
> 1) It is a pain to maintain as it needs rebuilds
> each kernel build
> 2) It is not really a solution as copr does not
> build for ARM
> 3) On most of these devices wifi is the only
> network connectivity, so not having support
> on the install media makes it very hard to
> get wifi going to the point that an user will
> likely just give up
>
> b) A copr with dkms modules, this is not a good answer
> for 2 reasons:
> 1) Building kernel modules from source on the users
> system is ugly and more importantly fragile
> 2) On most of these devices wifi is the only
> network connectivity, so not having support
> on the install media makes it very hard to
> get wifi going to the point that an user will
> likely just give up
>
> c) Integrate the driver into the Fedora kernel pkg,
> which means that:
> 1) It will always be rebuild together with the kernel
> 2) It will be available at and directly after installation
>
> d) Get the driver upstreamed. Unfortunately many of
> these drivers are vendor code, which often is ported
> windows code with lots of ugly glue; and the effort to
> get this upstream will take more time then I have
> to invest into this. Also if this were easy it would
> have been done by now, there are quite a few people
> interested in this. With this said I know that work
> is being done on upstreaming esp8089 support and
> the rtl8xxxu maintainer is looking on extending
> that with sdio support solving the problem for
> realtek chip. Note the ETA of any of this is unclear.
>
> As such I've come to the conclusion that from a user
> pov the only really good solution is c.
>
> As such I would like to (for starters) add this driver:
>
https://github.com/hadess/rtl8723bs
>
> Which is fully open source and although not ready for
> upstream, actively maintained by the community, to the
> driver/staging directory of the Fedora kernel pkg.
>
> I realize this goes against the no out-of-tree kernel
> modules in Fedora rule, but I believe it is time we
> bend that rule a bit. IIRC that rule was made to
> disallow so called kmod packages, which as I've listed
> above indeed have a bunch of downsides. However I
> believe that by simply integrating the driver into
> the fedora kernel srpm we can avoid these issues.
>
> I also believe that this rule goes against Fedora's
> basic principles:
>
> -It goes against the First principle, many other distros
> are shipping with this driver
> -It goes against the Features principle, disallowing
> people to have working wifi is a mis-Feature
> -It goes against the Freedom principle, if a contributor
> is willing to spend time to maintain such a driver
> he/she should have the freedom to do so
>
> I realize that this rule was made to protect the Fedora
> kernel maintainers from getting a lot of extra work on
> their plate caused by such drivers. But note that I'm
> not asking the Fedora kernel team to do any work on this,
> I'm volunteering to do both the integration work as well
> as maintaining these drivers going forward. If one a
> rebase to the next -rc1 things break, feel free to simply
> comment out the patch adding the driver(s) I will check
> each rc1 what the state is (test the driver on hardware
> with the specific sdio wifi chip) and fix any build or
> runtime issues, this is something which I'm doing anyways
> for my own kernel builds.
>
> All I'm asking from the fedora kernel team is permission
> to add the driver.
Would it be that much more work to get those drivers in staging?
Getting them in staging requires some commitment to them
becoming mainline ready in due course. AFAICT no one is
working on fixing the remaining blockers for e.g. the
rtl8723bs code and the rtl8xxxu path is likely a better
way forward.
The main problem I see with adding those drivers is that we still
had
to have patches on top of other subsystems to get them working in 4.x
kernels. Would we still need those?
No, the baytrail sdio problems have been fixed. There are
still some other baytrail issues, but those happen without
sdio wifi to so they are likely unrelated.
If the only reason why we cannot land this in staging is because of
indentation rules, I'd rather we made sure those rules are relaxed,
rather than reindenting everything and making it harder to rebase.
As said I believe that to get these in staging we need to
provide upstream with a path forward, which I believe for
this specific case is adding sdio support to the rtl8xxxu
driver. Which means that there is no incentive for upstream
to take the rtl8723bs code into staging, as it will likely
be replaced by something else rather then ever get promoted
to non-staging.
Also there are a bunch of other sdio wifi drivers used on
ARM (mostly more realtek models) which will require significant
work before being ready for staging then the rtl8723bs code,
all of which will be wasted work since ultimately we plan
to go the rtl8xxxu route.
Regards,
Hans