On Fri, Jul 22, 2016 at 08:51:36AM -0400, Prarit Bhargava wrote: > On 07/22/2016 08:21 AM, Arend Van Spriel wrote: > >> Another option to solve to problem would be stop requesting not > >> available publicly firmware. However, I assume some drivers would > >> like to preserve that option. > > > > Actually, this is not the case with brcmfmac. We do need a firmware > > file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file, > > ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device > > works fine without it. > > > > What is still unclear to me is when request_firmware_direct() would fail > > and in what circumstances the udev helper is a valid callback. Can you > > explain such a scenario. Another question I have is what the reasons are > > behind the 60 seconds timeout. > > request_firmware_direct() will fail when the specified FW file is not present. > This is different from request_firmware() which implements a usermode helper to > potentially download firmware, or unpack a firmware image. > > Re: 60 second timeout ... The 60 second timeout with request_firmware() is > completely arbitrary. There is no way for udev to signal back to the kernel > that userspace helper has not completed its actions, so the kernel has a 60 dead > man timer-ish delay. Lets call it what it was: the 60 second timeout thing was simply a mistake. Its no longer 60 seconds anyway, and in fact its accepted a dreaded issue. What *we* should be doing is thinking about proper long term architecture now. Async probe was one solution to some issues, a new flexible firmware API that avoids the usermode helper 100% is another. Distros stuck with the fallback option should review their strategies, either disabling the fallback option, upgrade systemd, or use alternative solutions (opensuse has a good one). > >>>> However I wonder if changing that will not broke the case when > >>>> driver is build-in in the kernel and f/w is not yet available when > >>>> driver start to initialize. Or maybe nowadays this is not the case > >>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w > >>>> images are build-in in the kernel or copied to initramfs? > >>> > >>> That is a nice idea, but I have not seen any change in that area. Could > >>> have missed it. > >> > >> I believe this is how the things are already done, IOW switching to > >> request_firmware_direct() in the driver should be no harm. > > > > Ok. What are the consequences when: > > - driver is built-in. > > - driver+firmware present on initramfs. > > - driver on initramfs, firmware only present on rootfs. > > - driver+firmware only on rootfs. > > > > I assume the third one would be considered a configuration issue. > > I think your question here can be answered by reading drivers/base/Kconfig:88, > and reading about those 4 config options. No, this documentation is terrible, I've posted some patches to help with this mess. > I could paraphrase it butI think the > Kconfig notes are better than I could explain it. Note that this is how things > currently work with request_firmware_nowait(). IIRC request_firmware_nowait() > is just an asynchronous version of request_firmware(). ... its a mess. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
