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: <CACRpkdaPFzq=Qya_UoZpxHom+VcynTwQL9EfdLb_Vpr=g6+Prg@mail.gmail.com>
Date:	Wed, 8 Oct 2014 11:16:11 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	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>,
	Mark Brown <broonie@...aro.org>
Subject: Re: [PATCH 2/2] PMIC / opregion: support PMIC customized operation
 region for CrystalCove

On Wed, Oct 8, 2014 at 10:05 AM, Lee Jones <lee.jones@...aro.org> wrote:

> 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?).

PMIC (Power Management Integrated Circuit) is often not even a
correct name for the thing if it contains things like audio amplifiers
USB PHY intrerfaces or LED boosters as some do.

MSIC (Mixed-Signal Integrated Circuit) is the correct name for
silicon that is created as a one-stop shop for anything combining
digital and analog constructions, often in a higher micron node
(not as densely integrated) as a digital IC (the latter referred to
as SoCs, "baseband", "CPU" and whatnot).

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.

This driver clearly does not qualify, look:

> +static int intel_crc_pmic_update_power(struct regmap *regmap,
> +                                    struct pmic_pwr_reg *preg, bool on)
> +{
> +     int data;
> +
> +     if (regmap_read(regmap, preg->reg, &data))
> +             return -EIO;
> +
> +     if (on) {
> +             data |= PWR_SOURCE_SELECT | BIT(preg->bit);
> +     } else {
> +             data &= ~BIT(preg->bit);
> +             data |= PWR_SOURCE_SELECT;
> +     }
> +
> +     if (regmap_write(regmap, preg->reg, data))
> +             return -EIO;
> +     return 0;
> +}

Selecting power source? Isn't that something and MFD cell
spawned driver in either drivers/regulator or drivers/power should
be doing?

I know I have sinned in this regard in the past. But let's move
forward with defining what this subsystem should *REALLY*
be.

Yours,
Linus Walleij
--
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/