From: Marc Dietrich <marvin24@gmx.de>
To: Olof Johansson <olof@lixom.net>
Cc: Rhyland Klein <rklein@nvidia.com>,
Marc Dietrich <marvin24@gmx.de>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Stephen Warren <swarren@nvidia.com>,
Colin Cross <ccross@android.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"John W. Linville" <linville@tuxdriver.com>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH 1/3] net: rfkill-gpio: add device tree support
Date: Tue, 14 Feb 2012 11:14:58 +0100 [thread overview]
Message-ID: <4F3A3422.7020304@gmx.de> (raw)
In-Reply-To: <CAOesGMgJW7bRZn84VSZNVvc3G6z4S6HPzFEv3MJ8DcNYVsV2uQ@mail.gmail.com>
Am 13.02.2012 20:36, schrieb Olof Johansson:
> On Mon, Feb 13, 2012 at 11:25 AM, Rhyland Klein<rklein@nvidia.com> wrote:
>> On Sun, 2012-02-12 at 11:13 -0800, Marc Dietrich wrote:
>>> This adds device tree support for rfkill-gpio. The optional platform
>>> paramters gpio_runtime_close and gpio_runtime_setup are not implemented.
>>>
>>> Cc: linux-wireless@vger.kernel.org
>>> Cc: "John W. Linville"<linville@tuxdriver.com>
>>> Cc: Johannes Berg<johannes@sipsolutions.net>
>>> Cc: Rhyland Klein<rklein@nvidia.com>
>>> Signed-off-by: Marc Dietrich<marvin24@gmx.de>
>>> +
>>> static int rfkill_gpio_probe(struct platform_device *pdev)
>>> {
>>> struct rfkill_gpio_data *rfkill;
>>> struct rfkill_gpio_platform_data *pdata = pdev->dev.platform_data;
>>> + struct device_node *np = pdev->dev.of_node;
>>> int ret = 0;
>>> int len = 0;
>>>
>>> + if (np)
>>> + pdata = rfkill_gpio_parse_pdata(pdev);
>>> +
>> The only concern I have is the precedence of devicetree settings vs
>> platform data settings? If there is pdata passed in from board file
>> initialization, and there is a device tree (a corner case but I think a
>> valid one) then I believe the order would be that defined pdata would
>> override the devicetree settings. That way if someone wanted to make a
>> quick update, they wouldn't need to change the boot loader as well.
> Yes, that is how other drivers tend to be coded -- only of pdata is
> null will the driver try to fill in from the DT.
If the device tree from the bootloader does not contain the rfkill
information the resources from platform_data will be used (so no need to
update the bootloader). If the bootloader contains rfkill information,
why shouldn't it be used?
Marc
next prev parent reply other threads:[~2012-02-14 10:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-12 19:13 [PATCH 1/3] net: rfkill-gpio: add device tree support Marc Dietrich
2012-02-12 19:13 ` [PATCH 2/3] dt: rfkill-gpio: add bindings documentation Marc Dietrich
2012-02-12 20:21 ` Simon Glass
2012-02-13 13:47 ` Rob Herring
2012-02-13 19:43 ` Olof Johansson
2012-02-14 10:12 ` Marc Dietrich
2012-02-16 10:29 ` Marc Dietrich
2012-02-13 19:25 ` [PATCH 1/3] net: rfkill-gpio: add device tree support Rhyland Klein
2012-02-13 19:36 ` Olof Johansson
2012-02-14 10:14 ` Marc Dietrich [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-02-05 17:18 Marc Dietrich
2012-02-05 19:59 ` Thierry Reding
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=4F3A3422.7020304@gmx.de \
--to=marvin24@gmx.de \
--cc=ccross@android.com \
--cc=johannes@sipsolutions.net \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=olof@lixom.net \
--cc=rklein@nvidia.com \
--cc=swarren@nvidia.com \
/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).