[Intel-gfx] [PATCH v3] ACPI / bus: Introduce a list of ids for "always present" devices

[Hans de Goede]

Hi,

On 09-04-17 09:26, Lukas Wunner wrote:
> On Sat, Apr 08, 2017 at 05:05:11PM +0200, Hans de Goede wrote:
>> Several cherrytrail devices (all of which ship with windows 10) hide the
>> lpss pwm controller in ACPI, typically the _STA method looks like this:
>>
>>     Method (_STA, 0, NotSerialized)  // _STA: Status
>>     {
>>         If (OSID == One)
>>         {
>>             Return (Zero)
>>         }
>>
>>         Return (0x0F)
>>     }
>>
>> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
>> the machine behave differently depending on which OS it *thinks* it is
>> booting, this gets set in a number of ways which we cannot control, on
>> some newer machines it simple hardcoded to "One" aka win10.
>
> Would it be a viable alternative to respond differently to _OSI queries
> for these devices by amending acpi_osi_dmi_table[] in drivers/acpi/osi.c?

Nope, _OSI influences OSYS not OSID, OSID is some quite bad Cherry Trail
hack where the BIOS behaves differently based on whether it thinks the
OS it is booting is going to be Android or Windows and there is nothing
one can do to influence OSID (other then hardcoding special handling
of that variable name in ACPICA I guess).

But even if we could influence OSID we really don't want to, for all
the same reasons our ACPI implementation always claims to be the
latest windows.

>> +		pr_debug("Device [%s] is in always present list setting status [%08x]\n",
>> +			 adev->pnp.bus_id, ACPI_STA_DEFAULT);
>
> In a lot of places in drivers/acpi/, dev_warn(&adev->dev, ...) is used.

Rafael asked me to use pr_debug here. But I agree that maybe always
logging something when this trigger might be a good idea, although
warning is too high a loglevel IMHO. So I would got with dev_info.

Rafael, what is your take on this ?

Regards,

Hans