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

[Mario Limonciello]

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@xxxxxxx>
> > > >
> > > > 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@xxxxxxx>
> > > > ---
> > > > v1->v2:
> > > >    * use pm preferred profile instead
> > >
> > > Thanks, patch looks good to me:
> > >
> > > Reviewed-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> > >
> > > 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.