Hi
On 02/09/2018 05:07 PM, Ben Gardner wrote:
I bisected the kernel to try to find where this broke, but the answer
I kept on getting didn't make any sense.
I think t was this commit:
4d6d5f1d08d2138dc43b28966eb6200e3db2e623 i2c: designware: fix rx fifo
depth tracking
> Of course, reverting that one commit didn't fix anything.
So I added a log to the dw_readl() and dw_writel() functions in both a
working and broken kernel and compared.
Yeah, it's not unusual that bisect diverts into wrong commit especially
with issues that don't reproduce easily or if some unrelated thing is
causing also failure at certain step leading to a wrong good/bad guess.
Can you test does reverting my guessed commit 2702ea7dbec5 ("i2c:
designware: wait for disable/enable only if necessary") fix it?
For linux-stable it is good info to know exactly the commit causing
regression and mark that in your changelog. It allows linux-stable folks
to apply fix to earlier kernels and know versions this fix will still
apply if cannot apply where regression was introduced. Fox example:
Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable
only if necessary")
Cc: linux-stable <stable@xxxxxxxxxxxxxxx> # 4.13+
--
Jarkko
