On Wed, May 10, 2023 at 05:17:04PM +0800, wangyouwan wrote:
> After waking up from sleep, 100% of the time it occurred. I suspected
> that there was a firmware issue with the machine I was debugging, but
> other machines did not notice it. Therefore, I attempted to make a
> modification here to avoid it
Okay then I suggest to investigate what causes the ->msgs to be NULL and
fix that. When the transfer function is called we expect there to be
something to be sent out so this should not happen.
Hi
On 5/10/23 12:23, Mika Westerberg wrote:
>
> On Wed, May 10, 2023 at 05:17:04PM +0800, wangyouwan wrote:
>> After waking up from sleep, 100% of the time it occurred. I suspected
>> that there was a firmware issue with the machine I was debugging, but
>> other machines did not notice it. Therefore, I attempted to make a
>> modification here to avoid it
>
> Okay then I suggest to investigate what causes the ->msgs to be NULL and
> fix that. When the transfer function is called we expect there to be
> something to be sent out so this should not happen.
Does you kernel include commit 301c8f5c32c8 ("i2c: designware: Fix
handling of real but unexpected device interrupts")? Vanilla kernels
after v6.1 have it and also linux-stable v5.15.75 and after.
I'm asking since issue sounds similar and wanted to clarify the kernel
version you are using.