Messages in this thread | | | Date | Thu, 18 Apr 2024 20:38:43 -0500 | Subject | Re: [PATCH v2] platform/x86/amd: Don't allow HSMP to be loaded on non-server hardware | From | 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@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.
| |