linux-kernel - Re: [PATCH v3 5/5] hisilicon/dts: Add hi655x pmic dts node

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: <20151218175813.GE5727@sirena.org.uk>
Date:	Fri, 18 Dec 2015 17:58:13 +0000
From:	Mark Brown <broonie@...nel.org>
To:	chenfeng <puck.chen@...ilicon.com>
Cc:	lee.jones@...aro.org, linux-kernel@...r.kernel.org,
	lgirdwood@...il.com, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, xuwei5@...ilicon.com, puck.chen@...yun.com,
	yudongbin@...ilicon.com, saberlily.xia@...ilicon.com,
	suzhuangluan@...ilicon.com, kong.kongxinwei@...ilicon.com,
	xuyiping@...ilicon.com, z.liuxinliang@...ilicon.com,
	weidong2@...ilicon.com, w.f@...wei.com, qijiwen@...ilicon.com,
	peter.panshilin@...ilicon.com, dan.zhao@...ilicon.com,
	linuxarm@...wei.com
Subject: Re: [PATCH v3 5/5] hisilicon/dts: Add hi655x pmic dts node

On Thu, Dec 17, 2015 at 11:27:27AM +0800, chenfeng wrote:

>  +- regulator-vset-regs: Voltage set register offset.
>  +- regulator-vset-mask: voltage set control mask.
>  +- regulator-n-vol: The num of support voltages.
>  +- regulator-vset-table: The table of support voltages.

> > Why is this in the binding?  This is a binding for a specific device,
> > there is no point in putting all these data tables in the DT - it just
> > bloats the DT and makes it harder for us to enhance our support for this
> > device in the future.

> You mentioned in previous version,I I have some questions for it.

> This regulator-vset-regs etc are vendor specific describe. The hi655x PMIC

There's nothing vendor specific about the way this is written...

> is a series of chips. They all have this value, but the offset may be different.
> And we can generate the dts file from excel which is defined by SOC.

> I think the dts is designed to distinguish different platform. If we hard code this
> in files, it may be also different to use as common in next chip version.

If your tooling can generate DT files it can generate C code just as
well and it seems unlikely you're going to be able to build new boards
without being able to do firmware updates here.  Especially for the
sorts of systems that use DT the set of scenarios where you're able to
update the DT but not the kernel seems like it will be extremely
limited.  I don't really buy the argument that there's any practical
difference in the ability to update the kernel and DT and to the extent
there is one it seems better to keep the ABI we have to support smaller
by having the DT be minimal.

This also allows us to map things more efficiently than we can with just
a table of voltages.  For example a good selection of the regulators in
your example DT appear to be linear ranges and so should be mapped as
such so we can do direct calcuations rather than having to iterate
through a table to map voltages into selectors.  That gets especially
serious for higher resolution regulators like most DCDCs (and modern
LDOs for that matter).

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