All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Cc: andrew@lunn.ch, jg1.han@samsung.com,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	computersforpeace@gmail.com, dwmw2@infradead.org
Subject: Re: [PATCH] mtd: orion_nand: fix error code path in probe
Date: Tue, 14 Oct 2014 23:35:03 +0200	[thread overview]
Message-ID: <20141014213503.GD5331@lunn.ch> (raw)
In-Reply-To: <1413296198-29486-1-git-send-email-michael.opdenacker@free-electrons.com>

On Tue, Oct 14, 2014 at 04:16:38PM +0200, Michael Opdenacker wrote:
> This replaces kzalloc() and ioremap() calls by
> the corresponding devm_ functions in the probe() routine,
> which automatically release the corresponding resources
> when probe() fails or when the device is removed.
> 
> This simplifies the error management code and
> fixes a bug reported by "make coccicheck":
> 
> if "board = devm_kzalloc()" fails, the probe()
> function jumps incorrectly to label "no_res" and
> therefore returns without running "iounmap()"
> 
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
> ---
>  drivers/mtd/nand/orion_nand.c | 28 +++++++++-------------------
>  1 file changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> index 471b4df3a5ac..a9c2bde16c25 100644
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -19,7 +19,7 @@
>  #include <linux/mtd/partitions.h>
>  #include <linux/clk.h>
>  #include <linux/err.h>
> -#include <asm/io.h>
> +#include <linux/io.h>
>  #include <asm/sizes.h>
>  #include <linux/platform_data/mtd-orion_nand.h>
>  
> @@ -85,32 +85,30 @@ static int __init orion_nand_probe(struct platform_device *pdev)
>  	int ret = 0;
>  	u32 val = 0;
>  
> -	nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info), GFP_KERNEL);
> +	nc = devm_kzalloc(&pdev->dev,
> +			sizeof(struct nand_chip) + sizeof(struct mtd_info),
> +			GFP_KERNEL);
>  	if (!nc) {
> -		ret = -ENOMEM;
> -		goto no_res;
> +		return -ENOMEM;
>  	}
>  	mtd = (struct mtd_info *)(nc + 1);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res) {
> -		ret = -ENODEV;
> -		goto no_res;
> +		return -ENODEV;
>  	}
>  
> -	io_base = ioremap(res->start, resource_size(res));
> +	io_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
>  	if (!io_base) {
>  		dev_err(&pdev->dev, "ioremap failed\n");
> -		ret = -EIO;
> -		goto no_res;
> +		return -EIO;
>  	}

Hi Michael

It is quite a common pattern to use:

        res = platform_get_resource(dev, IORESOURCE_MEM, 0);
        c->membase = devm_ioremap_resource(&dev->dev, res);
        if (IS_ERR(c->membase))
	   return PTR_ERR(c->membase)

which is more compact.

>  
>  	if (pdev->dev.of_node) {
>  		board = devm_kzalloc(&pdev->dev, sizeof(struct orion_nand_data),
>  					GFP_KERNEL);
>  		if (!board) {
> -			ret = -ENOMEM;
> -			goto no_res;
> +			return -ENOMEM;
>  		}

Doesn't this now break the coding style? No need to have the {} since
it is a single statement.

   Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Cc: dwmw2@infradead.org, computersforpeace@gmail.com,
	jg1.han@samsung.com, andrew@lunn.ch,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: orion_nand: fix error code path in probe
Date: Tue, 14 Oct 2014 23:35:03 +0200	[thread overview]
Message-ID: <20141014213503.GD5331@lunn.ch> (raw)
In-Reply-To: <1413296198-29486-1-git-send-email-michael.opdenacker@free-electrons.com>

On Tue, Oct 14, 2014 at 04:16:38PM +0200, Michael Opdenacker wrote:
> This replaces kzalloc() and ioremap() calls by
> the corresponding devm_ functions in the probe() routine,
> which automatically release the corresponding resources
> when probe() fails or when the device is removed.
> 
> This simplifies the error management code and
> fixes a bug reported by "make coccicheck":
> 
> if "board = devm_kzalloc()" fails, the probe()
> function jumps incorrectly to label "no_res" and
> therefore returns without running "iounmap()"
> 
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
> ---
>  drivers/mtd/nand/orion_nand.c | 28 +++++++++-------------------
>  1 file changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
> index 471b4df3a5ac..a9c2bde16c25 100644
> --- a/drivers/mtd/nand/orion_nand.c
> +++ b/drivers/mtd/nand/orion_nand.c
> @@ -19,7 +19,7 @@
>  #include <linux/mtd/partitions.h>
>  #include <linux/clk.h>
>  #include <linux/err.h>
> -#include <asm/io.h>
> +#include <linux/io.h>
>  #include <asm/sizes.h>
>  #include <linux/platform_data/mtd-orion_nand.h>
>  
> @@ -85,32 +85,30 @@ static int __init orion_nand_probe(struct platform_device *pdev)
>  	int ret = 0;
>  	u32 val = 0;
>  
> -	nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info), GFP_KERNEL);
> +	nc = devm_kzalloc(&pdev->dev,
> +			sizeof(struct nand_chip) + sizeof(struct mtd_info),
> +			GFP_KERNEL);
>  	if (!nc) {
> -		ret = -ENOMEM;
> -		goto no_res;
> +		return -ENOMEM;
>  	}
>  	mtd = (struct mtd_info *)(nc + 1);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res) {
> -		ret = -ENODEV;
> -		goto no_res;
> +		return -ENODEV;
>  	}
>  
> -	io_base = ioremap(res->start, resource_size(res));
> +	io_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
>  	if (!io_base) {
>  		dev_err(&pdev->dev, "ioremap failed\n");
> -		ret = -EIO;
> -		goto no_res;
> +		return -EIO;
>  	}

Hi Michael

It is quite a common pattern to use:

        res = platform_get_resource(dev, IORESOURCE_MEM, 0);
        c->membase = devm_ioremap_resource(&dev->dev, res);
        if (IS_ERR(c->membase))
	   return PTR_ERR(c->membase)

which is more compact.

>  
>  	if (pdev->dev.of_node) {
>  		board = devm_kzalloc(&pdev->dev, sizeof(struct orion_nand_data),
>  					GFP_KERNEL);
>  		if (!board) {
> -			ret = -ENOMEM;
> -			goto no_res;
> +			return -ENOMEM;
>  		}

Doesn't this now break the coding style? No need to have the {} since
it is a single statement.

   Andrew

  reply	other threads:[~2014-10-14 21:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14 14:16 [PATCH] mtd: orion_nand: fix error code path in probe Michael Opdenacker
2014-10-14 14:16 ` Michael Opdenacker
2014-10-14 21:35 ` Andrew Lunn [this message]
2014-10-14 21:35   ` Andrew Lunn
2014-10-15 21:39   ` Ezequiel Garcia
2014-10-15 21:39     ` Ezequiel Garcia
2014-10-16  4:43     ` Michael Opdenacker
2014-10-16  4:43       ` Michael Opdenacker
2014-10-16  4:58       ` [PATCH v2] " Michael Opdenacker
2014-10-16  4:58         ` Michael Opdenacker
2014-10-16  7:39         ` Jingoo Han
2014-10-16  7:39           ` Jingoo Han
2014-10-18 19:35         ` Andrew Lunn
2014-10-18 19:35           ` Andrew Lunn
2014-10-22  8:49         ` Brian Norris
2014-10-22  8:49           ` Brian Norris
2014-10-16  5:06   ` [PATCH] " Michael Opdenacker
2014-10-16  5:06     ` Michael Opdenacker

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=20141014213503.GD5331@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=jg1.han@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael.opdenacker@free-electrons.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.