linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Ben Greear <greearb@candelatech.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: rfkill API
Date: Thu, 10 Feb 2011 12:21:26 -0600	[thread overview]
Message-ID: <1297362087.17161.7.camel@dcbw.foobar.com> (raw)
In-Reply-To: <4D4AFACC.3080603@candelatech.com>

On Thu, 2011-02-03 at 10:58 -0800, Ben Greear wrote:
> On 02/03/2011 10:42 AM, Dan Williams wrote:
> > On Tue, 2011-02-01 at 20:51 -0800, Ben Greear wrote:
> >> On 02/01/2011 08:35 PM, Ben Greear wrote:
> >>> Hello!
> >>>
> >>> I was looking at using one rfkill socket in wpa_supplicant, instead
> >>> of one per vif.
> >>>
> >>> Current wpa_supplicant code seems to treat the API as if there is only
> >>> as single rfkill object for the entire kernel. I would assume that
> >>> instead different NICs could have different rfkill status.
> >>>
> >>> Is there any way to coorelate a netdevice (or devices)
> >>> to the rfkill->idx in the
> >>>
> >>> struct rfkill_event {
> >>> u32 idx;
> >>> u8 type;
> >>> u8 op;
> >>> u8 soft;
> >>> u8 hard;
> >>> } STRUCT_PACKED;
> >>>
> >>>
> >>> ?
> >>>
> >>> Thanks,
> >>> Ben
> >>>
> >>
> >> Err, nevermind..looks like you can grub around in sysfs and find the phy,
> >> and from there, find the devices....
> >
> > Remember about platform devices.  An rfkill device is not always
> > associated with a netdevice, and sometimes platform rfkill devices can
> > block the netdevice rfkill.
> >
> > So, if you have a laptop with a BIOS rfkill switch, setting that rfkill
> > switch "softblocked" will hardblock the netdevice rfkill device.  Thus
> > you cannot unblock the netdevice rfkill until you unblock the
> > platform/BIOS device rfkill.
> >
> > Yes, this sucks.
> 
> I tried to make my patch treat anything that wasn't specifically a phy
> as 'all'..but likely it could still use some work.  I'll send it to the
> list for review/suggestions..in case you have the time.
> 
> Is there any specific way to tell if an rfkill device is a platform
> device?
> 
> For the platform rfkill blocking the netdevice rfkill:  Is this something
> that must be done in software (ie, supplicant), or is that already handled
> by the kernel/drivers/hardware?

It's something usually done in hardware/BIOS.  On my laptop (HP 2530p),
the iwlagn phy killswitch will be hardblocked when the BIOS switch (a
physical button) is flipped.  The BIOS presumably tells the EC to toggle
the 5350's rfkill GPIO or something.  So when I hit the laptop
killswitch, I get:

hpwmi - softblocked
iwlagn - hardblocked

and no amount of "rfkill unblock" will make the iwlagn switch change.  I
must first unblock the hpwmi switch, which then magically unblocks the
iwlagn one.  Yay.

This is the case with most of the platform devices I've seen from
mainstream vendors.

Dan



      reply	other threads:[~2011-02-10 18:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-02  4:35 rfkill API Ben Greear
2011-02-02  4:51 ` Ben Greear
2011-02-03 18:42   ` Dan Williams
2011-02-03 18:58     ` Ben Greear
2011-02-10 18:21       ` Dan Williams [this message]

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=1297362087.17161.7.camel@dcbw.foobar.com \
    --to=dcbw@redhat.com \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    /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).