linux-kernel - Re: [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data

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: <20100714164708.GD1689@bnru01.bnr.st.com>
Date:	Wed, 14 Jul 2010 22:17:09 +0530
From:	Sundar R IYER <sundar.iyer@...ricsson.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	"lrg@...mlogic.co.uk" <lrg@...mlogic.co.uk>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@...t.st.com>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	Bengt JONSSON <bengt.g.jonsson@...ricsson.com>
Subject: Re: [PATCH v2 2/2] ux500: add ab8500-regulators machine specific
 data

> Are you positive that in your system it is sensible for consumers to
> enable and disable all the supplies?  Usually there are restrictions on
> what can sensibly be done on a given system.  For example, disabling the
> CPU core or RAM supplies from software would normally not work terribly
> well.
As I said earlier, there are other supplies which I havent exposed here,
simply because,
 1. they are controlled out of the kernel, which makes it meaningless
    to include them for kernel modules
 2. Even if those were included, the risk of mis-controlling them due
    to bad SW is very high as you say and hence safely out of SW control.

I assure you that such supplies are *not* included in this list.

> CPU core or RAM supplies from software would normally not work terribly
Also, usually the deepest(lowest) power state for the CPU core is
~0V(atleast on our platform); which can be possible only by switching
off the supplies to the core; thus effectively resulting in being
controlled by SW. Further, I dont see the point of running full supplies
to the RAM in a system idle state, when it is okay for the RAM to be
powered @ a half rating OIW accountable to the idle state latencies.

> Right, but think about the case I'm talking about: if you've only hooked
> up some but not all of the consumers then the core has no idea about the
> consumers you didn't hook up.  You can only do power control when *all*
> the consumers needed are configured.
I see your point. But from an other perspective - it is *not* neccessary
to have power control only when *all* consumers are in. For eg: we have
2 peripherals sharing one of the VAUX supplies. At this moment, both the
peripherals drivers are integrated with the regulator APIs; which means
the core handles most of the work regarding control. If, one of the
peripherals isnt included in the final configuration, still, IMO, it
*does* make sense that the other active peripheral optimally manage the
supply control; which is gauranteed by the core. IOW & IMO, a consumer
that hasnt hooked up to the regulator and thus is *aware* that it isnt
sourced can be safely assumed to be non-existent. 

Regards,
Sundar 
--
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/