From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754950AbbLQTYi (ORCPT ); Thu, 17 Dec 2015 14:24:38 -0500 Received: from mail-yk0-f179.google.com ([209.85.160.179]:33338 "EHLO mail-yk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753451AbbLQTYg (ORCPT ); Thu, 17 Dec 2015 14:24:36 -0500 MIME-Version: 1.0 In-Reply-To: References: <20150825193408.GR8051@wotan.suse.de> <1440576394.2443.17.camel@loki> <20150829011130.GK8051@wotan.suse.de> <55E1724E.6040303@broadcom.com> <20150829183802.480b1425@tom-T450> <55E2BE0E.1070907@broadcom.com> From: "Luis R. Rodriguez" Date: Thu, 17 Dec 2015 11:24:15 -0800 X-Google-Sender-Auth: fBT3fgS3NFUbOORRivJBZteMpCk Message-ID: Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. To: Linus Torvalds , Greg Kroah-Hartman , Daniel Vetter , Josh Boyer Cc: Arend van Spriel , Ming Lei , Takashi Iwai , Liam Girdwood , "Jie, Yang" , Dmitry Torokhov , "joonas.lahtinen@linux.intel.com" , Tom Gundersen , Al Viro , Kay Sievers , David Woodhouse , lkml , yalin wang , Ming Lei , linux-wireless , linux-security-module Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 30, 2015 at 11:11 AM, Linus Torvalds wrote: > On Sun, Aug 30, 2015 at 1:25 AM, Arend van Spriel 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@kroah.com Luis