lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 23 Jan 2019 10:37:07 -0600 From: Alan Tull <atull@...nel.org> To: Greg KH <gregkh@...uxfoundation.org> Cc: Richard Gong <richard.gong@...ux.intel.com>, Dinh Nguyen <dinguyen@...nel.org>, linux-kernel <linux-kernel@...r.kernel.org>, todd.riffel@...el.com, Richard Gong <richard.gong@...el.com> Subject: Re: [PATCHv1] firmware: intel_stratix10_service: add hardware dependency On Wed, Jan 23, 2019 at 10:00 AM Greg KH <gregkh@...uxfoundation.org> wrote: Hi Greg, > > On Wed, Jan 23, 2019 at 09:47:56AM -0600, richard.gong@...ux.intel.com wrote: > > From: Richard Gong <richard.gong@...el.com> > > > > Add a Kconfig dependency to ensure Intel Stratix10 service layer driver > > can be built only on the platform that supports it. > > > > Signed-off-by: Richard Gong <richard.gong@...el.com> > > --- > > drivers/firmware/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > > index f754578..cac16c4 100644 > > --- a/drivers/firmware/Kconfig > > +++ b/drivers/firmware/Kconfig > > @@ -218,7 +218,7 @@ config FW_CFG_SYSFS_CMDLINE > > > > config INTEL_STRATIX10_SERVICE > > tristate "Intel Stratix10 Service Layer" > > - depends on HAVE_ARM_SMCCC > > + depends on ARCH_STRATIX10 && HAVE_ARM_SMCCC > > That's lame, what about building for testing? Do you mean this instead? depends on (ARCH_STRATIX10 && HAVE_ARM_SMCCC) || COMPILE_TEST > > And is this needed now, for 5.0-final, or can it wait for 5.1? This change will reduce kernel size for most arm64. It can go into whichever kernel. We can resubmit allowing for COMPILE_TEST. > What > changed to require this? Nothing, we just didn't catch this. We're used to having our own defconfig. Not used to having a single defconfig that is shared. Thanks for the review comments, Alan > > tahnks, > > greg k-h
Powered by blists - more mailing lists