linux-kernel - RE: [PATCH] regulator: Rail is said to be enable only if this and supply rails are enabled.

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]

Date:	Wed, 4 Jan 2012 11:49:14 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Laxman Dewangan <ldewangan.com@...dia.com>
CC:	"lrg@...com" <lrg@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: RE: [PATCH] regulator: Rail is said to be enable only if this and
 supply rails are enabled.

> From: Mark Brown [mailto:broonie@...nsource.wolfsonmicro.com]
> Sent: Wednesday, January 04, 2012 1:46 AM +0530
> >
> > The given rail is said to be enabled only if this rail is eanbled
> > along with supply rail.
> > Adding check for the supply rail whether it is enabled or not when
> > query about rail enabled.
> 
> This feels wrong - the code in general assumes that the parents will all
> be enabled for an enabled child (and does the required stuff on enable
> and disable).  Doing the check isn't unreasonable but if it fails we
> really ought to be complaining loudly as we're probably confused and
> things might be going wrong elsewhere.
>
Yes, in general checking of the parent rail is not really required but it is
good to have on safer side because it directly checks at the interface of
regulator level rather than the ref count and give the more correct results.

I came to this issue when I set the supply regulator for a rail and set the rail
is always on but the supply regulator was not always on. And so this function
returns true but actually the rail is not enabled because supply rail was not enabled.
Although it is fixed in other patch but such checks help more.

> We should also look at the bootstrapping code, we're not really making
> much effort to verify that the hardware configuration on boot is sane
> (though realistically it's unlikely that it won't be).
> 
> > Signed-off-by: Laxman Dewangan <ldewangan@...dia.com>
> > ---
> > When consumer of any rails query about whether rail is enabled
> > or not, the function regulator_is_enabled() should return enabled
> > only if this rail and supply rail (both) are enabled.
> > if any one of rail, whether the given rail or supply rail, is enabled
> > then function should return as not enabled.
> 
> Please just put things in the changelog if they're useful.

I already send the 2nd patch for putting this info on changelog.

Thanks,
Laxman
--
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/