* Re: brcmfmac: don't warn user if requested nvram fails @ 2017-04-06 12:14 Hans de Goede 2017-04-07 21:43 ` Arend Van Spriel 0 siblings, 1 reply; 10+ messages in thread From: Hans de Goede @ 2017-04-06 12:14 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: Arend Van Spriel, linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-06 12:14 brcmfmac: don't warn user if requested nvram fails Hans de Goede @ 2017-04-07 21:43 ` Arend Van Spriel 2017-04-08 9:53 ` Hans de Goede 2017-04-27 0:45 ` Luis R. Rodriguez 0 siblings, 2 replies; 10+ messages in thread From: Arend Van Spriel @ 2017-04-07 21:43 UTC (permalink / raw) To: Hans de Goede, Luis R. Rodriguez; +Cc: linux-wireless 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 > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-07 21:43 ` Arend Van Spriel @ 2017-04-08 9:53 ` Hans de Goede 2017-04-10 21:50 ` Arend Van Spriel 2017-06-26 18:16 ` Rafał Miłecki 2017-04-27 0:45 ` Luis R. Rodriguez 1 sibling, 2 replies; 10+ messages in thread From: Hans de Goede @ 2017-04-08 9:53 UTC (permalink / raw) To: Arend Van Spriel, Luis R. Rodriguez Cc: linux-wireless, Rafał Miłecki 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-08 9:53 ` Hans de Goede @ 2017-04-10 21:50 ` Arend Van Spriel 2017-04-11 8:53 ` Hans de Goede 2017-06-26 18:16 ` Rafał Miłecki 1 sibling, 1 reply; 10+ messages in thread From: Arend Van Spriel @ 2017-04-10 21:50 UTC (permalink / raw) To: Hans de Goede, Luis R. Rodriguez; +Cc: linux-wireless, Rafał Miłecki 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-10 21:50 ` Arend Van Spriel @ 2017-04-11 8:53 ` Hans de Goede 2017-04-27 0:36 ` Luis R. Rodriguez 0 siblings, 1 reply; 10+ messages in thread From: Hans de Goede @ 2017-04-11 8:53 UTC (permalink / raw) To: Arend Van Spriel, Luis R. Rodriguez Cc: linux-wireless, Rafał Miłecki 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-11 8:53 ` Hans de Goede @ 2017-04-27 0:36 ` Luis R. Rodriguez 2017-04-30 19:39 ` Hans de Goede 0 siblings, 1 reply; 10+ messages in thread From: Luis R. Rodriguez @ 2017-04-27 0:36 UTC (permalink / raw) To: Hans de Goede Cc: Arend Van Spriel, Luis R. Rodriguez, linux-wireless, Rafał Miłecki 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-27 0:36 ` Luis R. Rodriguez @ 2017-04-30 19:39 ` Hans de Goede 2017-05-01 8:57 ` Arend van Spriel 0 siblings, 1 reply; 10+ messages in thread From: Hans de Goede @ 2017-04-30 19:39 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Arend Van Spriel, linux-wireless, Rafał Miłecki 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-30 19:39 ` Hans de Goede @ 2017-05-01 8:57 ` Arend van Spriel 0 siblings, 0 replies; 10+ messages in thread From: Arend van Spriel @ 2017-05-01 8:57 UTC (permalink / raw) To: Hans de Goede, Luis R. Rodriguez; +Cc: linux-wireless, Rafał Miłecki 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-08 9:53 ` Hans de Goede 2017-04-10 21:50 ` Arend Van Spriel @ 2017-06-26 18:16 ` Rafał Miłecki 1 sibling, 0 replies; 10+ messages in thread From: Rafał Miłecki @ 2017-06-26 18:16 UTC (permalink / raw) To: Hans de Goede Cc: Arend Van Spriel, Luis R. Rodriguez, linux-wireless, 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: brcmfmac: don't warn user if requested nvram fails 2017-04-07 21:43 ` Arend Van Spriel 2017-04-08 9:53 ` Hans de Goede @ 2017-04-27 0:45 ` Luis R. Rodriguez 1 sibling, 0 replies; 10+ messages in thread From: Luis R. Rodriguez @ 2017-04-27 0:45 UTC (permalink / raw) To: Arend Van Spriel; +Cc: Hans de Goede, Luis R. Rodriguez, linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-06-26 18:16 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-06 12:14 brcmfmac: don't warn user if requested nvram fails Hans de Goede 2017-04-07 21:43 ` Arend Van Spriel 2017-04-08 9:53 ` Hans de Goede 2017-04-10 21:50 ` Arend Van Spriel 2017-04-11 8:53 ` Hans de Goede 2017-04-27 0:36 ` Luis R. Rodriguez 2017-04-30 19:39 ` Hans de Goede 2017-05-01 8:57 ` Arend van Spriel 2017-06-26 18:16 ` Rafał Miłecki 2017-04-27 0:45 ` Luis R. Rodriguez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).