All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Tony Lindgren <tony@atomide.com>,
	Enric Balletbo i Serra <eballetbo@gmail.com>,
	Lars Poeschel <poeschel@lemonage.de>,
	devicetree-discuss@lists.ozlabs.org,
	linux-omap <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe
Date: Wed, 17 Apr 2013 16:27:20 -0500	[thread overview]
Message-ID: <516F13B8.20601@ti.com> (raw)
In-Reply-To: <1366230852-2440-1-git-send-email-javier.martinez@collabora.co.uk>


On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
> The GPMC DT probe function use for_each_node_by_name() to search
> child device nodes of the GPMC controller. But this function does
> not use the GPMC device node as the root of the search and instead
> search across the complete Device Tree.
> 
> This means that any device node on the DT that is using any of the
> GPMC child nodes names searched for will be returned even if they
> are not connected to the GPMC, making the gpmc_probe_xxx_child()
> function to fail.
> 
> Fix this by using the GPMC device node as the search root so the
> search will be restricted to its children.
> 
> Reported-by: Lars Poeschel <poeschel@lemonage.de>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> 
> Changes since v1 (suggested by Jon Hunter):
>   - Split the search for GPMC child nodes and only warn if a
>     child probe fails on two different patches
>   - Don't probe all childs unnecesary if a previous matched
> 
>  arch/arm/mach-omap2/gpmc.c |   33 ++++++++++-----------------------
>  1 files changed, 10 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index ed946df..6166847 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1520,32 +1520,19 @@ 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_child_of_node(pdev->dev.of_node, child) {
>  
> -	for_each_node_by_name(child, "onenand") {
> -		ret = gpmc_probe_onenand_child(pdev, child);
> -		if (ret < 0) {
> -			of_node_put(child);
> -			return ret;
> -		}
> -	}
> +		if (!child->name)
> +			continue;
>  
> -	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, "nand") == 0)
> +			ret = gpmc_probe_nand_child(pdev, child);
> +		else if (of_node_cmp(child->name, "onenand") == 0)
> +			ret = gpmc_probe_onenand_child(pdev, child);
> +		else if (of_node_cmp(child->name, "ethernet") == 0 ||
> +			 of_node_cmp(child->name, "nor") == 0)
> +			ret = gpmc_probe_generic_child(pdev, child);
>  
> -	for_each_node_by_name(child, "ethernet") {
> -		ret = gpmc_probe_generic_child(pdev, child);
>  		if (ret < 0) {

I think that we need to make sure that "ret" is initialised to 0 at the
beginning of the function. We should not have a case where the child
name does not match but who knows. Actually that raises another point,
should we have an "else" clause at the end that WARNs on
"unknown/unsupported child" device?

>  			of_node_put(child);
>  			return ret;
> 

Otherwise looks great.

Cheers
Jon

  parent reply	other threads:[~2013-04-17 21:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-17 20:34 [PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe Javier Martinez Canillas
2013-04-17 20:34 ` [PATCH v2 2/2] ARM: OMAP2+: only WARN if a GPMC child probe function fail Javier Martinez Canillas
2013-04-17 21:27 ` Jon Hunter [this message]
2013-04-17 22:10   ` [PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe Javier Martinez Canillas
2013-04-17 22:33     ` Jon Hunter
2013-04-18  9:05       ` Javier Martinez Canillas

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=516F13B8.20601@ti.com \
    --to=jon-hunter@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=eballetbo@gmail.com \
    --cc=javier.martinez@collabora.co.uk \
    --cc=linux-omap@vger.kernel.org \
    --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 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.