* [PATCH] i2c: mxs: Fix misuse init_completion
@ 2012-11-21 5:19 Marek Vasut
[not found] ` <1353475146-28669-1-git-send-email-marex-ynQEQJNshbs@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Marek Vasut @ 2012-11-21 5:19 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: Marek Vasut, Fabio Estevam, Shawn Guo, Wolfram Sang
The init_completion() call does reinit not only the variable carrying
the flag that the completion finished, but also initialized the
waitqueue associated with the completion. On the contrary, the
INIT_COMPLETION() call only reinits the flag.
In case there was anything still stuck in the waitqueue, subsequent call
to init_completion() would be able to create possible race condition. This
patch uses the proper function and moves init_completion() into .probe() call
of the driver, to be issued only once.
Note that such scenario is impossible, since two threads can never enter the
mxs_i2c_xfer_msg(), since whole this section is protected by mutex in I2C core.
This by no means allows this issue to exit though.
Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
Cc: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
drivers/i2c/busses/i2c-mxs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 6ed53da..47d5d53 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -316,7 +316,7 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg,
if (msg->len == 0)
return -EINVAL;
- init_completion(&i2c->cmd_complete);
+ INIT_COMPLETION(i2c->cmd_complete);
i2c->cmd_err = 0;
ret = mxs_i2c_dma_setup_xfer(adap, msg, flags);
@@ -473,6 +473,8 @@ static int __devinit mxs_i2c_probe(struct platform_device *pdev)
i2c->dev = dev;
i2c->speed = &mxs_i2c_95kHz_config;
+ init_completion(&i2c->cmd_complete);
+
if (dev->of_node) {
err = mxs_i2c_get_ofdata(i2c);
if (err)
--
1.7.10.4
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] i2c: mxs: Fix misuse init_completion
[not found] ` <1353475146-28669-1-git-send-email-marex-ynQEQJNshbs@public.gmane.org>
@ 2013-01-21 3:47 ` Marek Vasut
[not found] ` <201301210447.46939.marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Marek Vasut @ 2013-01-21 3:47 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA; +Cc: Fabio Estevam, Shawn Guo, Wolfram Sang
Hi,
> The init_completion() call does reinit not only the variable carrying
> the flag that the completion finished, but also initialized the
> waitqueue associated with the completion. On the contrary, the
> INIT_COMPLETION() call only reinits the flag.
>
> In case there was anything still stuck in the waitqueue, subsequent call
> to init_completion() would be able to create possible race condition. This
> patch uses the proper function and moves init_completion() into .probe()
> call of the driver, to be issued only once.
>
> Note that such scenario is impossible, since two threads can never enter
> the mxs_i2c_xfer_msg(), since whole this section is protected by mutex in
> I2C core. This by no means allows this issue to exit though.
>
> Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Why is this not applied / not in stable please?
Also, what about the other MXS I2C patches?
Thanks!
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] i2c: mxs: Fix misuse init_completion
[not found] ` <201301210447.46939.marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2013-01-23 9:55 ` Wolfram Sang
0 siblings, 0 replies; 3+ messages in thread
From: Wolfram Sang @ 2013-01-23 9:55 UTC (permalink / raw)
To: Marek Vasut; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, Fabio Estevam, Shawn Guo
> > The init_completion() call does reinit not only the variable carrying
> > the flag that the completion finished, but also initialized the
> > waitqueue associated with the completion. On the contrary, the
> > INIT_COMPLETION() call only reinits the flag.
> >
> > In case there was anything still stuck in the waitqueue, subsequent call
> > to init_completion() would be able to create possible race condition. This
> > patch uses the proper function and moves init_completion() into .probe()
> > call of the driver, to be issued only once.
> >
> > Note that such scenario is impossible, since two threads can never enter
> > the mxs_i2c_xfer_msg(), since whole this section is protected by mutex in
> > I2C core. This by no means allows this issue to exit though.
> >
> > Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
> > Cc: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > Cc: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> Why is this not applied / not in stable please?
Thanks, applied. It will go to 3.8 but not to stable, since it is not
really a bugfix as you also mentioned.
> Also, what about the other MXS I2C patches?
Pending, obviously. New next branch probably this weekend.
Thanks,
Wolfram
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-01-23 9:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-21 5:19 [PATCH] i2c: mxs: Fix misuse init_completion Marek Vasut
[not found] ` <1353475146-28669-1-git-send-email-marex-ynQEQJNshbs@public.gmane.org>
2013-01-21 3:47 ` Marek Vasut
[not found] ` <201301210447.46939.marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-23 9:55 ` Wolfram Sang
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).