Re: [PATCH v2] platform/x86/amd: Don't allow HSMP to be loaded on non-server hardware

[Mario Limonciello <superm1@gmail.com>]

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.