On Sun, Aug 30, 2015 at 11:11 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Aug 30, 2015 at 1:25 AM, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: >> On 08/29/2015 12:38 PM, Ming Lei wrote: >> >> Does this mean a built-in driver can not get firmware from initramfs or >> built in the kernel early. Seems a bit too aggressive. > > Yeah, that seems wrong. Loading firmware from initramfs is required > for some things, like disk drivers. Of course, depending on how it's > done, it's all after the SYSTEM_BOOTING phase, but .. > > What we *might* do is to not allow it for the user-mode helper > fallback, FWIW, that's what we did, request_firmware_direct() now skips the silly usermode helper. I'll note that Greg pointed out to me that Daniel (was this right?) might have some use cases for the usermode helper in the future on graphics though. Daniel is that right? Can you clarify the use case, I'd just like to document this and keep it in mind for future design changes on firmware_class. Also, it occurs to me that if you have a need for it, perhaps others might and if we can avoid *others* from coming up with their own solution that'd be best, specifically as this is related to file loading -- more on this later generalized possible use cases in another thread I'll Cc you folks on. > but I think it's more likely that we'll just deprecate the > usermode helper fw loader entirely, so adding new error cases for it > seems pointless. I was shooting hard to deprecate the usermodehelper, Greg has noted that we can only phase it out though, so that is what I will be shooting for: a sysdata API, what will have firmware signing support later will *not* make use of the usermode helper. The old APIs will still use it. [0] http://lkml.kernel.org/r/20151006090821.GB9030@xxxxxxxxx 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
