Subject: Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
From: Rhyland Klein <rklein@nvidia.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "olof@lixom.net" <olof@lixom.net>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
In-Reply-To: <1305189092.3461.10.camel@jlt3.sipsolutions.net>
References: <1305159661-11982-1-git-send-email-rklein@nvidia.com>
	 <1305189092.3461.10.camel@jlt3.sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 12 May 2011 11:23:12 -0700
Message-ID: <1305224592.10961.10.camel@rklein-linux2>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1411
Lines: 36

On Thu, 2011-05-12 at 01:31 -0700, Johannes Berg wrote:
> On Wed, 2011-05-11 at 17:21 -0700, Rhyland Klein wrote:
> 
> > +enum rfkill_gpio_clk_state {
> > +	UNSPECIFIED = 0,
> > +	PWR_ENABLED,
> > +	PWR_DISABLED
> 
> Are you sure starting out with UNSPECIFIED works? Then you'll always
> change, but if the clock was enabled already you still enable it on the
> first set_block() from rfkill, which still has the refcount problem, no?
> It seems to me that the original state has to be passed in from the
> platform?
> 
> johannes
> 

I thought about that. But I decided the clock that it is possible to
have the clock used for the radio used for something else right? in
which case, the driver will leave the clk in whatever state it initially
finds it. I.e. if the clock is disabled, then it will enable it only
once and work, if it is enabled, it will add a refcount (only once) and
then work and disable it again only once. It never changes the refcount
in either direction by more than 1, and this way the initial setting of
the clock is irrelevant. The board files can simply initialize the block
as off if that is the initial clk state they want.

rhyland


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/