rfkill API

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

Quoted 21 lines · Ben Greear

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;

Quoted 5 lines

?

Thanks,
Ben

Err, nevermind..looks like you can grub around in sysfs and find the phy, and from there, find the devices....

Quoted 22 lines · Ben Greear

Quoted 21 lines · Ben Greear

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;

Quoted 8 lines

Quoted 5 lines

?

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.

Quoted 36 lines · Dan Williams

Quoted 22 lines · Ben Greear

Quoted 21 lines · Ben Greear

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;

Quoted 8 lines

Quoted 5 lines

?

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.

Quoted 6 lines

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?