Hi,
On 18-01-17 15:16, Bastien Nocera wrote:
On Tue, 2017-01-17 at 14:05 +0100, Hans de Goede wrote:
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.
I don't think that's true. Larry Finger has maintained a number of
"vendor" drivers in staging, obsoleting them when a better option, most
notably Jes' reverse-engineered/reimplemented driver for a number of
Realtek devices.
At least for rtl8723bs, I'd be happy to try and get it in the kernel,
Ok, if you want to take a shot at this I'm all for it. Let me know
if I can do anything to help (IMHO it would be better for you to
start the discussion on this upstream since you're currently
somewhat maintaining the out of tree version).
On a related topic besides the kernel-driver we also need to get
the firmware into linux-firmware. I expect we will be able to do
this as linux-firmware already has a whole bunch of realtek firmwares
but we still need to do this. Do you know who we need to contact
for this ? Note I'm willing to go and work on the firmware side of
this.
as long as we don't spend too much time trying to follow the kernel's
indentation policy, which would just make rebasing more complicated.
There are also a number of vendors which might be interested in this,
like NextThingCo for their CHIP (CHIP Pro too?), and Endless for one of
their ARM machines.
Right, this is exactly why I believe that it is important to have
sdio wifi work out of the box on Fedora.
Regards,
Hans
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
