[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160223204525.GC16961@amd>
Date: Tue, 23 Feb 2016 21:45:26 +0100
From: Pavel Machek <pavel@....cz>
To: João Paulo Rechi Vita <jprvita@...il.com>
Cc: Johannes Berg <johannes@...solutions.net>,
"David S. Miller" <davem@...emloft.net>,
Darren Hart <dvhart@...radead.org>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
platform-driver-x86@...r.kernel.org, linux-api@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux@...lessm.com,
João Paulo Rechi Vita
<jprvita@...lessm.com>
Subject: Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode
Hi!
[BTW you should probably Cc people responsible for LED subsystem...]
> Provide an interface for the airplane-mode indicator be controlled from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft". If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.
So... you add LED trigger to display the state of the airplane
mode. Ok, why not.
But now you add an way to override it? Why? If someone wants to change
the led state, he can just change trigger to none, and then control
the LED manually...
BTW what happens when the device contains both radios controlled by
kernel (wifi, bluetooth) and radios controlled by userspace (GSM
modem)?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Powered by blists - more mailing lists