<div class="gmail_quote">2013/1/24 Wolfram Sang <span dir="ltr"><<a href="mailto:w.sang@pengutronix.de" target="_blank">w.sang@pengutronix.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Nov 07, 2012 at 11:44:37AM +0100, Jean Delvare wrote:<br>
> On Wed, 07 Nov 2012 15:58:26 +0530, Naveen Krishna Chatradhi wrote:<br>
> > Don't unmark the device as suspended until after it's been re-setup.<br>
> ><br>
> > The main race would be w.r.t. an i2c driver that gets resumed at the same<br>
> > time (asyncronously), that is allowed to do a transfer since suspended<br>
> > is set to 0 before reinit, but really should have seen the -EIO return<br>
> > instead.<br>
><br>
> I thought that the suspend order was children first and the resume<br>
> order was parent first?<br>
<br>
</div>Same here, why does it not work this way?<br></blockquote><div></div></div><br><div>Sorry for being quiet on this so far, I didn't notice the controversy until now.</div><div><br></div><div>This is actually about half of what the original fix was (which I wrote, thus my signed-off-by). The original one was related to us having the GPIO handshake for a shared bus (see separate discussions on how that should be upstreamed, and the work on that). For reference, that patch is at: <a href="https://gerrit.chromium.org/gerrit/#/c/28126/1/drivers/i2c/busses/i2c-s3c2410.c">https://gerrit.chromium.org/gerrit/#/c/28126/1/drivers/i2c/busses/i2c-s3c2410.c</a>.</div>
<div><br></div><div>So, I'm not sure that this patch is really needed. The significant part of the original one was the move of our internal s3c24xx_i2c_dt_gpio_free() below setting suspended = 1. Upstream implementation of the same functionality will be implemented differently, most likely.</div>
<div><br></div><div><br></div><div>-Olof</div>