> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
