| 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
| ||
|
Date: Thu, 5 Jan 2012 06:06:46 +0000 From: Mark Brown <broonie@...nsource.wolfsonmicro.com> To: Laxman Dewangan <ldewangan@...dia.com> Cc: Laxman Dewangan <ldewangan.com@...dia.com>, "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. On Wed, Jan 04, 2012 at 11:49:14AM +0530, Laxman Dewangan wrote: > > 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. > 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. You're not quite getting my point here - we should be treating this as an error and complaining about it when we notice it, your patch will silently mask the condition which seems likely to just cause the bug to manifest elsewhere. -- 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