Re: rfkill guidance

[Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]

> Today we already have all the platform rfkill instances (like the
> various ACPI ones) that don't live off a device that they control,
> but instead control the platform's radio functionality. And in some
> cases, that actually has very similar behaviour to what was proposed
> in the previous patch, and what you're looking for, in that it
> sometimes kills power to BT or WiFi chips when soft-disabled (or
> kicks them off the bus in some other way).

Actually, let me retract that a bit. Obviously they *do* control a
device or radio, but we don't actually know which one. And that can
actually become a problem, since we don't even know how they work etc.

So IOW, even with the ACPI stuff, there's no real "platform rfkill"
concept - it's always killing a specific radio.

There used to be some rfkill that was just reflecting the button state,
but I think we got rid of that in favour of reflecting button state
through hid/input, if it doesn't also control a radio.

So, actually, the more I think about it the more I agree with Mark's
objection. It doesn't really make sense to have a concept of an rfkill
and not know what radio it controls.

In your particular case, Jon, it's complicated by the fact that you
don't want to bind a kernel driver with the rfkill, not sure where
you'd get a device to tie the rfkill to then.

johannes
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html