From: Jiang Qiu <qiujiang@huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
linuxarm@huawei.com, haifeng.wei@huawei.com,
charles.chenxin@huawei.com
Subject: Re: [PATCH v3 1/2] gpio: designware: switch device node to fwnode
Date: Sat, 27 Feb 2016 15:15:40 +0800 [thread overview]
Message-ID: <56D14D1C.6090706@huawei.com> (raw)
In-Reply-To: <CAHp75Vecxx+YBrZ9d4oZzqS_X3cxUQ4UaSvjqjhuaoJ4O9xauw@mail.gmail.com>
在 2016/2/25 21:43, Andy Shevchenko 写道:
> On Thu, Feb 25, 2016 at 1:58 PM, Jiang Qiu <qiujiang@huawei.com> wrote:
>> 在 2016/2/24 21:46, Andy Shevchenko 写道:
>>> On Wed, Feb 24, 2016 at 2:33 PM, qiujiang <qiujiang@huawei.com> wrote:
>
>>> - why do you use fwnode_*() instead of device_property_*() calls?
>>> What prevents us to move to device property API directly?
>> Yes, it looks more reasonable by using devce_property. Howerver,
>> device_get_child_node_count was used here to find each child node. This
>> API output the fwnode_handle for each child node directly, but device
>> property APIs need 'dev' data instead. Actually, the effects of fwnode_*()
>> and device_*() are the same. So, I used fwnode_*() APIs here.
>
> Right, looks okay then.
>
>>>> - node = dev->of_node;
>>>> - if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
>>>> + if (!IS_ENABLED(CONFIG_OF_GPIO) || !(dev->of_node))
>>>> return ERR_PTR(-ENODEV);
>>>
>>> So, since you converted to fwnode, do you still need this check?
>>>
>> Although this patch coverted device node to fwnode, only DTs binding was
>> supported here, and patch2 support ACPI will remove this check.
>
> Yes, but like I said below device_get_child_node_count() will take
> care of that, will it?
Right, device_get_child_node_count() will take of it, this should be removed.
>
>>>>
>>>> - nports = of_get_child_count(node);
>>>> + nports = device_get_child_node_count(dev);
>>>> if (nports == 0)
>>>> return ERR_PTR(-ENODEV);
>>>
>>> ...I think this one fail if it will not found any child.
>> This one fail? yes, it will return to failure.
>> I am not very clear here.
>
> See above.
Here, device_get_child_node_count will return ZERO if there is not any child.
So, I think this will work ok, will it?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jiang Qiu <qiujiang@huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
<linuxarm@huawei.com>, <haifeng.wei@huawei.com>,
<charles.chenxin@huawei.com>
Subject: Re: [PATCH v3 1/2] gpio: designware: switch device node to fwnode
Date: Sat, 27 Feb 2016 15:15:40 +0800 [thread overview]
Message-ID: <56D14D1C.6090706@huawei.com> (raw)
In-Reply-To: <CAHp75Vecxx+YBrZ9d4oZzqS_X3cxUQ4UaSvjqjhuaoJ4O9xauw@mail.gmail.com>
在 2016/2/25 21:43, Andy Shevchenko 写道:
> On Thu, Feb 25, 2016 at 1:58 PM, Jiang Qiu <qiujiang@huawei.com> wrote:
>> 在 2016/2/24 21:46, Andy Shevchenko 写道:
>>> On Wed, Feb 24, 2016 at 2:33 PM, qiujiang <qiujiang@huawei.com> wrote:
>
>>> - why do you use fwnode_*() instead of device_property_*() calls?
>>> What prevents us to move to device property API directly?
>> Yes, it looks more reasonable by using devce_property. Howerver,
>> device_get_child_node_count was used here to find each child node. This
>> API output the fwnode_handle for each child node directly, but device
>> property APIs need 'dev' data instead. Actually, the effects of fwnode_*()
>> and device_*() are the same. So, I used fwnode_*() APIs here.
>
> Right, looks okay then.
>
>>>> - node = dev->of_node;
>>>> - if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
>>>> + if (!IS_ENABLED(CONFIG_OF_GPIO) || !(dev->of_node))
>>>> return ERR_PTR(-ENODEV);
>>>
>>> So, since you converted to fwnode, do you still need this check?
>>>
>> Although this patch coverted device node to fwnode, only DTs binding was
>> supported here, and patch2 support ACPI will remove this check.
>
> Yes, but like I said below device_get_child_node_count() will take
> care of that, will it?
Right, device_get_child_node_count() will take of it, this should be removed.
>
>>>>
>>>> - nports = of_get_child_count(node);
>>>> + nports = device_get_child_node_count(dev);
>>>> if (nports == 0)
>>>> return ERR_PTR(-ENODEV);
>>>
>>> ...I think this one fail if it will not found any child.
>> This one fail? yes, it will return to failure.
>> I am not very clear here.
>
> See above.
Here, device_get_child_node_count will return ZERO if there is not any child.
So, I think this will work ok, will it?
>
next prev parent reply other threads:[~2016-02-27 7:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 12:33 [PATCH v3 0/2] gpio: designware: add gpio-signaled acpi events support for power button qiujiang
2016-02-24 12:33 ` qiujiang
2016-02-24 12:33 ` [PATCH v3 1/2] gpio: designware: switch device node to fwnode qiujiang
2016-02-24 12:33 ` qiujiang
2016-02-24 13:46 ` Andy Shevchenko
2016-02-25 11:58 ` Jiang Qiu
2016-02-25 11:58 ` Jiang Qiu
2016-02-25 13:43 ` Andy Shevchenko
2016-02-25 13:43 ` Andy Shevchenko
2016-02-27 7:15 ` Jiang Qiu [this message]
2016-02-27 7:15 ` Jiang Qiu
2016-02-29 10:46 ` Andy Shevchenko
2016-02-24 12:33 ` [PATCH v3 2/2] gpio: designware: add gpio-signaled acpi events support for power button qiujiang
2016-02-24 12:33 ` qiujiang
2016-02-24 13:49 ` Andy Shevchenko
2016-02-25 12:13 ` Jiang Qiu
2016-02-25 12:13 ` Jiang Qiu
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=56D14D1C.6090706@huawei.com \
--to=qiujiang@huawei.com \
--cc=andy.shevchenko@gmail.com \
--cc=charles.chenxin@huawei.com \
--cc=gnurou@gmail.com \
--cc=haifeng.wei@huawei.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mika.westerberg@linux.intel.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 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.