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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
