linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	"David S. Miller" <davem@davemloft.net>,
	Chen-Yu Tsai <wens@csie.org>, Rhyland Klein <rklein@nvidia.com>,
	Marc Dietrich <marvin24@gmx.de>, Arnd Bergmann <arnd@arndb.de>,
	Alexandre Courbot <gnurou@gmail.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCHv2 3/5] net: rfkill: gpio: remove gpio names
Date: Wed, 5 Mar 2014 09:43:16 +0800	[thread overview]
Message-ID: <CACRpkdZF4-rWs1WkOp3t0x77fgSCE71E=wdrxiDuGZ8eBu_p_Q@mail.gmail.com> (raw)
In-Reply-To: <530D218E.9010007@wwwdotorg.org>

On Wed, Feb 26, 2014 at 7:04 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:

>> -     gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0);
>> +     gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
>
> I think the correct fix here is to look up the GPIO by name rather than
> by index, but simply hard-code the name rather than generating it with
> sprintf(). Index lookups are hard to expand compatibly, but named-based
> lookups scale much better.
>
> In other words, I rather specifically disagree with using a plain
> "gpios" property in any future DT binding, but would strongly prefer
> e.g. reset-gpios/shutdown-gpios or gpios/gpio-names.

If I understand the situation correctly it's like ACPI does not have named
GPIOs so keeping specifying this in DT GPIO bindings is counter-productive
to the work of abstracting the access to GPIO handlers so that drivers
need not know whether ACPI or DT is used for describing the hardware.

We could do worse. Like putting the GPIOs in a differently indexed order
in DT vs ACPI.

I have no strong opinion really, I just see that people doing DT and ACPI
HW descriptions need to cooperate if they want to share infrastructure
or we have to give up that pipe dream and let each HW description
method have its own unique probe()-runpath. Which would be the result
in this driver if we persist on using named GPIOs.

Yours,
Linus Walleij

  reply	other threads:[~2014-03-05  1:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25 12:22 [PATCHv2 0/5] net: rfkill: gpio: cleanup and a few new acpi ids Heikki Krogerus
2014-02-25 12:22 ` [PATCHv2 1/5] ARM: tegra: remove obsolete gpio entries Heikki Krogerus
2014-02-25 13:06   ` Marc Dietrich
2014-02-25 15:15   ` Johannes Berg
2014-02-25 23:00   ` Stephen Warren
2014-02-25 12:22 ` [PATCHv2 2/5] net: rfkill: gpio: remove unused and obsolete platform parameters Heikki Krogerus
2014-02-25 12:22 ` [PATCHv2 3/5] net: rfkill: gpio: remove gpio names Heikki Krogerus
2014-02-25 23:04   ` Stephen Warren
2014-03-05  1:43     ` Linus Walleij [this message]
2014-03-05  2:18       ` Stephen Warren
2014-03-05  2:37         ` Linus Walleij
2014-03-05  2:59           ` Stephen Warren
2014-03-07  3:41             ` Linus Walleij
2014-03-07  3:43               ` Chen-Yu Tsai
2014-03-07  4:22                 ` Stephen Warren
2014-02-25 12:22 ` [PATCHv2 4/5] net: rfkill: gpio: add ACPI ID for GPS module on Lenove Miix2 Heikki Krogerus
2014-02-25 16:40   ` Sergei Shtylyov
2014-02-27 10:55     ` Heikki Krogerus
2014-02-27 11:22       ` [PATCHv3 4/5] net: rfkill: gpio: add ACPI ID for GPS module on Lenovo Miix2 Heikki Krogerus
2014-02-25 12:22 ` [PATCHv2 5/5] net: rfkill: gpio: add ACPI IDs for a Broadcom bluetooth chip Heikki Krogerus
2014-02-25 15:11 ` [PATCHv2 0/5] net: rfkill: gpio: cleanup and a few new acpi ids Johannes Berg
2014-02-25 17:59   ` Marcel Holtmann

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='CACRpkdZF4-rWs1WkOp3t0x77fgSCE71E=wdrxiDuGZ8eBu_p_Q@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=gnurou@gmail.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marvin24@gmx.de \
    --cc=netdev@vger.kernel.org \
    --cc=rklein@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    --cc=wens@csie.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).