[systemd-devel] [BUG] too many rfkill services

[Marcel Holtmann]

Hi Lennart,

>> That's normal behavior in the case of a platform rfkill device and a
>> device-specific rfkill device.  The platform rfkill functionality can
>> sometimes (often?) cut power to the device through BIOS and GPIOs, and
>> it will drop off the USB or PCI bus.  But the device itself can also
>> expose rfkill functionality through it's own drivers, that doesn't cause
>> it to drop off the bus.  This is your case with the USB-based Bluetooth
>> device and the BIOS-based platform killswitch.
>> 
>> Since the routing of all these rfkills is highly model specific, there
>> is no way to know that the platform rfkill has an affect on any other
>> device in a generic way.  That would have to be hardcoded into the
>> kernel and would be pretty awful to maintain.
> 
> Hmm, so, currently we include the rfkill device name in the filename
> we store in disk (combined with ID_PATH if it is known). For an rfkill
> device that comes and goes and each time changes its name this
> filename will not be stable. 
> 
> Is there any way how we can get some stable ID out of these devices,
> in a way that allows multiple rfkill devices per USB device/interface?
> I don't see how without kernel change.
> 
> If rfkill devices shall be reliably recognizable, then we need some
> kind of sub-USB device stability...

actual individual RFKILL switch control is not something that anybody should store anywhere. We support it via /dev/rfkill, but it is not something you can rely on. As you have seen the RFKILL switches can come and go and be re-enumerated at it.

For this specific reason we have introduced the RFKILL_OP_CHANGE_ALL where you can either switch on/off all RFKILL switches (comparable to flight mode setting) or where you can switch on/off a specific type of switch (bluetooth, wlan, nfc etc.).

What is important that for example Bluetooth comes back up as it is suppose to. So if you do a CHANGE_ALL Bluetooth on, then you would expect to come back after suspend and reboot the same way.

So the proper way is record the change all states and keep them. And bring them back after suspend and resume. That is pretty much how ConnMan does it actually since it works on a per technology basis and not individual devices.

Of course with this handling a few RFKILL switches will fail to be restored as they were, because people messed with individual switches. There is nothing much you can do about that. Getting a unique RFKILL switch id is really hard. It relies on that your parent exposes a serial number or something really unique that makes it persistent over reboot. And all the platform RFKILL switches are just plain terrible since in most cases we pull some out of the ACPI magic or worse some vendor magic.

Regards

Marcel