On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > > I am not sure how/why a firmware loading daemon would be a better > > idea now. What Marc describes that Josh proposed with signals for > > userspcae seems more aligned with what we likely need > > Quite frankly, I doubt you want a signal. > > You will want to have some way to specify where the firmware files > are. Right now we have "fw_path[]" which is hardcoded except for the > first entry that can be set as a module parameter. But you'd probably > want to expand on that, which implies some /sys or /proc interface. > > And once you do that, wouldn't it make more sense to just make the > "update the firmware path /proc/sys/kernel/fw_path file" make things > re-search for firmware? That could work, but it seems like overkill to allow changing the path, rather than the simpler interface of just telling the one driver "go ahead and direct-load your firmware now". I definitely don't think it should be a system-wide "mount event"; it should be a per-device "go direct-load your firmware" poke from userspace. That would solve the "build-in the driver so it can start waking up slow monitors, but wait to load the firmware until you have a filesystem" problem. (And it would avoid creating some unusual driver-specific late-firmware-load mechanism.) That said, the Chrome OS folks apparently have some mechanism where they mount a tmpfs over /lib/firmware to let userspace choose firmware at runtime, so perhaps the path-changing mechanism would help there. Kees? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
