linux-kernel - Re: [PATCH 4/7] soc/tegra: pmc: Add interface to set voltage of IO rails

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]

Date:	Fri, 15 Apr 2016 09:54:34 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Laxman Dewangan <ldewangan@...dia.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Olof Johansson <olof@...om.net>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Jon Hunter <jonathanh@...dia.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH 4/7] soc/tegra: pmc: Add interface to set voltage of IO rails

On Tue, Apr 12, 2016 at 4:56 PM, Laxman Dewangan <ldewangan@...dia.com> wrote:

> NVIDIA Tegra210 supports some of the IO interface which can operate
> at 1.8V or 3.3V I/O rail voltage levels. SW needs to configure
> Tegra PMC register to set different voltage level of IO interface based
> on IO rail voltage from power supply i.e. power regulators.
>
> Add APIs to set and get IO rail voltage from the client driver.
>
> Signed-off-by: Laxman Dewangan <ldewangan@...dia.com>

Nobody seems to mention the elephant in the room: why is this
not using the regulator subsystem and instead using custom
code under drivers/soc? We have worried before about drivers/soc
becoming a dumping ground akin to drivers/misc

IIRC in the past we tried to use regulators for this kind of fast
switches at ST-Ericsson, and the problem we ran into was that
regulators were kind of heavyweight and would need some
locking and required to run in slowpath.

But as complexity increases the question has to be asked
again, because what we don't want is for every SOC to start
reimplementing stuff from the regulator framework under
drivers/soc.

I'm asking you to make a case for this necessarily
different, "we are special" custom code.

Yours,
Linus Walleij