On Sat, Jul 23, 2016 at 1:19 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > 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. > Awesome. I leave the code as is and ignore any RHEL bugs that are related to that. If someone wants to improve all this, I'd be thankful if he could do the work in the subsystem as Arend suggested. -- 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
