From: Ivo van Doorn <ivdoorn@gmail.com>
To: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
ak@linux.intel.com, Len Brown <lenb@kernel.org>,
Richard Purdie <rpurdie@rpsys.net>,
Andrew Morton <akpm@linux-foundation.org>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Subject: Re: [RESEND] [PATCH -next 2/2] acpi,rfkill,backlight: comapl-laptop update - use rfkill switch subsystem
Date: Wed, 9 Jul 2008 23:57:27 +0200 [thread overview]
Message-ID: <200807092357.28013.IvDoorn@gmail.com> (raw)
In-Reply-To: <20080709234419.12d6eabc@debian>
On Wednesday 09 July 2008, Cezary Jackiewicz wrote:
> Dnia 2008-07-09, o godz. 23:33:01
> Ivo van Doorn <ivdoorn@gmail.com> napisał(a):
>
> > On Wednesday 09 July 2008, Cezary Jackiewicz wrote:
> > > From: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
> > >
> > > Remove unnecessary attributes, use rfkill switch subsystem.
> >
> > I'm missing a call to rfkill_force_state() to inform the rfkill subsystem that
> > the key has been toggled. This function should be called when the hardware
> > has raised the interrupt about the pressed event, or when the function
> > which polls the register notices the state change.
> >
> > As the patch works now, it means that the driver will only listen to
> > events coming from rfkill and it doen't provide any updates itself.
> >
> > Ivo
>
> Does calling rfkill_force_state () is mandatory? This driver implement
> get_state() hook, @state is always up-to-date.
It is not mandatory if you are writing rfkill support for a driver that does not
come with a rfkill switch. Such drivers can make use of the rfkill events produced
by the hardware which does have such a switch.
When the hardware does have the rfkill switch, then yes rfkill_force_state() is mandatory.
The get_state() callback function is optional, and allows rfkill to differentiate
between soft and hardblock.
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Ivo van Doorn <ivdoorn@gmail.com>
To: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
ak@linux.intel.com, Len Brown <lenb@kernel.org>,
Richard Purdie <rpurdie@rpsys.net>,
Andrew Morton <akpm@linux-foundation.org>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Subject: Re: [RESEND] [PATCH -next 2/2] acpi,rfkill,backlight: comapl-laptop update - use rfkill switch subsystem
Date: Wed, 9 Jul 2008 23:57:27 +0200 [thread overview]
Message-ID: <200807092357.28013.IvDoorn@gmail.com> (raw)
In-Reply-To: <20080709234419.12d6eabc@debian>
On Wednesday 09 July 2008, Cezary Jackiewicz wrote:
> Dnia 2008-07-09, o godz. 23:33:01
> Ivo van Doorn <ivdoorn@gmail.com> napisał(a):
>
> > On Wednesday 09 July 2008, Cezary Jackiewicz wrote:
> > > From: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
> > >
> > > Remove unnecessary attributes, use rfkill switch subsystem.
> >
> > I'm missing a call to rfkill_force_state() to inform the rfkill subsystem that
> > the key has been toggled. This function should be called when the hardware
> > has raised the interrupt about the pressed event, or when the function
> > which polls the register notices the state change.
> >
> > As the patch works now, it means that the driver will only listen to
> > events coming from rfkill and it doen't provide any updates itself.
> >
> > Ivo
>
> Does calling rfkill_force_state () is mandatory? This driver implement
> get_state() hook, @state is always up-to-date.
It is not mandatory if you are writing rfkill support for a driver that does not
come with a rfkill switch. Such drivers can make use of the rfkill events produced
by the hardware which does have such a switch.
When the hardware does have the rfkill switch, then yes rfkill_force_state() is mandatory.
The get_state() callback function is optional, and allows rfkill to differentiate
between soft and hardblock.
Ivo
next prev parent reply other threads:[~2008-07-09 21:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 21:10 [RESEND] [PATCH -next 2/2] acpi,rfkill,backlight: comapl-laptop update - use rfkill switch subsystem Cezary Jackiewicz
2008-07-09 21:33 ` Ivo van Doorn
2008-07-09 21:44 ` Cezary Jackiewicz
2008-07-09 21:44 ` Cezary Jackiewicz
2008-07-09 21:57 ` Ivo van Doorn [this message]
2008-07-09 21:57 ` Ivo van Doorn
2008-07-10 1:12 ` Henrique de Moraes Holschuh
2008-07-10 13:17 ` Ivo van Doorn
2008-07-10 13:29 ` Henrique de Moraes Holschuh
2008-07-10 1:07 ` Henrique de Moraes Holschuh
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=200807092357.28013.IvDoorn@gmail.com \
--to=ivdoorn@gmail.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=cezary.jackiewicz@gmail.com \
--cc=hmh@hmh.eng.br \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rpurdie@rpsys.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.