On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote: > Take the punit lock to stop others from accessing the punit while the > pmic i2c bus is in use. This is necessary because accessing the punit > from the kernel may result in the punit trying to access the pmic i2c > bus, which results in a hang when it happens while we own the pmic i2c > bus semaphore. > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > Tested-by: tagorereddy <tagore.chandan@xxxxxxxxx> > --- > drivers/i2c/busses/i2c-designware-baytrail.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c > b/drivers/i2c/busses/i2c-designware-baytrail.c > index 3effc9a..cf7a2a0 100644 > --- a/drivers/i2c/busses/i2c-designware-baytrail.c > +++ b/drivers/i2c/busses/i2c-designware-baytrail.c > > @@ -62,6 +62,8 @@ static void reset_semaphore(struct dw_i2c_dev *dev) > + iosf_mbi_punit_unlock(); > @@ -79,6 +81,8 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev > + iosf_mbi_punit_lock(); For me it looks a bit asymmetrical. Can we use acquire()/release()? -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
