mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Mario Limonciello" <superm1@gmail.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>,
	Carlos Bilbao <carlos.bilbao@amd.com>,
	"open list:AMD HSMP DRIVER" <platform-driver-x86@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH v2] platform/x86/amd: Don't allow HSMP to be loaded on non-server hardware
Date: Thu, 18 Apr 2024 14:12:03 +0200	[thread overview]
Message-ID: <103294af-cb15-43d7-9f63-1d6eb458b61a@redhat.com> (raw)
In-Reply-To: <1071ea83-7919-469a-ac5b-3209fe9e018c@gmail.com>

HI,

On 4/18/24 1:27 PM, Mario Limonciello wrote:
> 
> 
> On 4/18/24 04:04, Hans de Goede wrote:
>> Hi,
>>
>> On 4/16/24 8:20 PM, Mario Limonciello wrote:
>>> From: Mario Limonciello <mario.limonciello@amd.com>
>>>
>>> If the HSMP driver is compiled into the kernel or a module manually loaded
>>> on client hardware it can cause problems with the functionality of the PMC
>>> module since it probes a mailbox with a different definition on servers.
>>>
>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2414
>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3285
>>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>>> ---
>>> v1->v2:
>>>   * use pm preferred profile instead
>>
>> Thanks, patch looks good to me:
>>
>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>
>> Mario, should this go in as a fix for the 6.9 cylce, or is
>> this for-next material ?  (I'm not sure what to do myself)
> The main risk with this patch is if there are servers that previously loaded amd-hsmp no longer working because of a BIOS bug to exporting the incorrect profile.  I think this is quite unlikely but not non-zero.
> 
> To at least give some time for anything like that to be raised I feel this should go to for-next.
> 
> Ideally I do want to see it go to stable kernels after we're all sufficiently happy though.  Random bug reports to me like the ones I added to the commit message get raised mostly by people who compile their own (stable) kernels and enable all the AMD stuff because they have AMD hardware.
> 
> So how about we target for-next, but also add a stable tag for when it gets merged in the 6.10 cycle?

Works for me. I'll merge this during my next round of patch merging and I'll
add a Cc: stable while merging.

Regards,

Hans






>>> ---
>>>   drivers/platform/x86/amd/hsmp.c | 16 ++++++++++++++++
>>>   1 file changed, 16 insertions(+)
>>>
>>> diff --git a/drivers/platform/x86/amd/hsmp.c b/drivers/platform/x86/amd/hsmp.c
>>> index 1927be901108..102a49c3e945 100644
>>> --- a/drivers/platform/x86/amd/hsmp.c
>>> +++ b/drivers/platform/x86/amd/hsmp.c
>>> @@ -907,6 +907,17 @@ static int hsmp_plat_dev_register(void)
>>>       return ret;
>>>   }
>>>   +static bool hsmp_supported_profile(void)
>>> +{
>>> +    switch (acpi_gbl_FADT.preferred_profile) {
>>> +    case PM_ENTERPRISE_SERVER:
>>> +    case PM_SOHO_SERVER:
>>> +    case PM_PERFORMANCE_SERVER:
>>> +        return true;
>>> +    }
>>> +    return false;
>>> +}
>>> +
>>>   static int __init hsmp_plt_init(void)
>>>   {
>>>       int ret = -ENODEV;
>>> @@ -917,6 +928,11 @@ static int __init hsmp_plt_init(void)
>>>           return ret;
>>>       }
>>>   +    if (!hsmp_supported_profile()) {
>>> +        pr_err("HSMP is only supported on servers");
>>> +        return ret;
>>> +    }
>>> +
>>>       /*
>>>        * amd_nb_num() returns number of SMN/DF interfaces present in the system
>>>        * if we have N SMN/DF interfaces that ideally means N sockets
>>
> 


  reply	other threads:[~2024-04-18 12:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16 18:20 Mario Limonciello
2024-04-18  9:04 ` Hans de Goede
2024-04-18 11:27   ` Mario Limonciello
2024-04-18 12:12     ` Hans de Goede [this message]
2024-04-18 13:51     ` Ilpo Järvinen
2024-04-19  1:38       ` Mario Limonciello
2024-04-22 13:31 ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=103294af-cb15-43d7-9f63-1d6eb458b61a@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=carlos.bilbao@amd.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=naveenkrishna.chatradhi@amd.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=superm1@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®