Received: by 10.192.165.148 with SMTP id m20csp1413903imm; Sat, 21 Apr 2018 07:54:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx481NuWDG9UDzEf4qpGizY4nb+bwuzQ0ec2/EeDr6cjdlWUeB7nspGi64AxqqPtc2Tf0HOLp X-Received: by 2002:a17:902:76c7:: with SMTP id j7-v6mr13890648plt.108.1524322466305; Sat, 21 Apr 2018 07:54:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524322466; cv=none; d=google.com; s=arc-20160816; b=DYzw1tUIq26K68oD4rYg1Zdbz4HJuPN48I+XqHGrsDvasC3GLV1aa4szdagsllvUm7 ZNJqzd17KYtrIX/sxg/vtC7isrzZYtR4+TX62AesWwl7IlrE8srag8YdxrRUx59G8cxB A4iJtnWGOvqxmFo0xgQ9+rPFGGIm9A1VyorrZiqq103ms6XpYBwqm1yQ6Hi4WzdmoBzW EXcWRv7M3yOI6ROdwkB2M5eGzKBn3oQdQ9/h0Z84XJ6dcjrfTPKZORgZQYCaeKOPAyRv cYVpq9akRXwKI7BfoqBBlJ1CSTVnjMVJQtw9eq2VRhrFxpA3IXK+ClADTZDFgjd/QMll Beaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Z7fRnUAVgujKO6NzZoEeu+f2aVz8PQ/5CqkRfpznDXs=; b=FGeo08NF/EICZeXEhlmuBc8TRunUpcTr8vCWXXomEoxGgid8qf8YkaohoyzSy5W8oD 1sWV27GARxv90p7CZupQ9zYmVstogI1wVePZCy6aDq2PVvGiZE//9p4N6cAwMd83er1p 0lg1ng7QS6Tj7s/5esRiUs0xFM2l57WEMvM1c+AdSpRZWpiNdEsrFoWaOZvO9dXkblBs bcz/lX7UlkTIXiNExljLk/xMYOYaSkGz781uQeXvirkPcbisUFnIeaUpZXAes5Q3fh5h S498DIX1Raln6fqRhfuKC8NKvXtjlvI/PEJsc3R1XxkLw9wYAxa6BE354T+M80zqCrv0 FprA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b12-v6si8140259pls.542.2018.04.21.07.53.48; Sat, 21 Apr 2018 07:54:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753080AbeDUOtO (ORCPT + 99 others); Sat, 21 Apr 2018 10:49:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:51427 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752700AbeDUOtN (ORCPT ); Sat, 21 Apr 2018 10:49:13 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BA8B7AE92; Sat, 21 Apr 2018 14:49:11 +0000 (UTC) Date: Sat, 21 Apr 2018 16:49:11 +0200 From: "Luis R. Rodriguez" To: "Luis R. Rodriguez" Cc: Andres Rodriguez , Greg Kroah-Hartman , Hans de Goede , Linus Torvalds , Kees Cook , David Woodhouse , linux-kernel@vger.kernel.org, alexdeucher@gmail.com, ckoenig.leichtzumerken@gmail.com, kvalo@codeaurora.org, arend.vanspriel@broadcom.com Subject: Re: [PATCH 5/9] firmware: add functions to load firmware without warnings v4 Message-ID: <20180421144911.GV14440@wotan.suse.de> References: <20180417153307.3693-1-andresx7@gmail.com> <20180417153307.3693-6-andresx7@gmail.com> <20180421143206.GQ14440@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180421143206.GQ14440@wotan.suse.de> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 21, 2018 at 04:32:06PM +0200, Luis R. Rodriguez wrote: > On Tue, Apr 17, 2018 at 11:33:03AM -0400, Andres Rodriguez wrote: > > @@ -755,10 +779,11 @@ static void firmware_request_work_func(struct work_struct *work) > > } > > > > /** > > - * firmware_request_nowait() - asynchronous version of firmware_request > > + * firmware_request_nowait2() - asynchronous version of firmware_request > > * @module: module requesting the firmware > > * @uevent: sends uevent to copy the firmware image if this flag > > * is non-zero else the firmware copy must be done manually. > > + * @warn: enable warnings > > * @name: name of firmware file > > * @device: device for which firmware is being loaded > > * @gfp: allocation flags > > @@ -778,8 +803,8 @@ static void firmware_request_work_func(struct work_struct *work) > > * - can't sleep at all if @gfp is GFP_ATOMIC. > > **/ > > int > > -firmware_request_nowait( > > - struct module *module, bool uevent, > > +firmware_request_nowait2( > > + struct module *module, bool uevent, bool warn, > > const char *name, struct device *device, gfp_t gfp, void *context, > > void (*cont)(const struct firmware *fw, void *context)) > > { > > @@ -799,7 +824,8 @@ firmware_request_nowait( > > fw_work->context = context; > > fw_work->cont = cont; > > fw_work->opt_flags = FW_OPT_NOWAIT | > > - (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER); > > + (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER) | > > + (warn ? 0 : FW_OPT_NO_WARN); > > > > if (!uevent && fw_cache_is_setup(device, name)) { > > kfree_const(fw_work->name); > > @@ -818,6 +844,24 @@ firmware_request_nowait( > > schedule_work(&fw_work->work); > > return 0; > > } > > +EXPORT_SYMBOL_GPL(firmware_request_nowait2); > > + > > +/** > > + * firmware_request_nowait() - compatibility version of firmware_request_nowait2 > > + * > > + * This is equivalent to calling firmware_request_nowait2 with warnings enabled. > > + * > > + * Refer to firmware_request_nowait2 for further details. > > + **/ > > +int > > +firmware_request_nowait( > > + struct module *module, bool uevent, > > + const char *name, struct device *device, gfp_t gfp, void *context, > > + void (*cont)(const struct firmware *fw, void *context)) > > +{ > > + return firmware_request_nowait2(module, uevent, true, name, device, > > + gfp, context, cont); > > +} > > EXPORT_SYMBOL(firmware_request_nowait); > > > > #ifdef CONFIG_PM_SLEEP > > Ugh this is precisely the type of naming issue I predicted *years ago* > about the unflexibility of the naming scheme we used. Greg, since you had > sent us this rabbit hole, any name preference here? Please review what is > proposed and also suggest a scheme which you do prefer. I'm done with > the bikeshedding and just want to move on, but in a way that scales. I'll side for now with Kalle's suggestion of having: firmware_request_nowait_nowarn() as nasty as it may seem. And this is just because we embarked on the path to not have parameters passed to modify the calls site. Luis