linux-kernel - Re: [PATCH 2/2] PMIC / opregion: support PMIC customized operation region for CrystalCove

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: <20141008125429.GX4609@sirena.org.uk>
Date:	Wed, 8 Oct 2014 13:54:29 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Lee Jones <lee.jones@...aro.org>, Aaron Lu <aaron.lu@...el.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jacob Pan <jacob.jun.pan@...ux.intel.com>,
	Lejun Zhu <lejun.zhu@...el.com>,
	Radivoje Jovanovic <radivoje.jovanovic@...el.com>,
	Daniel Glöckner <dg@...ix.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH 2/2] PMIC / opregion: support PMIC customized operation
 region for CrystalCove

On Wed, Oct 08, 2014 at 11:16:11AM +0200, Linus Walleij wrote:
> On Wed, Oct 8, 2014 at 10:05 AM, Lee Jones <lee.jones@...aro.org> wrote:

Please don't send upstream mail to my work account (which I've never
used for upstream mail and isn't advertised in MAINTAINERS), it mostly
gets deleted unread.

> > With the influx of new same-chip devices, I think the MFD subsystem is
> > fast becoming overloaded.  I think all of the PMIC handling should in
> > fact either live in Regulators or have its own subsystem.

> You have a valid point, and it's been raised before that MFD risk being
> a dumping ground of the same kind that drivers/misc used to be (is?).

> If they shall live in MFD the driver there should (IMHO) just be
> an exchange station, multiplexing messages and spawning
> MFD cells into platform devices for respective *real* subsystem,
> various misc stuff should not be allowed to be shoehorned
> into MFD just because there is no other place to put it.

Right, there's a very clear role for MFD in multiplexing the various
functions of the device and dealing with any core behaviour it needs for
bootstrapping or things like chip level suspend and resume.  Dumping
that into some random subsystem doesn't seem to make any sense, but
doing things that fall outside that remit also don't seem clever.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)