suspend fails - previous kernel works

The bug propagates through all kernel updates up to 5.0.0-36. I still stuck with 5.0.0-29.

Meanwhile and additionally I tried some BIOS updates from Lenovo without luck. The last BIOS update was o4dj* from 10.2019.

I've done some effort to get more information about the bug.

1. BIOS updates with the Lenovo tools are a bit confusing. I still stuck at the BIOS Version O3TKT46A from 07/21/2019. I've opened a support thread at https://forums.lenovo.com/t5/Lenovo-Desktop-Towers/V530-15ARR-Desktop-Tower-BIOS-update-confusion/td-p/4636769 .

2. I've recognized a difference in behavior since kernel 5.3.0-28-generic #30~18.04.1-Ubuntu: Wehn I put the computer into suspend it first does something like a kernel oops with
* RIP: 0010:irq_startup+0xe1/0x100
and after that it shows a few lines later
* PM: suspend_common(): xhci_pci_suspend+0x0/0xd0 returns -110
* PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -110
* PM: dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -110
* PM: Device 0000:04:00.4 failed to suspend async: error -110
* PM: Some devices failed to suspend, or early wake event detected
then it follows endless repeating kernel oops with
* RIP: 0010:dcn10_verify_allow_pstate_change_high+0x37/0x2d0 [amdgpu]

I've attached the snippet of the journalctl output.

Then I compared to the behavior with the kernel 5.0.0-29-generic #31~18.04.1-Ubuntu with the proper suspend behavior from a user's view. There the computer also shows the kernel oops with
* RIP: 0010:irq_startup+0xe1/0xf0
but i ends with a proper suspend.

I've attached the snippet of this suspend, too.

I think the bug is related to https://lkml.org/lkml/2019/11/4/13 since the CPU of my computer is a Raven Ridge model.

If there is a kernel available with the patch applied I'm willing to test the patch.

I verified my guess through providing a kernel parameter at startup
  xhci-hcd.quirks=0x00020000

where the bit set is along xhci.h:
  #define XHCI_SLOW_SUSPEND BIT_ULL(17)

This quirk provide nearly the same as the patch mentioned in #5.

With kernel 5.3.0-28 and this parameter set the machine suspended without complaining :-) Unfortunately it did not resume :-(

With kernel 5.0.0-37 and this parameter set the machine suspended and resumed without complaining.

Since I misused the kernel parameter this maybe a side effect. If not it is a previously covered bug. This will be a new game.

Again: If there is a kernel available with the patch applied I'm willing to test the patch.

With kernel 5.3.0-40 for me the suspend problem is solved. Still I face a resume problem. But that is another game.