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: <5257A0C0.8000701@ti.com>
Date:	Fri, 11 Oct 2013 12:24:56 +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

On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
> 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.

btw.. I think this is the code in regulator fw that's responsible for enabling..

	/* If the constraints say the regulator should be on at this point
	 * and we have control then make sure it is enabled.
	 */
	if ((rdev->constraints->always_on || rdev->constraints->boot_on) &&
	    ops->enable) {
		ret = ops->enable(rdev);
		if (ret < 0) {
			rdev_err(rdev, "failed to enable\n");
			goto out;
		}
	}

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ