From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: corentincj@iksaif.net, Woody Suwalski <woodys@xandros.com>,
Sitsofe Wheeler <sits@sucs.org>,
acpi4asus-user@lists.sourceforge.net,
linux-acpi <linux-acpi@vger.kernel.org>
Subject: Re: Is rfkill class really appropriate for eeepc-laptop?
Date: Fri, 26 Sep 2008 15:17:41 +0100 [thread overview]
Message-ID: <20080926141741.GA6671@srcf.ucam.org> (raw)
In-Reply-To: <48DCEE58.5060004@tuffmail.co.uk>
On Fri, Sep 26, 2008 at 03:14:48PM +0100, Alan Jenkins wrote:
> Matthew Garrett wrote:
> > No, it's to use allow the OS to control whatever mechanism the platform
> > provides for making the radio stop transmitting. The fact that this is,
> > uh, "interestingly" implemented on the Eee doesn't alter that.
>
> So rfkill should be allowed to mean "entire PCI device goes away,
> network interface will vanish" - just so long as it comes back correctly
> when re-enabled :-).
Sure, if that's how the platform implements it. This is how almost every
bluetooth rfkill interface works, so applications should be able to
cope.
> > We should just sort out the hotplug code...
> >
>
> Ok. I have a little knowledge, I'll see if I can be dangerous. My real
> question was, is it safe to merge your rfkill support before this is
> sorted out?
I don't see why not. It works on various versions of the eee, and unless
anything actually pokes it people can carry on using their bizarro
userspace scripts. I'm working with the PCI guys on handling the hotplug
case sanely. It may be possible to special case this in eeepc-laptop,
though I'd prefer a more generic solution.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2008-09-26 14:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080918133144.GA4338@silver.sucs.org>
[not found] ` <48D564A8.7030009@xandros.com>
[not found] ` <20080921102246.GA27071@silver.sucs.org>
[not found] ` <48D660C5.6070204@xandros.com>
[not found] ` <48D69052.1040908@tuffmail.co.uk>
[not found] ` <48D6AC5E.70502@xandros.com>
2008-09-26 13:49 ` Is rfkill class really appropriate for eeepc-laptop? Alan Jenkins
2008-09-26 13:55 ` Matthew Garrett
2008-09-26 14:14 ` Alan Jenkins
2008-09-26 14:17 ` Matthew Garrett [this message]
2008-09-26 16:48 ` 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=20080926141741.GA6671@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=acpi4asus-user@lists.sourceforge.net \
--cc=alan-jenkins@tuffmail.co.uk \
--cc=corentincj@iksaif.net \
--cc=linux-acpi@vger.kernel.org \
--cc=sits@sucs.org \
--cc=woodys@xandros.com \
/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