Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1224383 > unrolled thread

Re: [PATCH 1/2] ASoC: qcom: change PTR_ERR argument

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] ASoC: qcom: change PTR_ERR argument Mark Brown <broonie@kernel.org> - 2015-09-14 20:10 +0200
    Re: [PATCH 1/2] ASoC: qcom: change PTR_ERR argument Julia Lawall <julia.lawall@lip6.fr> - 2015-09-17 10:50 +0200
    Re: [PATCH 1/2] ASoC: qcom: change PTR_ERR argument Julia Lawall <julia.lawall@lip6.fr> - 2015-09-17 10:50 +0200
      Re: [PATCH 1/2] ASoC: qcom: change PTR_ERR argument Mark Brown <broonie@kernel.org> - 2015-09-17 11:30 +0200

#1224383 — Re: [PATCH 1/2] ASoC: qcom: change PTR_ERR argument

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 30, 2015 at 08:05:10PM +0200, Julia Lawall wrote:
> Apply PTR_ERR to the value that was recently assigned.
> 
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)

I have no idea what's going on with this stuff without spending more
time than it looks like should need, there's a moderately big thread and
some patches posted in the middle of it.  Can you repost whatever the
current state is please?

[toc] | [next] | [standalone]

#1226771

Apply PTR_ERR to the value that was recently assigned.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x,y;
@@

if (IS_ERR(x) || ...) {
  ... when any
      when != IS_ERR(...)
(
   PTR_ERR(x)
|
*  PTR_ERR(y)
)
  ... when any
}
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>

---
 sound/soc/qcom/lpass-cpu.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 23f3d59..94beb99 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -438,7 +438,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
 		if (IS_ERR(drvdata->mi2s_bit_clk[dai_id])) {
 			dev_err(&pdev->dev,
 				"%s() error getting mi2s-bit-clk: %ld\n",
-				__func__, PTR_ERR(drvdata->mi2s_bit_clk[i]));
+				__func__,
+				PTR_ERR(drvdata->mi2s_bit_clk[dai_id]));
 			return PTR_ERR(drvdata->mi2s_bit_clk[dai_id]);
 		}
 	}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226772

On Mon, 14 Sep 2015, Mark Brown wrote:

> On Sun, Aug 30, 2015 at 08:05:10PM +0200, Julia Lawall wrote:
> > Apply PTR_ERR to the value that was recently assigned.
> >
> > The semantic match that finds this problem is as follows:
> > (http://coccinelle.lip6.fr/)
>
> I have no idea what's going on with this stuff without spending more
> time than it looks like should need, there's a moderately big thread and
> some patches posted in the middle of it.  Can you repost whatever the
> current state is please?

The discussion was about introducing a temporary variable to simplify the
code.  But that makes a lot of changes, so I think it would be better to
just apply the original bug fixing patch as is, and then the cleanup could
be applied on top of that.  I will submit the original patch again.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226800

[Multipart message — attachments visible in raw view] — view raw

On Thu, Sep 17, 2015 at 10:46:16AM +0200, Julia Lawall wrote:

> The discussion was about introducing a temporary variable to simplify the
> code.  But that makes a lot of changes, so I think it would be better to
> just apply the original bug fixing patch as is, and then the cleanup could
> be applied on top of that.  I will submit the original patch again.

OK, makes sense - thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web