Hi Joao,
> For platform drivers to be able to correctly drive the "Airplane Mode"
> indicative LED there needs to be a RFKill LED trigger tied to the global
> state of RFKILL_TYPE_ALL (instead of to a specific RFKill) and that
> works in an inverted manner of regular RFKill LED triggers, that is, the
> LED is ON when the state is blocked, and OFF otherwise.
>
> This commit implements such a trigger, which will be used by the
> asus-wireless x86 platform driver.
>
> Signed-off-by: João Paulo Rechi Vita <jprv...@endlessm.com>
> ---
> net/rfkill/core.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index b41e9ea..3effc29 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -124,6 +124,26 @@ static bool rfkill_epo_lock_active;
>
>
> #ifdef CONFIG_RFKILL_LEDS
> +static void airplane_mode_led_trigger_activate(struct led_classdev *led);
> +
> +static struct led_trigger airplane_mode_led_trigger = {
> + .name = "rfkill-airplane-mode",
> + .activate = airplane_mode_led_trigger_activate,
> +};
so I am not convinced the kernel should have the concept of airplane mode at
all. It is kinda of a term that keeps changing since airlines do now allow WiFi
and Bluetooth short range transmissions during flight. We stayed away from
calling it airplane mode since by the nature of it being governed by local
regulations it will change over time.
The RFKILL subsystem got away with not labeling it by just saying
RFKILL_CHANGE_ALL and if we want a trigger for that action we better find a
more general term to describe the fact that all RF devices are shut off.
Keep in mind that even with airplane mode on, you can re-activate Bluetooth and
WiFi these days. So while you are in airplane mode, then RFKILL switches for
these two technologies can be taken back off. If we wanted to model that in the
kernel we would be putting policy in the kernel and I think that is a bad idea.
That is pretty much the main reason why ConnMan never tried to push the
information about flight mode back into the kernel. It is not a policy that the
kernel can determine in the first place.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
