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?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
