Re: brcmfmac: don't warn user if requested nvram fails

[Hans de Goede <hdegoede@redhat.com>]

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