linux-kernel - Re: [PATCH v1 0/4] iosf

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:	Wed, 8 Jul 2015 12:55:31 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:	"David E. Box" <david.e.box@...ux.intel.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v1 0/4] iosf_mbi: clean up


* Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Wed, 2015-07-08 at 11:36 +0200, Ingo Molnar wrote:
> > * Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
> > 
> > > There are few patches to clean up (with small fixes) iosf_mbi 
> > > driver along with
> > > extension it to cover Intel Tangier.
> > > 
> > > Andy Shevchenko (4):
> > >   iosf_mbi: check result for all calls of debugfs API
> > >   iosf_mbi: pci_dev_put() is NULL-proof
> > >   iosf_mbi: group global variables
> > >   iosf_mbi: append Intel Tangier ID
> > > 
> > >  arch/x86/include/asm/iosf_mbi.h |  8 ++++----
> > >  arch/x86/kernel/iosf_mbi.c      | 31 +++++++++++++++--------------
> > > --
> > >  2 files changed, 19 insertions(+), 20 deletions(-)
> > 
> > Could you please also move it from arch/x86/kernel/ to 
> > arch/x86/platform/[intel-quark?] while at it?
> 
> I will think about proper folder (apparently not quark, since it is
> specific to man different Intel SoCs).

Yeah, you could make it arch/x86/platform/iosf/, and the file would be 
arch/x86/platform/iosf/mbi.c? Or something like that?

> > 
> > arch/x86/kernel/ is the wrong place for this driver.
> 
> Would be okay to send an additional patch or better to regenerate the whole 
> series?

So it might be better to first do the file movement, then the fixes. It should be 
relatively easy to regenerate the patches like that, and if any failure is 
bisected back to a commit it's easy to revert - or if some new review observation 
comes in then it will be easy to adjust the series.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/