devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Rob Herring <robh@kernel.org>, Paul Cercueil <paul@crapouillou.net>
Cc: "David S . Miller" <davem@davemloft.net>,
	Mark Rutland <mark.rutland@arm.com>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
	Maarten ter Huurne <maarten@treewalker.org>
Subject: Re: [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
Date: Mon, 02 Jan 2017 15:57:07 +0100	[thread overview]
Message-ID: <1483369027.21014.11.camel@sipsolutions.net> (raw)
In-Reply-To: <20161109182612.i4rnsdxulk5ghemz@rob-hp-laptop> (sfid-20161109_192614_527668_B4DB10FA)


> 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

      reply	other threads:[~2017-01-02 14:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-01 10:58 [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator Paul Cercueil
2016-11-01 10:58 ` [PATCH 2/2] net: rfkill-regulator: Add devicetree support Paul Cercueil
2016-11-09 18:26 ` [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator Rob Herring
2017-01-02 14:57   ` Johannes Berg [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=1483369027.21014.11.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=maarten@treewalker.org \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=paul@crapouillou.net \
    --cc=robh@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).