Hi All,
Background
----------
While testing some i2c-hid touchscreen suspend/resume fixes I hit a bug
on a Peaq C1010 2-in-1 where it would not come back from resume with a
4.19-rc2 kernel.
After some debugging this turns out to be the same issue as which I fixed
with commit 9d9a152ebaa8 ("i2c: designware: Re-init controllers with
pm_disabled set on resume"):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d9a152ebaa8
It turns out that in some cases we need to re-init the I2C controller for
the i2c bus to the PMIC which is shared with the SoC's PUNIT earlier then
we do now.
I guess this is due to some _PS0 method needing it and running before the
resume_early method of the I2C controller, but this is hard to debug since
before the fix the machine simply reboots on resume without any logs.
We could play some tricks with ACPI's _DEP method which we normally ignore,
as was done in commit e6ce0ce34f65 ("ACPI / LPSS: Add device link for CHT
SD card dependency on I2C") but there are a number of reasons why I've not
chosen that approach:
1) I don't know for which device to add a link in this case
2) This has the risk of quickly becoming a game of whack-a-mole where we
add more and more device links
3) This will not help devices where _DEP is not properly reporting a dep
on the shared I2C bus
Instead this patch fixes things by moving the re-init of the I2C controller
for the shared bus to a resume_noirq handler. Normally that would not be
a good idea, but in this case the controller is kept alive over suspend/
resume so we can talk to it from the noirq handler without problems.
On which branch should this be merged?
--------------------------------------
As the commit message mentions this is a fix to the fix from commit
9d9a152ebaa8, which would make this material for i2c/for-current and
eventually adding to 4.18.y, etc.
But this all is only a problem if BYT/CHT devices with the shared bus
can actually reach S0ix states and since commit f11fc4bc669b ("ACPI / LPSS:
Force LPSS quirks on boot") we are back to the same state as a couple
of weeks ago where this never happens. I've send out a fix for the LPSS
quirk handling to make these devices reach S0ix states again, but that
is not necessarily fixes / 4.18.y material. So for now I think this patch
should go to i2c/for-next.
If the ACPI LPSS fix making it possible to reach S0ix states gets merged
as a fix, then we need to backport this patch. Note it will not apply
cleanly on 4.18.y / 4.19 unless the following 2 patches are cherry-picked
first:
https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next&id=1732c22abca8f4e2528a4927baf6ffb2e3be58b0
https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next&id=9cbeeca05049b1109e7e445369898b8a88d5ea7b
I think that that probably is the best solution since these are not that
invasive / risky and otherwise we get a merge conflict.
But this all is theoretical as I do not really expect the ACPI LPSS fix
to go to fixes / 4.18.y .
Regards,
Hans
