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

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

[Hans de Goede]

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.

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.

Likewise for sdio devices on devicetree platforms
first try brcmfmac-4xxx-sdio-<model>.txt.

And for sdio devices on ACPI/x86 systems I want to
do something similar too.

Luis, do you think it would be a good idea to add
.optional_postfix member to driver_data_req_params
for this? I believe other sdio based wifi devices
may want to do the same, or should this be handled
in the driver by doing 2 driver_data_request_async
calls (the 2nd when the 1st fails) ?

Regards,

Hans

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

[Arend Van Spriel]

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.

> 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. 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.

> Likewise for sdio devices on devicetree platforms
> first try brcmfmac-4xxx-sdio-<model>.txt.
> 
> And for sdio devices on ACPI/x86 systems I want to
> do something similar too.
> 
> Luis, do you think it would be a good idea to add
> .optional_postfix member to driver_data_req_params
> for this? I believe other sdio based wifi devices
> may want to do the same, or should this be handled
> in the driver by doing 2 driver_data_request_async
> calls (the 2nd when the 1st fails) ?

I think we briefly touched this subject a while ago. It would be great
if the driver_data api could be given a list/array of files which can be
flagged as required or optional. Just not sure how to deal with drivers
that request a firmware file and fallback to requesting older ones
repeatedly thus stop processing upon first successful load. Both
use-cases seem present in drivers.

Regards,
Arend

> Regards,
> 
> Hans
> 
> 

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

[Hans de Goede]

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.

>> 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.

So would you be willing to accept a brcmfmac patch
trying such a post-fixed nvram filename first ?

>> Likewise for sdio devices on devicetree platforms
>> first try brcmfmac-4xxx-sdio-<model>.txt.
>>
>> And for sdio devices on ACPI/x86 systems I want to
>> do something similar too.
>>
>> Luis, do you think it would be a good idea to add
>> .optional_postfix member to driver_data_req_params
>> for this? I believe other sdio based wifi devices
>> may want to do the same, or should this be handled
>> in the driver by doing 2 driver_data_request_async
>> calls (the 2nd when the 1st fails) ?
>
> I think we briefly touched this subject a while ago.

Correct back then I wanted to achieve the same goals
(and I still do) for some ARM boards. What I'm striving
for here is "it just works" user experience when
people use a new enough distro which has all the
bits in place.

 > It would be great
> if the driver_data api could be given a list/array of files which can be
> flagged as required or optional. Just not sure how to deal with drivers
> that request a firmware file and fallback to requesting older ones
> repeatedly thus stop processing upon first successful load. Both
> use-cases seem present in drivers.

Regards,

Hans

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

[Arend Van Spriel]

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?

> 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.

Regards,
Arend

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

[Hans de Goede]

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

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

[Luis R. Rodriguez]

On Tue, Apr 11, 2017 at 10:53:57AM +0200, Hans de Goede wrote:
> 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.

We take licensing serious on linux-firmware, a IANAL is no excuse for
being sloppy.

> 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).

Either way I am convinced I can drop that patch then.

  Luis

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

[Luis R. Rodriguez]

On Fri, Apr 07, 2017 at 11:43:04PM +0200, Arend Van Spriel wrote:
> On 6-4-2017 14:14, Hans de Goede wrote:
> > Luis, do you think it would be a good idea to add
> > .optional_postfix member to driver_data_req_params
> > for this? I believe other sdio based wifi devices
> > may want to do the same, or should this be handled
> > in the driver by doing 2 driver_data_request_async
> > calls (the 2nd when the 1st fails) ?
> 
> I think we briefly touched this subject a while ago. It would be great
> if the driver_data api could be given a list/array of files which can be
> flagged as required or optional. Just not sure how to deal with drivers
> that request a firmware file and fallback to requesting older ones
> repeatedly thus stop processing upon first successful load. Both
> use-cases seem present in drivers.

I've now added chaining request support and it follows the API model
devised by Intel, as it is very sensible and should also work with open
firmware models very well. By default the optional nature is specific to
anything in between, but it will complain if no file is found at all,
unless of course the entire set is optional.

If the series of files do not match a simple API model / revisions,
then yes, I'd be happy to support allowing users to specify a list
of files with their own set of specific requirements (including specifying
if one optional or not). How I'd advise for this to be supported would be
with a flexible array pointer and setting the pointer / num_members later,
for processing. I recently had to demo how to do this so here is a simple
demo using flexible arrays embedded:

http://drvbp1.linux-foundation.org/~mcgrof/demos/demo-flexible-array-subopts.c

I would imagine macros can be added to driver_data.h to make spelling out
file entries easier to read.

Everything must be const on the request though. Oh and we want respective
test cases in the new test driver to ensure we never regress and things
work just as expected.

I'll respin the driver data API once again now addressing hopefully
the last pieces of feedback.

  Luis

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

[Hans de Goede]

Hi,

On 27-04-17 02:36, Luis R. Rodriguez wrote:
> On Tue, Apr 11, 2017 at 10:53:57AM +0200, Hans de Goede wrote:

<snip>

>>>> 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.
> 
> We take licensing serious on linux-firmware, a IANAL is no excuse for
> being sloppy.

I don't mean to be sloppy. As I already stated I plan to make it
clear in the commit msg that there is no license info for the nvram
file and that in my non expert opinion that is not a problem.

If people disagree then we will likely need to ask an actual lawyer
for advice and see from there,

Regards,

Hans

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

[Arend van Spriel]

On 4/30/2017 9:39 PM, Hans de Goede wrote:
> Hi,
> 
> On 27-04-17 02:36, Luis R. Rodriguez wrote:
>> On Tue, Apr 11, 2017 at 10:53:57AM +0200, Hans de Goede wrote:
> 
> <snip>
> 
>>>>> 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.
>>
>> We take licensing serious on linux-firmware, a IANAL is no excuse for
>> being sloppy.
> 
> I don't mean to be sloppy. As I already stated I plan to make it
> clear in the commit msg that there is no license info for the nvram
> file and that in my non expert opinion that is not a problem.
> 
> If people disagree then we will likely need to ask an actual lawyer
> for advice and see from there,

I think what Luis mean to say here is that you should be sure about this 
instead of submitting the patch and see what happens. In that respect I 
will inform internally what Broadcom policy is regarding the 
distribution requirements/restriction of the nvram files.

Regards,
Arend

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

[Rafał Miłecki]

On 8 April 2017 at 11:53, Hans de Goede <hdegoede@redhat.com> wrote:
> On 07-04-17 23:43, Arend Van Spriel wrote:
>> On 6-4-2017 14:14, Hans de Goede wrote:
>>> 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.

This is a late reply, I know...

I think you misunderstood my patch. It didn't completely remove the
warning. It just removed first try warning, where there is still a
chance of getting NVRAM from the platform data (special partition used
by bootloader & accessible by the operating system).

When both methods would fail, the warning would still appear.