Re: [PATCH 2/2] Documentation/arch/x86/amd-debugging: Add section about delay_suspend

[Daniel Gibson]

On 10.08.26 19:27, Mario Limonciello wrote:
> On 8/5/26 20:41, Borislav Petkov wrote:
>> On Thu, Aug 06, 2026 at 12:54:04AM +0200, Daniel Gibson wrote:
>>> That document mainly talks about s2idle issues and lists issues that
>>> have
>>> been quirked in the past, so IMHO it fits there?
>>
>> Did you not read the first sentence of that document?
>>
>>> Also, Mario Limonciello (of AMD) suggested documenting it there in:
>>> https://lore.kernel.org/platform-driver-x86/
>>> f86d9af4-6415-427a-9f4e-639b2ae6203e@xxxxxxxxxx/
>>
>> Maybe he needs to read the first sentence of that document too.
>>
>>> However, if there's a specific Wiki you think would be appropriate to
>>> document this in, I should probably document it there as well.
>>
>> You have a pretty good commit message in
>>
>>    428b9fd2dce5 ("platform/x86/amd/pmc: Add delay_suspend module
>> parameter")
>>
>> You have a bugzilla entry, you have a mailing list thread, you have a
>> module
>> param documentation.
>>
>> How much more do you need to document this? People should be able to use
>> search engines or AI, right?
>>
>> The problem with adding some hints as to how suspend can be fixed on some
>> laptops is that we'll open the floodgates. Do you know how many
>> laptops need
>> quirks and fixes for suspend?
>>
>> In any case, this doc is not for that.
>>
>> Sorry.
>>
> 
> I guess I have a different opinion here.  If someone very technical
> comes to me and says I want to debug an issue with suspend or shutdown I
> want to give them a single link that has all the information they can
> use to learn.
> 
> I thought this could fit in well at 18.7, and then even if a search
> engine or AI tool stumbles on that page it can learn about the debugging
> parameter too.

The assumption that commit messages or bug reports are documentation
sure explains why Linux official documentation is so lacking and users
(have to) rely on AI and Reddit and distro forums and the like, where
like half of the information is outdated or even misunderstood hearsay.

Even as a very technical users with strong coding skills (compared to
normal users, not to kernel developers), using git blame to figure out
the context of kernel module parameter's one-line documentation is very
annoying.

I thought that AMD debugging document was a step in the right direction
(and wondered if I just haven't found the proper documentation in
similar cases in the past), but seems like it's just a glitch in the matrix…