Re: [PATCH] i2c: designware: Revert recent changes to i2c_dw_probe_lock_support()

[Kim Phillips <kim.phillips@amd.com>]

On 1/15/24 3:16 PM, Kim Phillips wrote:
> On 1/12/24 2:13 AM, Jarkko Nikula wrote:
>> Hi
> 
> Hi,
> 
>> On 1/11/24 19:56, Kim Phillips wrote:
>>>> [    6.245173] i2c_designware AMDI0010:00: Unknown Synopsys component type: 0xffffffff
>>
>> This has puzzled me all the time since I'm unable to see which one of Andy's patches could cause it. However controller is clearly powered down since DW_IC_COMP_TYPE register reads 0xffffffff.

Just FYI, that message is apparently 'normal' as, e.g., a stable v6.4
based tree emits it, but it doesn't crash because of it:

[    7.640335] usbcore: registered new device driver usb
[    7.663651] i2c_designware AMDI0010:00: Unknown Synopsys component type: 0xffffffff
[    7.677362] i2c_designware AMDI0010:01: Unknown Synopsys component type: 0xffffffff
[    7.738163] pps_core: LinuxPPS API ver. 1 registered

>> That I'd call as a regression one. Second regression is the Oops and I was speculating if commit bd466a892612 ("i2c: designware: Fix PM calls order in dw_i2c_plat_probe()") can cause it.

So I just tested checking out bd466a892612, and indeed it produces
the stacktrace.  Prior to that commit is v6.7-rc3, which boots fine.
So right now I'm suspecting bd466a892612 is to blame for the stacktrace.

Thanks,

Kim

>>> Hold on, I'm testing this on top of next-20240111 and still seeing the splat...
>>>
>> Btw, does this reproduce always? Can we be mislead if it happens somewhat randomly? Happens to boot once we revert some commits and then at another Andy's nearby commit does not and we make the wrong conclusion?
> 
> It's possible, yes, since we initially blamed commit 2f571a725434
> ("i2c: designware: Fix lock probe call order in dw_i2c_plat_probe()")
> and now testing this patch produces the failure: I'm pretty sure
> that those two boots were using the same exact kernel code base,
> yet one didn't produce the stacktrace, and the other did.
> 
> I've since updated my BIOS to the latest, and did a factory reset
> on both the host and BMC to try to be more stably reproducible, but
> we shall see.
> 
>> Does bisecting between v6.7-rc1 and next-20240111 lead anywhere?
> 
> Not really, unfortunately:
> 
> # bad: [9e21984d62c56a0f6d1fc6f76b646212cfd7fe88] Add linux-next specific files for 20240111
> # good: [b85ea95d086471afb4ad062012a4d73cd328fa86] Linux 6.7-rc1
> git bisect start 'next-20240111' 'v6.7-rc1'
> # good: [0e7cc4233dafe9474ab32825bda3a8fed92b08bb] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
> git bisect good 0e7cc4233dafe9474ab32825bda3a8fed92b08bb
> # bad: [627690dd85803b0ac9861751c663bad0d5ff6c1a] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git
> git bisect bad 627690dd85803b0ac9861751c663bad0d5ff6c1a
> # good: [cdf1b6bad35cbc1e2be672982cb0dc7825dafe14] Merge branch 'main' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
> git bisect good cdf1b6bad35cbc1e2be672982cb0dc7825dafe14
> # good: [04194a4f780895799cf83c86d5bb8bc11560a536] drm/xe: Fix lockdep warning from xe_vm_madvise
> git bisect good 04194a4f780895799cf83c86d5bb8bc11560a536
> # good: [b6e1b708176846248c87318786d22465ac96dd2c] drm/xe: Remove uninitialized variable from warning
> git bisect good b6e1b708176846248c87318786d22465ac96dd2c
> # good: [0f35b0a7b8fa402adbffa2565047cdcc4c480153] Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole"
> git bisect good 0f35b0a7b8fa402adbffa2565047cdcc4c480153
> # good: [d4ca26ac4be0d9aea7005c40df75e6775749671b] drm/msm/dp: call dp_display_get_next_bridge() during probe
> git bisect good d4ca26ac4be0d9aea7005c40df75e6775749671b
> # good: [6aaff21547a08e5a151fbf7a3f7be5a68877d9e3] Merge tag 'drm-intel-next-2023-12-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
> git bisect good 6aaff21547a08e5a151fbf7a3f7be5a68877d9e3
> # good: [3c064aea46d071ccf95a142be5532768a7fa6f02] Merge tag 'drm-misc-next-fixes-2024-01-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
> git bisect good 3c064aea46d071ccf95a142be5532768a7fa6f02
> # good: [b76c01f1d950425924ee1c1377760de3c024ef78] Merge tag 'drm-intel-gt-next-2023-12-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
> git bisect good b76c01f1d950425924ee1c1377760de3c024ef78
> # good: [f48705f473cea37efeeaa6a197ae12730c112863] Bluetooth: Remove HCI_POWER_OFF_TIMEOUT
> git bisect good f48705f473cea37efeeaa6a197ae12730c112863
> # good: [7974b2128489d062c9d21419633eebde07f07032] Bluetooth: hci_event: Fix wrongly recorded wakeup BD_ADDR
> git bisect good 7974b2128489d062c9d21419633eebde07f07032
> # good: [f8c47ee39e6dc6170da06865b84e8c8b08e87ab0] Bluetooth: hci_event: Use HCI error defines instead of magic values
> git bisect good f8c47ee39e6dc6170da06865b84e8c8b08e87ab0
> # good: [ba0bc076e90fa6ae1284fc0b34d7460531c45ab7] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
> git bisect good ba0bc076e90fa6ae1284fc0b34d7460531c45ab7
> # first bad commit: [627690dd85803b0ac9861751c663bad0d5ff6c1a] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git
> 
> Let me know if there are other ideas, otherwise I'll wait for the
> series with the rearranged series from Andy.
> 
> Thanks,
> 
> Kim