Hi,
On 12-01-17 19:45, Wolfram Sang wrote:
On Sun, Jan 08, 2017 at 02:44:23PM +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>
I don't think the I2C patches need to go via I2C tree, so:
Acked-by: Wolfram Sang <wsa@xxxxxxxxxxxxx>
Note that as mentioned in the cover-letter, these 2 i2c patches depend
on these:
https://patchwork.ozlabs.org/patch/710067/
https://patchwork.ozlabs.org/patch/710068/
https://patchwork.ozlabs.org/patch/710069/
https://patchwork.ozlabs.org/patch/710070/
https://patchwork.ozlabs.org/patch/710071/
https://patchwork.ozlabs.org/patch/710072/
Which all have many reviews / acks. Given the race between i915
and designware-i2c opened up by the last patch in this series
these not having been merged yet is a good thing, but patch 1-5
are ready for merging.
So Wolfram, what is the plan with these ? As said they are necessary
for the 2 i2c patches in this patch-set, so do you want the
entire set of 8 i2c patches to go through an other tree to avoid
inter tree dependencies ?
And if so, can we then have you're Acked-by for the 6 above too ?
Regards,
Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
