linux-kernel - Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.03.1307171758591.14924@syhkavp.arg>
Date:	Wed, 17 Jul 2013 18:22:46 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Samuel Ortiz <sameo@...ux.intel.com>
cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Pawel Moll <pawel.moll@....com>,
	Jon Medhurst <tixy@...aro.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@....com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	Olof Johansson <olof@...om.net>,
	Achin Gupta <Achin.Gupta@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support

On Wed, 17 Jul 2013, Samuel Ortiz wrote:

> On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> > At this point I don't really care about the name.  I just want the damn 
> > thing merged upstream.  But after several iterations to either fit one 
> > or another maintainers taste, each rework ends up in that maintainer 
> > saying: "Now that you've reworked the code, I still don't like it since 
> > this no longer fits in my subsystem tree."
> FWIW, we asked Pawel to rework the sysreg and config parts of the
> vexpress driver, make it an actual MFD driver, and spread the remaining
> bits of the code into their respective subsystems. I don't think
> this is an eccentric requirement.

I agree.  However the code that Lorenzo just posted can't be deprived 
of any more sysreg/config parts.  They are simply nonexistent.

Even the larger code you reviewed before is completely useless without 
_additional_ drivers to go on top which are indeed waiting after this 
code to be merged before they are submitted to their respective 
subsystems.

And those additional drivers are way more interesting than this dumb 
register access arbitrator.  Because this is fundamentally the only 
thing it does.

> > In fact what we'd need at this point is 
> > drivers/code_that_no_subsystem_maintainers_wants/.  
> Which is what some people think drivers/mfd/ is...

Does mfd still stand for "Multi Function Device"?

> I don't mind merging Lorenzo's SPC driver as it is if he can explain to
> me how it will eventually evolve into an actual MFD driver. If that's
> not the case, I don't see how I could justify merging it through the
> MFD tree.

Maybe the misunderstanding is about what actually is a MFD driver.
Given your persisting reluctance, I may only conclude that this is 
indeed not a MFD driver after all.

So I'll follow existing precedents in the kernel and move Lorenzo's code 
to drivers/platform/vexpress/.


Nicolas
--
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/