Received: by 10.213.65.68 with SMTP id h4csp220239imn; Tue, 20 Mar 2018 01:33:17 -0700 (PDT) X-Google-Smtp-Source: AG47ELtfto2PxMYa+g1jOHwHAz2fv/YzJth6TK3Lq1dROQtmT1XhnCU7ju5U8G5dQoXGuFZeJt0B X-Received: by 10.167.128.2 with SMTP id j2mr12977570pfi.179.1521534797062; Tue, 20 Mar 2018 01:33:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521534797; cv=none; d=google.com; s=arc-20160816; b=XZT4vJz/1grlnKbU1vc8OsaiFOKfHWXwxXEFcVEwxJtA99dtiVxZTfpKXBCG7x2CGe gARyHgY2NmXm7VPhLIUlRXbZEswZw+IeKqZw2K8WO0CQkcB3OHXIPtlY+3JijyOYhdbP Clx4CKWFaxYQaf+uj7gh6ByGvm2JYVNEIYMZpn/ur8iF3xhA2XYCWSYvnFV8coMA69Hn SUEOPYzl3AYgR/6Bj351hXjopwoFBZODOqkM4kkO08YPDW7dsEOMZyoUBaXMkFrFQG3v 9OBBe98FyfsPVwZVEwvSICCJy9azKcaWbMTQyCVRRzRY+qZRyPBqd9T6hBosMpdChzKr 1Grg== 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=jRWHtD3d7BKxbn2fEYlCJ0v+SDDD7t/RVMtYBPfnD6c=; b=nHrF+aGt3xd6Joa3KXn9hdvVzma4eQyl3+cWsjvfRAZPJHAhG6waLZXxC9/QCxsxKQ yIefSwwFdmX3kgSP99wvLl/leIf8w7UVbQFMPX7gvH50WDruczeWXN+NTYU6ndYwX16w JFx/fwB7oko90wpyXiQz4nbtucKu+y24vSOY8QxOeg0+FOeWl59rq/nmA5a8eyaNsido 8cz7mWQqcXtcd0Ige0I7MSIXllLYoNFa/CCcOfSAmoWMvrqTKNEMVa2sBNXsgWECqUzC hIJ83PshXzyQj3wW1ccRRIiJO0jZb4UgvbjrMF0RNptzs2nqDtbMK1TcWN4Ua8z+CJYT 9D0Q== 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 q128si861417pga.833.2018.03.20.01.33.00; Tue, 20 Mar 2018 01:33:17 -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 S1752171AbeCTIbA (ORCPT + 99 others); Tue, 20 Mar 2018 04:31:00 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53960 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbeCTIa5 (ORCPT ); Tue, 20 Mar 2018 04:30:57 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id F2985ECB; Tue, 20 Mar 2018 08:30:56 +0000 (UTC) Date: Tue, 20 Mar 2018 09:30:55 +0100 From: Greg KH To: "Luis R. Rodriguez" Cc: akpm@linux-foundation.org, cantabile.desu@gmail.com, kubakici@wp.pl, linux-wireless@vger.kernel.org, keescook@chromium.org, shuah@kernel.org, mfuzzey@parkeon.com, zohar@linux.vnet.ibm.com, dhowells@redhat.com, pali.rohar@gmail.com, tiwai@suse.de, arend.vanspriel@broadcom.com, zajec5@gmail.com, nbroeking@me.com, markivx@codeaurora.org, broonie@kernel.org, dmitry.torokhov@gmail.com, dwmw2@infradead.org, torvalds@linux-foundation.org, Abhay_Salunke@dell.com, bjorn.andersson@linaro.org, jewalt@lgsinnovations.com, oneukum@suse.com, ast@fb.com, andresx7@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot Message-ID: <20180320083055.GA21640@kroah.com> References: <20180310141501.2214-1-mcgrof@kernel.org> <20180310141501.2214-20-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180310141501.2214-20-mcgrof@kernel.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote: > Some devices have an optimization in place to enable the firmware to > be retaineed during a system reboot, so after reboot the device can skip > requesting and loading the firmware. This can save up to 1s in load > time. The mt7601u 802.11 device happens to be such a device. > > When these devices retain the firmware on a reboot and then suspend > they can miss looking for the firmware on resume. To help with this we > need a way to cache the firmware when such an optimization has taken > place. > > Signed-off-by: Luis R. Rodriguez > --- > .../driver-api/firmware/request_firmware.rst | 14 +++++++++++++ > drivers/base/firmware_loader/main.c | 24 ++++++++++++++++++++++ > include/linux/firmware.h | 3 +++ > 3 files changed, 41 insertions(+) > > diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst > index cc0aea880824..b554f4338859 100644 > --- a/Documentation/driver-api/firmware/request_firmware.rst > +++ b/Documentation/driver-api/firmware/request_firmware.rst > @@ -44,6 +44,20 @@ request_firmware_nowait > .. kernel-doc:: drivers/base/firmware_class.c > :functions: request_firmware_nowait > > +Special optimizations on reboot > +=============================== > + > +Some devices have an optimization in place to enable the firmware to be > +retained during system reboot. When such optimizations are used the driver > +author must ensure the firmware is still available on resume from suspend, > +this can be done with request_firmware_cache() insted of requesting for the > +firmare to be loaded. > + > +request_firmware_cache() > +----------------------- > +.. kernel-doc:: drivers/base/firmware_class.c > + :functions: request_firmware_load > + > request firmware API expected driver use > ======================================== > > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > index 2913bb0e5e7b..04bf853f60e9 100644 > --- a/drivers/base/firmware_loader/main.c > +++ b/drivers/base/firmware_loader/main.c > @@ -656,6 +656,30 @@ int request_firmware_direct(const struct firmware **firmware_p, > } > EXPORT_SYMBOL_GPL(request_firmware_direct); > > +/** > + * request_firmware_cache: - cache firmware for suspend so resume can use it > + * @name: name of firmware file > + * @device: device for which firmware should be cached for > + * > + * There are some devices with an optimization that enables the device to not > + * require loading firmware on system reboot. This optimization may still > + * require the firmware present on resume from suspend. This routine can be > + * used to ensure the firmware is present on resume from suspend in these > + * situations. This helper is not compatible with drivers which use > + * request_firmware_into_buf() or request_firmware_nowait() with no uevent set. > + **/ > +int request_firmware_cache(struct device *device, const char *name) > +{ > + int ret; > + > + mutex_lock(&fw_lock); > + ret = fw_add_devm_name(device, name); > + mutex_unlock(&fw_lock); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(request_firmware_cache); I know you are just following the existing naming scheme, but please let's not continue the problem here. Can you prefix all of the firmware exported symbols with "firmware_", and then the verb. So this would be "firmware_request_cache", and the older function would be "firmware_request_direct". I've stopped here in the patch series, applying the others now, so feel free to rebase and resend what I've missed, and the minor fixups for the prior patches. thanks, greg k-h