lkml.org 
[lkml]   [2024]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2] platform/x86/amd: Don't allow HSMP to be loaded on non-server hardware
From


On 4/18/24 08:51, Ilpo Järvinen wrote:
> On Thu, 18 Apr 2024, Mario Limonciello wrote:
>> On 4/18/24 04:04, Hans de Goede wrote:
>>> 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.
>
> I was also thinking it would be better to route this through 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?
>
> That's possible but if you want to retain true control over it, don't add
> stable tag at all now. You can send it on your own volition into stable
> address later once the change is in Linus' tree and your "happy" condition
> is met (Option 3 in Documentation/process/stable-kernel-rules.rst).
>
> Otherwise, stable will autoselect it the moment it lands into Linus' tree
> and you don't have much control over the timeline from that point on (I've
> seen stable folks to grumble when somebody asked to delay including a
> patch marked for stable, their reasoning was that their autotools keep
> reselecting the patch over and over again).
>

I don't feel a strong need for a specific timing. The timeline of of it
going to the stable trees when 6.10-rc1~ish seems fine by me.

\
 
 \ /
  Last update: 2024-05-27 16:46    [W:0.039 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site