Received: by 10.223.185.116 with SMTP id b49csp5856750wrg; Tue, 27 Feb 2018 23:12:25 -0800 (PST) X-Google-Smtp-Source: AH8x226ykZyB4vSYc4hV5v5VudKoUK8E2BTtH8Cg2lMKvOWxG6AkR1SMSjrOgae7xlcxWzUZYbd5 X-Received: by 10.98.10.219 with SMTP id 88mr16798080pfk.202.1519801945695; Tue, 27 Feb 2018 23:12:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519801945; cv=none; d=google.com; s=arc-20160816; b=vjj4sLKVko3yMPxeuE55r6287PyDTq5REnCPlaHgYUIYVjiSzSYij7ms8kZScKnwmu 62y15+4x+F9k9hjNcsUOSGxMAO3nU2/mVhpzFcP7DWwC64cApDzxRHrkMnG46TA+ksVw QWf5zFSeflryumcHj4z/eWFgCkAlS3FDK58q1b54hTLvjhyUP0KpU2l0hV6j6RlQMv8U ANuMxeRKpBciadS+wpa6Mgrkm0redQdN8MFfHmmWZWOdfM3c3oRbTMuwP4PQ/+lc8SF0 PEzab8gq16U8+84IvkOTUo8paS3PHOkDGzY6cBOXoL/pPFRJjTMU1Sle8jGSr9MrWgX6 Qn/Q== 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=rjRWop4yeZWttqWKY6h22OBVS73VD2Y8KMVAL9AdJec=; b=QK5TrKkCte3Jte72xVDV/I0C6VuEJ0MVsHgtaVBiPc90Y5iwjUU2c+zZXWV0Pgl3w1 /+KtJhxBISU73rNf9aUMd/E0cAZgmZCTwzlwUCfL/PCX7taz70dSt9iOl98noI5ZJ3ap s1kj1xKlRVaocOVIx34lEj6CVnVaRjmFQROq861M8F2dHPZqIN6QH5NdO8eRQkBK1Xj9 sXZe5NaS/hm5RmuLCTDwKAwTKEGZPE9RTFqoszk9lqZmsW9hiT3/HX8S4RKLB1dLxpcK l1DGUndsRhTiGLUrNU7nG4fC9WC/A1MksNgfpFGwUhvhKZijlK2Y88b/xpkWkvfArSlW SNGA== 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 198si651330pga.176.2018.02.27.23.12.10; Tue, 27 Feb 2018 23:12:25 -0800 (PST) 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 S1751717AbeB1HLc (ORCPT + 99 others); Wed, 28 Feb 2018 02:11:32 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:57900 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbeB1HLb (ORCPT ); Wed, 28 Feb 2018 02:11:31 -0500 Received: from localhost (clnet-b04-243.ikbnet.co.at [83.175.124.243]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 6891614C6; Wed, 28 Feb 2018 07:11:30 +0000 (UTC) Date: Wed, 28 Feb 2018 08:11:31 +0100 From: Greg KH To: Kees Cook Cc: "Luis R. Rodriguez" , Andrew Morton , Shuah Khan , Martin Fuzzey , Mimi Zohar , David Howells , pali.rohar@gmail.com, Takashi Iwai , arend.vanspriel@broadcom.com, =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , nbroeking@me.com, Vikram Mulukutla , stephen.boyd@linaro.org, Mark Brown , Dmitry Torokhov , David Woodhouse , Linus Torvalds , Abhay_Salunke@dell.com, bjorn.andersson@linaro.org, jewalt@lgsinnovations.com, LKML , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH v2 07/11] firmware: split firmware fallback functionality into its own file Message-ID: <20180228071131.GA17185@kroah.com> References: <20180224024613.24078-1-mcgrof@kernel.org> <20180224024613.24078-8-mcgrof@kernel.org> <20180228012802.GG14069@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 27, 2018 at 09:33:28PM -0800, Kees Cook wrote: > On Tue, Feb 27, 2018 at 5:28 PM, Luis R. Rodriguez wrote: > > On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote: > >> On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > >> > The firmware fallback code is optional. Split that code out to help > >> > distinguish the fallback functionlity from othere core firmware loader > >> > features. This should make it easier to maintain and review code > >> > changes. > >> > > >> > The reason for keeping the configuration onto a table which is built-in > >> > if you enable firmware loading is so that we can later enable the kernel > >> > after subsequent patches to tweak this configuration, even if the > >> > firmware loader is modular. > >> > > >> > This introduces no functional changes. > >> > > >> > Signed-off-by: Luis R. Rodriguez > >> > --- > >> > drivers/base/Makefile | 4 +- > >> > drivers/base/firmware_fallback.c | 661 +++++++++++++++++++++++++++ > >> > drivers/base/firmware_fallback.h | 61 +++ > >> > drivers/base/firmware_fallback_table.c | 29 ++ > >> > drivers/base/firmware_loader.c | 803 +-------------------------------- > >> > drivers/base/firmware_loader.h | 115 +++++ > >> > 6 files changed, 874 insertions(+), 799 deletions(-) > >> > create mode 100644 drivers/base/firmware_fallback.c > >> > create mode 100644 drivers/base/firmware_fallback.h > >> > create mode 100644 drivers/base/firmware_fallback_table.c > >> > create mode 100644 drivers/base/firmware_loader.h > >> > >> Does it make sense to have a separate subdirectory for firmware > >> instead? I did this _ stuff with lkdtm and have regretted it. (I'm > >> likely going to make a subdirectory for it this cycle...) > > > > Sure, the only eyesore is that drivers/base/firmware.c what is that for? > > > > drivers/base/firmware_loader/ ok? > > Yeah? Seems fine to me. Greg, do you have thoughts on this? I don't care :)