Hi,
On 10-04-17 23:50, Arend Van Spriel wrote:
On 8-4-2017 11:53, Hans de Goede wrote:
Hi,
On 07-04-17 23:43, Arend Van Spriel wrote:
On 6-4-2017 14:14, Hans de Goede wrote:
Hi,
I noticed your patch-series on the lwn.net kernel page,
and I took a peek :)
I don't think that this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170329-driver-data-v2-try3&id=3968dd3031d1ff7e7be4acfb810948c70c2d4490
Is a good idea, specifically the "do not warn" part,
although the brcmfmac driver will indeed try to continue
without a nvram file, in my experience it almost all
the time will not work properly without the nvram file.
Actually, brcmfmac will only continue without nvram for PCIe devices.
For SDIO it is a different story, which may be the kind of devices you
have experienced.
Ah, no I've experience with both now, and the device I've
with a PCIE which needs nvram:
http://www.gpd.hk/gpdwin.asp
Will not work without the nvram file, so I really think
we should at least keep a warning msg here.
Nice gadget.
Arend, should we maybe just make the missing nvram file
a fatal error ?
###
While on the subject of nvram file loading, I want to make
some changes to how brcmfmac does this, for pcie
devices I want it to first try:
brcmfmac-4xxx-sdio-<pci-subsys-vid>-<pci-subsys-pid>.txt
and only if that is not present fallback to
brcmfmac-4xxx-sdio.txt, so that we can include the
brcmfmac-4xxx-sdio-<pci-subsys-vid>-<pci-subsys-pid>.txt
in the linux-firmware repo and have things just work.
You got me confused. I suppose the -sdio- should not be in the filename
examples above.
Right, sorry. For the pcie device I'm looking at the
name is brcmfmac4356-pcie.txt and I would like to propose
to first check for "brcmfmac4356-<pci-subsys-vid>-<pci-subsys-pid>.txt"
So who is going to provide these nvram files. We can not
maintain that as there are too many variants and they are under control
of the OEM/ODM.
Users / people like me who are interested in using certain
devices with Linux. The idea is to at least make it possible to
have these devices just work. E.g. I would like a user to be
able to insert a USB-stick with a live Fedora 27 and then
have everything just work on the GPD win.
To make this happen I will submit the nvram file from the
Windows install on the GPDwin to linux-firmware as
"brcmfmac4356-<pci-subsys-vid>-<pci-subsys-pid>.txt"
and yes I've checked that there are sensible values in
the subsys ids.
I suppose the "nvram file from the Windows install" than has a
redistributable license?
IANAL but I fail to see how the contents of this file is
anything but functional and as such not copyright-able.
That at least is what I plan to put in the commit msg
when submitting it to linux-firmware and then we will
see from there.
So would you be willing to accept a brcmfmac patch
trying such a post-fixed nvram filename first ?
It seems a sensible approach, but the devil is probably in the details.
Ok, I'll leave this on my todo list then. Expect a patch
sometime in the future (but not really soon).
Regards,
Hans
