From: Marcel Holtmann <marcel@holtmann.org>
To: Florian Mickler <florian@mickler.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org,
Randy Dunlap <rdunlap@xenotime.net>,
"John W. Linville" <linville@tuxdriver.com>,
Alan Jenkins <alan-jenkins@tuffmail.co.uk>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [PATCH 2/2] enhance /sys/class/rfkill/<rfkill>/state interface
Date: Sun, 21 Feb 2010 11:07:35 +0100 [thread overview]
Message-ID: <1266746855.18491.0.camel@violet> (raw)
In-Reply-To: <20100221000716.29ad3e90@schatten.dmk.lab>
Hi Florian,
> > > Introduce a new state-value RFKILL_STATE_SOFT_AND_HARD_BLOCKED
> > > which is returned only through the sysfs state file.
> > > The other interfaces are designed so that they don't need this extra
> > > state.
> > >
> > > This allows the sysfs to represent all possible states an rfkill
> > > driver can
> > > have.
> > >
> > > Signed-off-by: Florian Mickler <florian@mickler.org>
> > > ---
> > >
> > > After stumbling over this arbitrary limitation of
> > > sys/class/rfkill/*/state I
> > > wondered what would hinder this patch?
> >
> > This is not backward compatible, so can't be done.
> >
> > johannes
>
> hmm... ah, i see... if driver is in hard'n'soft-block state
> an userspace program would expect to read hardblock instead of the
> new hard'n'softblock-state...
> now that i think of it, it even becomes obvious :)
a userspace program would be expected to use /dev/rfkill and do this
properly. Don't bother with sysfs at all.
Regards
Marcel
prev parent reply other threads:[~2010-02-21 10:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-20 21:40 [PATCH 0/2] Document and enhance rfkill sysfs abi florian
2010-02-20 21:40 ` [PATCH 1/2] Document the rfkill sysfs ABI florian
2010-02-20 22:19 ` Johannes Berg
2010-02-21 10:08 ` Marcel Holtmann
2010-02-21 11:21 ` Florian Mickler
2010-02-22 15:00 ` John W. Linville
2010-02-22 15:17 ` Johannes Berg
2010-02-22 18:16 ` Marcel Holtmann
2010-02-24 11:05 ` [PATCH v2 0/2] Document and enhance rfkill sysfs abi florian
2010-02-24 11:05 ` [PATCH v2 1/2] Document the rfkill sysfs ABI florian
2010-02-24 11:05 ` [PATCH v2 2/2] enhance sysfs rfkill interface florian
2010-02-25 23:35 ` Henrique de Moraes Holschuh
2010-02-26 11:01 ` florian
2010-02-26 11:01 ` [PATCH v3] " florian
2010-02-26 13:11 ` [PATCH v2 2/2] " Marcel Holtmann
2010-02-26 16:32 ` Florian Mickler
2010-02-20 21:40 ` [PATCH 2/2] enhance /sys/class/rfkill/<rfkill>/state interface florian
2010-02-20 22:14 ` Johannes Berg
2010-02-20 23:07 ` Florian Mickler
2010-02-21 10:07 ` Marcel Holtmann [this message]
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=1266746855.18491.0.camel@violet \
--to=marcel@holtmann.org \
--cc=alan-jenkins@tuffmail.co.uk \
--cc=florian@mickler.org \
--cc=gregkh@suse.de \
--cc=johannes@sipsolutions.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=rdunlap@xenotime.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.