On 13.03.22 19:33, James Turner wrote:
My understanding at this point is that the root problem is probably
not in the Linux kernel but rather something else (e.g. the machine
firmware or AMD Windows driver) and that the change in f9b7f3703ff9
("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)") simply
exposed the underlying problem.
FWIW: that in the end is irrelevant when it comes to the Linux kernel's
'no regressions' rule. For details see:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/admin-guide/reporting-regressions.rst
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/process/handling-regressions.rst
That being said: sometimes for the greater good it's better to not
insist on that. And I guess that might be the case here.
I'm not sure where to go from here. This issue isn't much of a concern
for me anymore, since blacklisting `amdgpu` works for my machine. At
this point, my understanding is that the root problem needs to be fixed
in AMD's Windows GPU driver or Dell's firmware, not the Linux kernel. If
any of the AMD developers on this thread would like to forward it to the
AMD Windows driver team, I'd be happy to work with AMD to fix the issue
properly.
In that case I'll drop it from the list of regressions, unless what I
wrote above makes you change your mind.
#regzbot invalid: firmware issue exposed by kernel change, user seems to
be happy with a workaround
Thx everyone who participated in handling this.