All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 3/3] clk: keystone: Fix missing iounmap calls in an error handling path
Date: Fri, 28 Oct 2016 00:19:08 +0000	[thread overview]
Message-ID: <20161028001908.GL26139@codeaurora.org> (raw)
In-Reply-To: <7ed7c1abf1666f1e6eda240bb705940bc14bd186.1477339880.git.christophe.jaillet@wanadoo.fr>

On 10/26, walter harms wrote:
> 
> 
> Am 25.10.2016 22:35, schrieb Stephen Boyd:
> > On 10/25, walter harms wrote:
> >> Am 24.10.2016 22:43, schrieb Christophe JAILLET:
> >>> @@ -220,6 +218,12 @@ static void __init _of_pll_clk_init(struct device_node *node, bool pllctrl)
> >>>  
> >>>  out:
> >>>  	pr_err("%s: error initializing pll %s\n", __func__, node->name);
> >>> +	if (pll_data->pllm)
> >>> +		iounmap(pll_data->pllm);
> >>> +	if (pll_data->pll_ctl0)
> >>> +		iounmap(pll_data->pll_ctl0);
> >>> +	if (pll_data->pllod)
> >>> +		iounmap(pll_data->pllod);
> >>>  	kfree(pll_data);
> >>>  }
> >>>  
> >>
> >> IMHO calles the iounmap() need no check for NULL.
> >>
> > 
> > ARM doesn't seem to check for NULL there though. So that would be
> > a bug.
> > 
> > It would be nice to remove the checks though. Perhaps someone
> > could do that by unifying ionumap into asm-generic with the NULL
> > check and then have architecture specific functions for the rest
> > of it?
> > 
> 
> Is there a specific reason not to check ?
> It seems not wise to have different behavior across architectures.
> 

I have no idea. Patches welcome.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

      parent reply	other threads:[~2016-10-28  0:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 20:43 [PATCH 0/3] clk: keystone: Fix some error handling paths Christophe JAILLET
2016-10-24 20:43 ` Christophe JAILLET
2016-10-24 20:43 ` [PATCH 1/3] clk: keystone: Fix an error checking Christophe JAILLET
2016-10-24 20:43   ` Christophe JAILLET
2016-11-02  0:22   ` Stephen Boyd
2016-11-02  0:22     ` Stephen Boyd
2016-11-04  5:43     ` Christophe JAILLET
2016-11-04  5:43       ` Christophe JAILLET
2016-10-24 20:43 ` [PATCH 2/3] clk: keystone: Fix some error messages Christophe JAILLET
2016-10-24 20:43   ` Christophe JAILLET
2016-10-24 20:43 ` [PATCH 3/3] clk: keystone: Fix missing iounmap calls in an error handling path Christophe JAILLET
2016-10-24 20:43   ` Christophe JAILLET
2016-10-25  7:08   ` walter harms
2016-10-25  7:08     ` walter harms
2016-10-25 20:35     ` Stephen Boyd
2016-10-25 20:35       ` Stephen Boyd
2016-10-26 12:14   ` walter harms
2016-10-28  0:19   ` Stephen Boyd [this message]

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=20161028001908.GL26139@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=kernel-janitors@vger.kernel.org \
    /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.