linux-kernel - Re: [PATCH v1] platform/x86/amd/pmc: Get smu version before reading dram size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bd018335-3b2c-4233-aae3-407e239fd393@amd.com>
Date:   Mon, 30 Oct 2023 11:17:52 -0500
From:   Mario Limonciello <mario.limonciello@....com>
To:     Mark Hasemeyer <markhas@...omium.org>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     Shyam Sundar S K <Shyam-sundar.S-k@....com>,
        LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <markgross@...nel.org>,
        Sanket Goswami <Sanket.Goswami@....com>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v1] platform/x86/amd/pmc: Get smu version before reading
 dram size

On 10/30/2023 11:09, Mark Hasemeyer wrote:
>> Hi,
>>
>> Thank you for your patch. This has already come up but no acceptable patch
>> has emerged since. Please see this thread for what needs to be done if you
>> want to provide one (or maybe Shyam already has one which has just not
>> been sent out yet):
>>
>> https://lore.kernel.org/platform-driver-x86/3b224c62-a1d8-41bd-aced-5825f5f20e66@amd.com/
>>
>> (Since this dram size is on an init path that always needs SMU version,
>> the SMU version can just be called by the init unconditonally rather than
>> adding more of this lazy initialization everywhere).
> 
> Thanks for pointing me to that thread. I think Shyam/AMD can come up
> with a better long term solution, but it may be worth pushing this
> patch through for a couple reasons:
> 1. Probing of the driver currently fails on STB enabled systems with a
> Mendocino SoC. A slower boot time is better than the driver failing to
> load IMO.
> 2. This patch only affects Mendocino SoCs, and was a suggested
> solution from Mario in the thread you mentioned.
> 
> That said, I can also just disable STB for now...

It's debugfs.  The vast majority of people won't need to access it even 
if STB is turned on by default.  It should only really be needed in 
error cases.

So how about if the STB init is pushed into the lazy init path as well? 
You can make the files at probe, and then check in their first access if 
init was done.