mbox series

[RFC,0/2] Stop the abuse of Linux-* _OSI strings

Message ID 20220819142519.5684-1-mario.limonciello@amd.com
Headers show
Series Stop the abuse of Linux-* _OSI strings | expand

Message

Mario Limonciello Aug. 19, 2022, 2:25 p.m. UTC
3 _OSI strings were introduced in recent years that were intended
to workaround very specific problems found on specific systems.

The idea was supposed to be that these quirks were only used on
those systems, but this proved to be a bad assumption.  I've found
at least one system in the wild where the vendor using the _OSI
string doesn't match the _OSI string and the neither does the use.

So this brings a good time to review keeping those strings in the kernel.
There are 3 strings that were introduced:

Linux-Dell-Video
-> Intended for systems with NVIDIA cards that didn't support RTD3
Linux-Lenovo-NV-HDMI-Audio
-> Intended for powering on NVIDIA HDMI device
Linux-HPI-Hybrid-Graphics
-> Intended for changing dGPU output

AFAIK the first string is no longer relevant as nouveau now supports
RTD3.  If that's wrong, this can be changed for the series.

The second two strings appear to be non-scalable workarounds.  For
accomplishing these tasks, registers can be written from kernel drivers
or custom ASL can be put behind a _DSM.  By forcing either of these two
solutions it will better let the Linux kernel control the behavior.

Based on the above this series drops the first string and marks the second
two strings to only apply to older systems.

Link: https://lore.kernel.org/all/54add026bb6f45fd94a2dc2bae4adf9f@AUSX13MPC101.AMER.DELL.COM/T/

Mario Limonciello (2):
  ACPI: OSI: Remove Linux-Dell-Video _OSI string
  ACPI: OSI: Deprecate some abused _OSI strings

 Documentation/firmware-guide/acpi/osi.rst | 24 ++++++++----------
 drivers/acpi/osi.c                        | 31 ++++++++++++-----------
 2 files changed, 26 insertions(+), 29 deletions(-)

Comments

Karol Herbst Aug. 19, 2022, 3:44 p.m. UTC | #1
On Fri, Aug 19, 2022 at 4:25 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> 3 _OSI strings were introduced in recent years that were intended
> to workaround very specific problems found on specific systems.
>
> The idea was supposed to be that these quirks were only used on
> those systems, but this proved to be a bad assumption.  I've found
> at least one system in the wild where the vendor using the _OSI
> string doesn't match the _OSI string and the neither does the use.
>
> So this brings a good time to review keeping those strings in the kernel.
> There are 3 strings that were introduced:
>
> Linux-Dell-Video
> -> Intended for systems with NVIDIA cards that didn't support RTD3
> Linux-Lenovo-NV-HDMI-Audio
> -> Intended for powering on NVIDIA HDMI device
> Linux-HPI-Hybrid-Graphics
> -> Intended for changing dGPU output
>
> AFAIK the first string is no longer relevant as nouveau now supports
> RTD3.  If that's wrong, this can be changed for the series.
>

Nouveau always supported RTD3, because that's mainly a kernel feature.
When those were introduced we simply had a bug only hit on a few
systems. And instead of helping us to debug this, this workaround was
added :( We were not even asked about this.

I am a bit curious about the other two though as I am not even sure
they are needed at all as we put other work arounds in place. @Lyude
Paul might know more about these.
Mario Limonciello Aug. 19, 2022, 4:43 p.m. UTC | #2
On 8/19/2022 11:37, Karol Herbst wrote:
> On Fri, Aug 19, 2022 at 6:00 PM Limonciello, Mario
> <mario.limonciello@amd.com> wrote:
>>
>> On 8/19/2022 10:44, Karol Herbst wrote:
>>> On Fri, Aug 19, 2022 at 4:25 PM Mario Limonciello
>>> <mario.limonciello@amd.com> wrote:
>>>>
>>>> 3 _OSI strings were introduced in recent years that were intended
>>>> to workaround very specific problems found on specific systems.
>>>>
>>>> The idea was supposed to be that these quirks were only used on
>>>> those systems, but this proved to be a bad assumption.  I've found
>>>> at least one system in the wild where the vendor using the _OSI
>>>> string doesn't match the _OSI string and the neither does the use.
>>>>
>>>> So this brings a good time to review keeping those strings in the kernel.
>>>> There are 3 strings that were introduced:
>>>>
>>>> Linux-Dell-Video
>>>> -> Intended for systems with NVIDIA cards that didn't support RTD3
>>>> Linux-Lenovo-NV-HDMI-Audio
>>>> -> Intended for powering on NVIDIA HDMI device
>>>> Linux-HPI-Hybrid-Graphics
>>>> -> Intended for changing dGPU output
>>>>
>>>> AFAIK the first string is no longer relevant as nouveau now supports
>>>> RTD3.  If that's wrong, this can be changed for the series.
>>>>
>>>
>>> Nouveau always supported RTD3, because that's mainly a kernel feature.
>>> When those were introduced we simply had a bug only hit on a few
>>> systems. And instead of helping us to debug this, this workaround was
>>> added :( We were not even asked about this.
>>
>> My apologies, I was certainly part of the impetus for this W/A in the
>> first place while I was at my previous employer.  Your comment
>> re-affirms to me that at least the first patch is correct.
>>
> 
> Yeah, no worries. I just hope that people in the future will
> communicate such things.
> 
> Anyway, there are a few issues with the runpm stuff left, and looking
> at what nvidia does in their open driver makes me wonder if we might
> need a bigger overhaul of runpm. They do apply bridge/host controller
> specific workarounds and I suspect some of them are related here as
> the workaround I came up with in nouveau can be seen in 434fdb51513bf.

But this overhaul shouldn't gate removing this _OSI string, or you think 
it should?

> 
> But also having access to documentation/specification from what Nvidia
> is doing would be quite helpful. We know that on some really new AMD
> systems we run into new issues and this needs some investigation. I
> simply don't access to any laptops where this problem can be seen.
> 

Do you mean there are specifically remaining issues on AMD APU + NVIDIA 
dGPU systems?  Any public bugs by chance?

Depending on what these are I'm happy to try to help with at least 
access.  If we have them maybe we can try to make the right connections 
to get some hardware to you, or at least remotely access it.

>>>
>>> I am a bit curious about the other two though as I am not even sure
>>> they are needed at all as we put other work arounds in place. @Lyude
>>> Paul might know more about these.
>>>
>>
>> If the other two really aren't needed anymore, then yeah we should just
>> tear all 3 out.  If that's the direction we go, I would appreciate some
>> commit IDs to reference in the commit message for tearing them out so
>> that if they end up backporting to stable we know how far they should go.
>>
>
Lyude Paul Aug. 22, 2022, 9:18 p.m. UTC | #3
On Fri, 2022-08-19 at 17:44 +0200, Karol Herbst wrote:
> On Fri, Aug 19, 2022 at 4:25 PM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
> > 
> > 3 _OSI strings were introduced in recent years that were intended
> > to workaround very specific problems found on specific systems.
> > 
> > The idea was supposed to be that these quirks were only used on
> > those systems, but this proved to be a bad assumption.  I've found
> > at least one system in the wild where the vendor using the _OSI
> > string doesn't match the _OSI string and the neither does the use.
> > 
> > So this brings a good time to review keeping those strings in the kernel.
> > There are 3 strings that were introduced:
> > 
> > Linux-Dell-Video
> > -> Intended for systems with NVIDIA cards that didn't support RTD3
> > Linux-Lenovo-NV-HDMI-Audio
> > -> Intended for powering on NVIDIA HDMI device
> > Linux-HPI-Hybrid-Graphics
> > -> Intended for changing dGPU output
> > 
> > AFAIK the first string is no longer relevant as nouveau now supports
> > RTD3.  If that's wrong, this can be changed for the series.
> > 
> 
> Nouveau always supported RTD3, because that's mainly a kernel feature.
> When those were introduced we simply had a bug only hit on a few
> systems. And instead of helping us to debug this, this workaround was
> added :( We were not even asked about this.
> 
> I am a bit curious about the other two though as I am not even sure
> they are needed at all as we put other work arounds in place. @Lyude
> Paul might know more about these.

Some of the _OSI strings are totally fine. From my recollection:

[    0.242993] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
^ this one is needed to do a couple of ACPI tricks at startup to get the PCIe
device for audio on nvidia's GPU to be detected properly

[    0.242993] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)

I don't actually know how necessary this is, but I'm hesistant to call this
one bad as it may be related to the funny mux configurations that I'm learning
may exist on HP machines.

>
Kai-Heng Feng Aug. 23, 2022, 3:47 a.m. UTC | #4
[+Cc Aaron]

On Tue, Aug 23, 2022 at 5:18 AM Lyude Paul <lyude@redhat.com> wrote:
>
> On Fri, 2022-08-19 at 17:44 +0200, Karol Herbst wrote:
> > On Fri, Aug 19, 2022 at 4:25 PM Mario Limonciello
> > <mario.limonciello@amd.com> wrote:
> > >
> > > 3 _OSI strings were introduced in recent years that were intended
> > > to workaround very specific problems found on specific systems.
> > >
> > > The idea was supposed to be that these quirks were only used on
> > > those systems, but this proved to be a bad assumption.  I've found
> > > at least one system in the wild where the vendor using the _OSI
> > > string doesn't match the _OSI string and the neither does the use.
> > >
> > > So this brings a good time to review keeping those strings in the kernel.
> > > There are 3 strings that were introduced:
> > >
> > > Linux-Dell-Video
> > > -> Intended for systems with NVIDIA cards that didn't support RTD3
> > > Linux-Lenovo-NV-HDMI-Audio
> > > -> Intended for powering on NVIDIA HDMI device
> > > Linux-HPI-Hybrid-Graphics
> > > -> Intended for changing dGPU output
> > >
> > > AFAIK the first string is no longer relevant as nouveau now supports
> > > RTD3.  If that's wrong, this can be changed for the series.
> > >
> >
> > Nouveau always supported RTD3, because that's mainly a kernel feature.
> > When those were introduced we simply had a bug only hit on a few
> > systems. And instead of helping us to debug this, this workaround was
> > added :( We were not even asked about this.
> >
> > I am a bit curious about the other two though as I am not even sure
> > they are needed at all as we put other work arounds in place. @Lyude
> > Paul might know more about these.
>
> Some of the _OSI strings are totally fine. From my recollection:
>
> [    0.242993] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
> ^ this one is needed to do a couple of ACPI tricks at startup to get the PCIe
> device for audio on nvidia's GPU to be detected properly

This should be fixed by commit b516ea586d71 ("PCI: Enable NVIDIA HDA
controllers").
Aaron worked on more Lenovo systems than me, so he may be more sure of it.

>
> [    0.242993] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
>
> I don't actually know how necessary this is, but I'm hesistant to call this
> one bad as it may be related to the funny mux configurations that I'm learning
> may exist on HP machines.

Should be fixed by commit 8e55f99c510f ("drm/i915: Invoke another _DSM
to enable MUX on HP Workstation laptops").

And for "Linux-Dell-Video", it should be fixed by 5775b843a619 ("PCI:
Restore config space on runtime resume despite being unbound").

So actually I am in favor of removing them all.

Kai-Heng

>
> >
>
> --
> Cheers,
>  Lyude Paul (she/her)
>  Software Engineer at Red Hat
>
Lyude Paul Aug. 23, 2022, 5:05 p.m. UTC | #5
On Tue, 2022-08-23 at 11:47 +0800, Kai-Heng Feng wrote:
> [+Cc Aaron]
> 
> On Tue, Aug 23, 2022 at 5:18 AM Lyude Paul <lyude@redhat.com> wrote:
> > 
> > On Fri, 2022-08-19 at 17:44 +0200, Karol Herbst wrote:
> > > On Fri, Aug 19, 2022 at 4:25 PM Mario Limonciello
> > > <mario.limonciello@amd.com> wrote:
> > > > 
> > > > 3 _OSI strings were introduced in recent years that were intended
> > > > to workaround very specific problems found on specific systems.
> > > > 
> > > > The idea was supposed to be that these quirks were only used on
> > > > those systems, but this proved to be a bad assumption.  I've found
> > > > at least one system in the wild where the vendor using the _OSI
> > > > string doesn't match the _OSI string and the neither does the use.
> > > > 
> > > > So this brings a good time to review keeping those strings in the kernel.
> > > > There are 3 strings that were introduced:
> > > > 
> > > > Linux-Dell-Video
> > > > -> Intended for systems with NVIDIA cards that didn't support RTD3
> > > > Linux-Lenovo-NV-HDMI-Audio
> > > > -> Intended for powering on NVIDIA HDMI device
> > > > Linux-HPI-Hybrid-Graphics
> > > > -> Intended for changing dGPU output
> > > > 
> > > > AFAIK the first string is no longer relevant as nouveau now supports
> > > > RTD3.  If that's wrong, this can be changed for the series.
> > > > 
> > > 
> > > Nouveau always supported RTD3, because that's mainly a kernel feature.
> > > When those were introduced we simply had a bug only hit on a few
> > > systems. And instead of helping us to debug this, this workaround was
> > > added :( We were not even asked about this.
> > > 
> > > I am a bit curious about the other two though as I am not even sure
> > > they are needed at all as we put other work arounds in place. @Lyude
> > > Paul might know more about these.
> > 
> > Some of the _OSI strings are totally fine. From my recollection:
> > 
> > [    0.242993] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
> > ^ this one is needed to do a couple of ACPI tricks at startup to get the PCIe
> > device for audio on nvidia's GPU to be detected properly
> 
> This should be fixed by commit b516ea586d71 ("PCI: Enable NVIDIA HDA
> controllers").
> Aaron worked on more Lenovo systems than me, so he may be more sure of it.
> 
> > 
> > [    0.242993] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
> > 
> > I don't actually know how necessary this is, but I'm hesistant to call this
> > one bad as it may be related to the funny mux configurations that I'm learning
> > may exist on HP machines.
> 
> Should be fixed by commit 8e55f99c510f ("drm/i915: Invoke another _DSM
> to enable MUX on HP Workstation laptops").
> 
> And for "Linux-Dell-Video", it should be fixed by 5775b843a619 ("PCI:
> Restore config space on runtime resume despite being unbound").
> 
> So actually I am in favor of removing them all.

Woo! Thank you for the help with this :3. Since this all seems to be in order:

Reviewed-by: Lyude Paul <lyude@redhat.com>

> 
> Kai-Heng
> 
> > 
> > > 
> > 
> > --
> > Cheers,
> >  Lyude Paul (she/her)
> >  Software Engineer at Red Hat
> > 
>