linux-kernel - Re: [PATCH] platform: intel_turbo_max

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 21 Feb 2017 10:35:57 -0800
From:   Darren Hart <dvhart@...radead.org>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc:     Paul Gortmaker <paul.gortmaker@...driver.com>,
        linux-kernel@...r.kernel.org, Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH] platform: intel_turbo_max_3: make it explicitly
 non-modular

On Mon, Feb 20, 2017 at 07:55:45AM -0800, Srinivas Pandruvada wrote:
> On Thu, 2017-02-16 at 19:37 -0800, Darren Hart wrote:
> > On Mon, Feb 13, 2017 at 07:37:00PM -0500, Paul Gortmaker wrote:
> > > The Kconfig currently controlling compilation of this code is:
> > > 
> > > drivers/platform/x86/Kconfig:config INTEL_TURBO_MAX_3
> > > drivers/platform/x86/Kconfig:   bool "Intel Turbo Boost Max
> > > Technology 3.0 enumeration driver"
> > > 
> > > ...meaning that it currently is not being built as a module by
> > > anyone.
> > > 
> > > Lets remove the couple traces of modular infrastructure use, so
> > > that
> > > when reading the driver there is no doubt it is builtin-only.
> > > 
> > > Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> > > 
> > > We also delete the MODULE_LICENSE tag etc. since all that
> > > information
> > > was (or is now) contained at the top of the file in the comments.
> > > 
> > > We do uncover some implicit includes during build coverage that
> > > were hidden behind the module.h which pulls in a lot of dependants.
> > > 
> > 
> > Paul, this all looks so very familiar... have we been through this
> > before? Maybe
> > for another driver...
> > 
> > > Cc: Darren Hart <dvhart@...radead.org>
> > > Cc: Andy Shevchenko <andy@...radead.org>
> > > Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
> > 
> > Srinivas, any objections?
> This module can be loadable just by adding EXPORT_GPL to two scheduler
> function. I was hoping that someone will require those functions to be
> exported.
> But any way I have no objections in this case as this driver doesn't
> have to be loadable at all.

OK, merged. We can always make it a module if that becomes an option.

-- 
Darren Hart
Intel Open Source Technology Center