Received: by 10.223.185.116 with SMTP id b49csp5625852wrg; Tue, 27 Feb 2018 17:29:12 -0800 (PST) X-Google-Smtp-Source: AG47ELspBfDRrS6iW3ZlnBRglkZ8W2kiJgMN1mR4yW0b9QmiDBHXs7XkNH+rCR2xsQ4KVFl7hSgT X-Received: by 2002:a17:902:52c1:: with SMTP id a59-v6mr6914159pli.37.1519781352171; Tue, 27 Feb 2018 17:29:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519781352; cv=none; d=google.com; s=arc-20160816; b=Vn7AwXtQf+qBhD61amJPyJYucHGJ3itw0Iw4GPiECwCSYKwKu70S0GZU3mQqXL56Eu 1gF0YWsv7bUvczqPhmMBCoy52rg/jZo3OyNLBUoEaiX8pldRUZDXjoHM86bynoiunmA+ oZKcb7r5BNoFZe0EhtmVLoDT8LCH55WnH3W1KP0eCxdrwKJvFefsPqB4RDD2DJFyz03d ZCMQo0Ik5DVZzEMczP1DQhxlXBoIV0Dbvb7EpnWQL+f7W6VaUJSPoe62v/GSWY75oaZB K4oMJ1CxSJj3a/ScOqLWGuLKYNjba5HAIUoky2gVliyenDCNyGOrWmcmmpW1ePY7i0UY gJ9w== 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=9omUFrarBRakkEUZdmUMc6zcgEbZ4qK8olQigtwsrzk=; b=EdrZcYdx3q+7EXE9D/VXGFXwil31+7aFvOdE20jWjasNaXPEG/dirA5VjfiNJi76YZ dxeCyWNp1/GK3gqW/PJTEBKLcBzXAehPJRGiX3WTu4Qq/lvM5I9hBFxVP1l6rvFycb9t hL4sNoSdIUBBYS32AA891LdGsDPJd5sD4oX/MlAQTFvXMC5ayAHU1jVEbn5hGgAxLtsQ WZDInvr/7jGftV39nTZ1ck98np/YdkA+Dl8Dxouu3e49E72WmwnN8NHtVsR7zWx3QeQQ z6fscVruw7QO3QsUwCfFlwiowe1m+ORIy78pFNOY6T0aOfKQQ6IF9aTep3UR4DnADtYg jfig== 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 i11si267592pgq.332.2018.02.27.17.28.57; Tue, 27 Feb 2018 17:29:12 -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 S1751844AbeB1B2G (ORCPT + 99 others); Tue, 27 Feb 2018 20:28:06 -0500 Received: from mx2.suse.de ([195.135.220.15]:48743 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751611AbeB1B2E (ORCPT ); Tue, 27 Feb 2018 20:28:04 -0500 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 2C6DCACBA; Wed, 28 Feb 2018 01:28:03 +0000 (UTC) Date: Wed, 28 Feb 2018 01:28:02 +0000 From: "Luis R. Rodriguez" To: Kees Cook Cc: "Luis R. Rodriguez" , Greg KH , 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: <20180228012802.GG14069@wotan.suse.de> References: <20180224024613.24078-1-mcgrof@kernel.org> <20180224024613.24078-8-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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? Luis