linux-kernel - Re: [PATCH 6/6] ARM: dts: Add tps65090 FETs constraints

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53EB4CA0.3010006@collabora.co.uk>
Date:	Wed, 13 Aug 2014 13:31:44 +0200
From:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
To:	Mark Brown <broonie@...nel.org>
CC:	Kukjin Kim <kgene.kim@...sung.com>,
	Doug Anderson <dianders@...omium.org>,
	Olof Johansson <olof@...om.net>,
	Yuvaraj Kumar C D <yuvaraj.cd@...il.com>,
	linux-samsung-soc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/6] ARM: dts: Add tps65090 FETs constraints

Hello Mark,

On 08/12/2014 11:27 PM, Mark Brown wrote:
> On Tue, Aug 12, 2014 at 08:49:29PM +0200, Javier Martinez Canillas wrote:
> 
>> So, is adding these voltages ranges (the design limits) in the Peach Pit DTS
>> file directly an acceptable solution? Basically what my previous patch [0] did.
> 
>> That matches what is in the board schematic so I assume that it's safe to use
>> these voltage ranges for that machine. If so I'll drop this series and repost
>> that patch fixing the typo error and commit message pointed by Doug that were
>> already addressed in $subject.
> 
> Well, I think the question is if you understand where those numbers come
> from and if they make sense.  I've not seen the schematic for the board
> so I can't comment but it is quite unusual to see ranges listed for so
> many supplies, for things like SD it's obviously normal but things like
> video_mid are a bit more surprising.  Does anything actually vary those
> voltages?
> 

You are right, in fact even the voltage for the SD supply (tps65090 fet4) does
not change but still their constraints have to be defined, since it is used as a
vmmc-supply and the series "Adding UHS support for dw_mmc driver" [0] calls
mmc_regulator_get_ocrmask()/mmc_regulator_set_ocr() for mmc->supply.vmmc.

For fixed regulators (like fet4), mmc_regulator_set_ocr() just skips varying the
regulator voltage but still expects to be able to obtain its voltage.

Since the FET is just a switch and doesn't have an output voltage, the regulator
core gets its parent supply voltage but regulator_list_voltge() [1] checks that
the obtained parent voltage is between the child regulator constraints.

So in this particular case it makes sense to compare that the parent voltage is
between the (design limits) voltage ranges for the FET but I agree that it may
not make sense on other boards.

Since I needed to add the ranges for fet4 I (wrongly) thought that it would make
sense to add the ranges for all the other FETs in case other boards had a
similar need. But now I understand your concerns about this series so I'll drop
it and just post a patch that adds to the Peach Pit and Pi DTS, the constraints
for the fet4 used as vmmc-supply instead of pretending that it's a common setup.

> The change where you fix up the supply mappings still makes sense of
> course.
>

Good to know, again thanks a lot for your feedback and explanations.

Best regards,
Javier

[0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/265657.html
[1]:
https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/tree/drivers/regulator/core.c?h=for-next#n2209
--
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/