linux-kernel - Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC

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: <20151023231822.GQ29919@sirena.org.uk>
Date:	Sat, 24 Oct 2015 08:18:22 +0900
From:	Mark Brown <broonie@...nel.org>
To:	"Andrew F. Davis" <afd@...com>
Cc:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Lee Jones <lee.jones@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Grygorii Strashko <grygorii.strashko@...com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the
 TPS65912 PMIC

On Fri, Oct 23, 2015 at 07:46:39AM -0500, Andrew F. Davis wrote:

> I know just because other drivers do it doesn't mean it's a good idea,
> but this is not new for MFDs and it is done in other regulators as well
> (mt6397, tps659038, qcom,spmi, etc..).

mt6397 doesn't do this, it doesn't have a compatible string at all (it's
doing what I'm recommending that you do).  The SPMI devices are
standalone devices, their parent device is actually functioning as a bus
controller here (it's really a microcontroller inside the SoC).  The
Palmas is part of how we realised this was a problem.

> >It seems like this is describing how Linux
> >loads drivers not how the hardware is constructed but DT should describe
> >the hardware.

> While I agree to a point, if we follow this to its logical conclusion we
> would end up with one compatible binding per SoC and be basically back to
> board files. We need some granularity, just finding out where is the issue,

The fact that the SoC DT is not distinct from the board DT is actually
one of the problems with the way we're using DT at the minute, it means
that DTBs are much less stable than they should be since we can enhance
support for SoCs but DTBs need regenerating to take advantage of it.  It
would be much better if the boards just referenced the SoC they use and
pulled in a separate definition of the SoC (DT overlays will make it
much more tractable to implement that if someone has time...).

> I would say that as these devices belong to different subsystems and are
> almost completely independent there should be no problem with having their
> own compatible matched hardware sub-node.

All it's adding is more typing for users.

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