From: Johannes Berg <johannes@sipsolutions.net>
To: John Linville <linville@tuxdriver.com>
Cc: Thiemo Nagel <thiemo.nagel@ph.tum.de>,
Corentin Chary <corentin.chary@gmail.com>,
debian-eeepc-devel@lists.alioth.debian.org,
acpi4asus-user@lists.sourceforge.net,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Darren Salt <linux@youmustbejoking.demon.co.uk>
Subject: [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again
Date: Fri, 10 Jul 2009 21:41:39 +0200 [thread overview]
Message-ID: <1247254899.21972.9.camel@johannes.local> (raw)
In-Reply-To: <507E3B9268%linux@youmustbejoking.demon.co.uk>
Apparently there actually _are_ tools that try to set
this in sysfs even though it wasn't supposed to be used
this way without claiming first. Guess what: now that
I've cleaned it all up it doesn't matter and we can
simply allow setting the soft-block state in sysfs.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
*shrug*, I don't like it, but whatever...
Please test & report.
net/rfkill/core.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
--- wireless-testing.orig/net/rfkill/core.c 2009-07-10 21:29:10.000000000 +0200
+++ wireless-testing/net/rfkill/core.c 2009-07-10 21:36:31.000000000 +0200
@@ -648,15 +648,26 @@ static ssize_t rfkill_state_store(struct
struct device_attribute *attr,
const char *buf, size_t count)
{
- /*
- * The intention was that userspace can only take control over
- * a given device when/if rfkill-input doesn't control it due
- * to user_claim. Since user_claim is currently unsupported,
- * we never support changing the state from userspace -- this
- * can be implemented again later.
- */
+ struct rfkill *rfkill = to_rfkill(dev);
+ unsigned long state;
+ int err;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ err = strict_strtoul(buf, 0, &state);
+ if (err)
+ return err;
+
+ if (state != RFKILL_USER_STATE_SOFT_BLOCKED &&
+ state != RFKILL_USER_STATE_UNBLOCKED)
+ return -EINVAL;
+
+ mutex_lock(&rfkill_global_mutex);
+ rfkill_set_block(rfkill, state == RFKILL_USER_STATE_SOFT_BLOCKED);
+ mutex_unlock(&rfkill_global_mutex);
- return -EPERM;
+ return err ?: count;
}
static ssize_t rfkill_claim_show(struct device *dev,
next prev parent reply other threads:[~2009-07-10 19:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A5716AA.5000903@ph.tum.de>
[not found] ` <71cd59b00907100545v6f440a19xfc3668826eb1e509@mail.gmail.com>
[not found] ` <4A5743AB.6090303@ph.tum.de>
[not found] ` <71cd59b00907100646h5e0283fcyce5874cc4a19106b@mail.gmail.com>
[not found] ` <4A575119.9070505@ph.tum.de>
2009-07-10 18:57 ` [2.6.31-rc2] Writing to /sys/class/rfkill/*/state fails Darren Salt
2009-07-10 19:34 ` Corentin Chary
2009-07-10 19:37 ` Marcel Holtmann
2009-07-10 19:41 ` Johannes Berg [this message]
2009-07-10 21:09 ` [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again Darren Salt
2009-07-10 21:55 ` Johannes Berg
2009-07-10 23:09 ` Darren Salt
2009-07-25 20:56 ` [Acpi4asus-user] " Rafael J. Wysocki
2009-07-25 22:35 ` John W. Linville
2009-07-26 19:32 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1247254899.21972.9.camel@johannes.local \
--to=johannes@sipsolutions.net \
--cc=acpi4asus-user@lists.sourceforge.net \
--cc=corentin.chary@gmail.com \
--cc=debian-eeepc-devel@lists.alioth.debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@youmustbejoking.demon.co.uk \
--cc=linville@tuxdriver.com \
--cc=thiemo.nagel@ph.tum.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®