linux-kernel - Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10

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: <5257A05B.2070906@ti.com>
Date:	Fri, 11 Oct 2013 12:23:15 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Nishanth Menon <nm@...com>
CC:	Mark Rutland <mark.rutland@....com>,
	dt list <devicetree@...r.kernel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Pawel Moll <pawel.moll@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	Stephen Warren <swarren@...dotorg.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Benoit Cousson <bcousson@...libre.com>,
	linux-omap <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from
 smps10_out1

Hi,

On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
> On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I <kishon@...com> wrote:
>>
>>> regulator-boot-on indicates that PMIC enables it by default as part of
>>> OTP or some internal behavior -> Looking at the measurements done on
>>> uEVM and OTP information -> regulator-boot-on should be kept here.
>>
>> No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
>> driver to handle it.
>> Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
>> ideally be detected only when you connect a host cable.
>> Btw I didn't exactly get why you want regulator-boot-on should be kept here.
> 
> binding description states:
> - regulator-boot-on: bootloader/firmware enabled regulator
> Further info: include/linux/regulator/machine.h
> * @boot_on: Set if the regulator is enabled when the system is initially
> *           started.  If the regulator is not enabled by the hardware or
> *           bootloader then it will be enabled when the constraints are
> *           applied.
> 
> What that means is that it is enabled by firmware/bootloader (in our
> case One Time Program {OTP} inside Palmas) when the system switches on
> even before the kernel starts. and we know SMPS10 is autoenabled by
> Palmas OTP configuration even before first instruction in A15
> executes.

Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
> 
> I think you misunderstand this to mean that you'd like the regulator
> to be *switched on* automatically at kernel boot by regulator
> framework - there is no reasoning why we'd want such a binding since
> we'd expect drivers to do their job of requesting and enabling
> regulators on need..

The comment you just quoted tells it enables the regulator if its not enabled
by hardware. "If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied." At-least that's what
I understood from that comment.

Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.

Thanks
Kishon
--
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/