[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZbb=eO8YRtMn6hW0vn97PkHUo88e_o61DEC8=wPY3_PQ@mail.gmail.com>
Date: Wed, 22 Jan 2014 10:58:38 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Alexandre Courbot <gnurou@...il.com>
Cc: Arnd Bergmann <arnd@...db.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
netdev <netdev@...r.kernel.org>,
linux-wireless <linux-wireless@...r.kernel.org>,
linux-sunxi <linux-sunxi@...glegroups.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Chen-Yu Tsai <wens@...e.org>,
Johannes Berg <johannes@...solutions.net>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
"David S. Miller" <davem@...emloft.net>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot <gnurou@...il.com> wrote:
> The good (or bad, rather) thing about DT is that we can do whatever we
> please with the new bindings: decide which name or which index
> (doesn't matter here) a GPIO should have. However we don't have this
> control over ACPI, where nothing guarantees that the same index will
> be used for the same GPIO function.
It's not like ACPI will impose some tables on us and expect us to
use them as-is no matter how crazy they are. Then indeed the whole
idea of unifying ACPI and DT accessors would be moot and it would
only work by mistake or as a good joke.
The situation with ACPI is just like with DT, it is assumed that the
author of these tables also look at the Linux kernel drivers to figure
out what argument goes where and we can influence them.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists