On Mon, Jun 07, 2021 at 04:10:30PM +0200, Joerg Roedel wrote: > Hi Bjorn, > > On Thu, Jun 03, 2021 at 03:50:47PM -0500, Bjorn Helgaas wrote: > > On Thu, Jun 03, 2021 at 02:48:14PM +0200, Joerg Roedel wrote: > > > If instead you mean that the OS has *not* been granted DPC control, > > but does _OSC(Query, SUPPORT=x, CONTROL=0), I think that means the OS > > is telling the platform what it supports but not requesting anything. > > That sounds legal to me, so if firmware complains about it, I would > > say it's a firmware problem. > > I think it depends on how you look at it. The machine I was working with > has a BIOS setting where one can configure that DPC is controlled by the > OS. When it is configured that way, then the BIOS will issue an error > when an _OSC query is made with control set to 0. This is because it > indicates to the BIOS that the OS does not take control over DPC and > thus that the OS does not support it. The BIOS will issue a warning into > its log and when the Linux later takes control the warning is already > there. I think that BIOS setting is misguided. _OSC is designed around the assumption that features in the Control field start out being controlled by the platform, and they stay that way until the OS requests control of a feature and the platform grants it. It makes no sense to me to configure the BIOS in advance to say "the OS controls DPC." The BIOS has no control over what the OS will do, and it can't behave as though the OS controls DPC until the OS actually requests that. I also think the warning is overly aggressive. _OSC is clearly designed to be evaluated multiple times, and the OS is allowed to request control of more features each time (ACPI v6.3, sec 6.2.11.1.1, 6.2.11.1.3). Bjorn
