linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH v2] net: rfkill: add generic gpio rfkill driver
Date: Thu, 12 May 2011 11:23:12 -0700	[thread overview]
Message-ID: <1305224592.10961.10.camel@rklein-linux2> (raw)
In-Reply-To: <1305189092.3461.10.camel@jlt3.sipsolutions.net>

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




  reply	other threads:[~2011-05-12 18:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-12  0:21 [PATCH v2] net: rfkill: add generic gpio rfkill driver Rhyland Klein
2011-05-12  8:31 ` Johannes Berg
2011-05-12 18:23   ` Rhyland Klein [this message]
2011-05-12 18:40     ` Johannes Berg
2011-05-12 18:52       ` Rhyland Klein
2011-05-12 19:02         ` Johannes Berg
2011-05-12 21:23           ` Rhyland Klein
2011-05-13  7:15             ` Johannes Berg
2011-05-13 19:02               ` Rhyland Klein
2011-05-13 19:20                 ` John W. Linville
2011-05-13 20:11                   ` John W. Linville
2011-05-16 18:13                     ` wireless-next-2.6 rebased -- " John W. Linville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1305224592.10961.10.camel@rklein-linux2 \
    --to=rklein@nvidia.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=olof@lixom.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).