From: Jon Hunter <jon-hunter@ti.com>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Lars Poeschel <poeschel@lemonage.de>,
Benoit Cousson <b-cousson@ti.com>,
Tony Lindgren <tony@atomide.com>,
Grant Likely <grant.likely@secretlab.ca>,
Russell King <linux@arm.linux.org.uk>,
Enric Balletbo i Serra <eballetbo@gmail.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Date: Wed, 17 Apr 2013 13:33:07 -0500 [thread overview]
Message-ID: <516EEAE3.5060007@ti.com> (raw)
In-Reply-To: <516EACBB.9020607@collabora.co.uk>
On 04/17/2013 09:07 AM, Javier Martinez Canillas wrote:
> On 04/17/2013 03:48 PM, Jon Hunter wrote:
>>
>> On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
>>
>> ...
>>
>>> Yes, in fact I just realized that for_each_node_by_name() expand to:
>>>
>>> #define for_each_node_by_name(dn, name) \
>>> for (dn = of_find_node_by_name(NULL, name); dn; \
>>> dn = of_find_node_by_name(dn, name))
>>>
>>> which means that it will search for a node with "name" on the complete
>>> DeviceTree and this is wrong. It should only search on GPMC childs.
>>
>> Good catch. I guess we could have flash & ethernet devices connected to
>> other interfaces such as SPI.
>>
>
> Yes, in fact this is the case for omap4-sdp.dts which has an ethernet controller
> connected through SPI:
>
> &mcspi1 {
> eth@0 {
> compatible = "ks8851";
> spi-max-frequency = <24000000>;
> reg = <0>;
> interrupt-parent = <&gpio2>;
> interrupts = <2>; /* gpio line 34 */
> vdd-supply = <&vdd_eth>;
> };
> };
>
> it just didn't fail because the device node name is "eth" and not "ethernet".
Yes we got lucky here or unlucky as this would have tripped us up
earlier ;-)
> which makes me wonder if is OK to rely on a device node name or we should use
> compatible properties instead such as "ti,gpmc-{eth,nand,nor,onenand}" and do
> something like:
>
> for_each_compatible_node(pdev->dev.of_node, NULL, "ti,gpmc-eth") and so on.
Yes I was wondering about that too. However, it does seem simpler to
just search through the child devices and that would be an easier fix.
>>> Could you please test the following patch? If it works for you I'll add a proper
>>> description and submit it as a PATCH.
>>>
>>> Thanks a lot and best regards,
>>> Javier
>>>
>>> From d8dab9ae9a0284f17553875c2fddd806d9f6ab2e Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> Date: Wed, 17 Apr 2013 13:50:30 +0200
>>> Subject: [PATCH] ARM: OMAP2+: only search for GPMC DT child nodes on
>>> probe
>>>
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> ---
>>> arch/arm/mach-omap2/gpmc.c | 51 ++++++++++++++++++++-----------------------
>>> 1 files changed, 24 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>>> index ed946df..58e2415 100644
>>> --- a/arch/arm/mach-omap2/gpmc.c
>>> +++ b/arch/arm/mach-omap2/gpmc.c
>>> @@ -1520,35 +1520,32 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>>> return ret;
>>> }
>>>
>>> - for_each_node_by_name(child, "nand") {
>>> - ret = gpmc_probe_nand_child(pdev, child);
>>> - if (ret < 0) {
>>> - of_node_put(child);
>>> - return ret;
>>> - }
>>> - }
>>> -
>>> - for_each_node_by_name(child, "onenand") {
>>> - ret = gpmc_probe_onenand_child(pdev, child);
>>> - if (ret < 0) {
>>> - of_node_put(child);
>>> - return ret;
>>> - }
>>> - }
>>> + for_each_child_of_node(pdev->dev.of_node, child) {
>>> + if (child->name) {
>>
>> Minor nit ... how about ...
>>
>> + if (!child->name)
>> continue;
>>
>
> Yes, much better. I just cooked a quick patch so Lars could test it ;-)
>
>>> + if (of_node_cmp(child->name, "nand") == 0) {
>>> + ret = gpmc_probe_nand_child(pdev, child);
>>> + if (ret < 0) {
>>> + of_node_put(child);
>>> + return ret;
>>> + }
>>> + }
>>>
>>> - for_each_node_by_name(child, "nor") {
>>> - ret = gpmc_probe_generic_child(pdev, child);
>>> - if (ret < 0) {
>>> - of_node_put(child);
>>> - return ret;
>>> - }
>>> - }
>>> + if (of_node_cmp(child->name, "onenand") == 0) {
>>> + ret = gpmc_probe_onenand_child(pdev, child);
>>> + if (ret < 0) {
>>> + of_node_put(child);
>>> + return ret;
>>> + }
>>> + }
>>>
>>> - for_each_node_by_name(child, "ethernet") {
>>> - ret = gpmc_probe_generic_child(pdev, child);
>>> - if (ret < 0) {
>>> - of_node_put(child);
>>> - return ret;
>>> + if (of_node_cmp(child->name, "ethernet") == 0 ||
>>> + of_node_cmp(child->name, "nor") == 0) {
>>> + ret = gpmc_probe_generic_child(pdev, child);
>>> + if (ret < 0) {
>>> + of_node_put(child);
>>> + return ret;
>>> + }
>>> + }
>>> }
>>> }
>>
>> I am also wondering if the probe should fail if one of its children
>> fails. The panic that Lars reported occurred because the nand
>> successfully probed and so the nand device was registered, but because
>> the ethernet device probe failed, the gpmc probe fails, and then when
>> the nand device is probed by the mtd driver the kernel panics. I wonder
>> if it would be better to WARN on child devices that fail to probe but
>> not return error from the gpmc probe.
>>
>
> I wonder the same. Probably is better to just WARN so a user could at lest use
> some of the peripherals connected to the GPMC. This is specially important for
> flash memory devices since the rootfs could have to be mounted from there.
>
> Do you want me to split the child node search and the WARN_ON() replacement in
> two different patchs or should I send both changes in one patch?
Probably best to make these two separate patches as I think that will be
clearer.
Cheers
Jon
next prev parent reply other threads:[~2013-04-17 18:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 21:54 [PATCH v3 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes Javier Martinez Canillas
2013-03-15 15:24 ` Jon Hunter
2013-03-15 15:34 ` Jon Hunter
[not found] ` <1363298051-24574-1-git-send-email-javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2013-04-17 9:40 ` Lars Poeschel
2013-04-17 12:05 ` Javier Martinez Canillas
2013-04-17 13:48 ` Jon Hunter
2013-04-17 14:07 ` Javier Martinez Canillas
2013-04-17 18:33 ` Jon Hunter [this message]
2013-04-17 18:50 ` Javier Martinez Canillas
[not found] ` <516E9026.8070804-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2013-04-17 14:41 ` Lars Poeschel
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=516EEAE3.5060007@ti.com \
--to=jon-hunter@ti.com \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=eballetbo@gmail.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=grant.likely@secretlab.ca \
--cc=javier.martinez@collabora.co.uk \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=poeschel@lemonage.de \
--cc=tony@atomide.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).