linux-kernel - Re: [PATCH] rfkill: Regulator consumer driver for rfkill

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: <20110406141131.GC2810@opensource.wolfsonmicro.com>
Date:	Wed, 6 Apr 2011 23:11:33 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Antonio Ospite <ospite@...denti.unina.it>
Cc:	linux-wireless@...r.kernel.org, openezx-devel@...ts.openezx.org,
	"John W . Linville" <linville@...driver.com>,
	Johannes Berg <johannes@...solutions.net>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	linux-kernel@...r.kernel.org, Marek Vasut <marek.vasut@...il.com>,
	Guiming Zhuo <gmzhuo@...il.com>
Subject: Re: [PATCH] rfkill: Regulator consumer driver for rfkill

On Wed, Apr 06, 2011 at 11:21:19AM +0200, Antonio Ospite wrote:

> +	tristate "Generic rfkill regulator driver"
> +	depends on RFKILL || !RFKILL

That looks *odd*.  Otherwise this looks fine from a regulator API point
of view.  You use an exclusive get() so you could get away without
remembering the enable state as nothing else could hold the device open
but there's no harm in doing so and it's defensive against silly
constraints that force the regulator on.
--
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/