> My understanding is it is generally felt that using the regulator > enable GPIO commonly found on WiFi chips for rfkill is an abuse of > rfkill as it is more that just an RF disable. From a DT standpoint, > this seems like creating a binding for what a Linux driver wants. > Instead, I think this should be either a GPIO or GPIO regulator and > the driver for the WiFi chip should decide whether or not to register > that as an rfkill driver. Sadly, there are two ways to use rfkill right now: 1) the more common, and correct, way of having rfkill be a control tied to a specific wireless interface (wifi, BT, FM, GPS, NFC, ...), to both report the hardware button state that might be tied to it, and to control - centrally - the software state. 2) the platform way, which some ACPI based platforms do, which register an rfkill instance, which often allows controlling in software the hardware line that then toggles the hardware rfkill on the WiFi NIC. It's not clear to me what this patch is trying to achieve. It seems a bit like something else entirely, which would be using it to toggle the power for a wifi device? I agree that doesn't seem appropriate, and instead the driver could bind to the regulator and disable it when wifi gets disabled (by rfkill or simply by taking all interfaces down.) In fact, given that there are no in-tree users, I'm tempted to remove the rfkill-regulator entirely. Thoughts? 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
