[PATCH 1/3] ACPI / X86: Allow matching always_present_id array entries by DMI

[PATCH 1/3] ACPI / X86: Allow matching always_present_id array entries by DMI

[Hans de Goede]

On some X86 systems the DSDT hides APCI devices to work around Windows
driver bugs. On one such system the device is even hidden until a certain
time after _SB.PCI0.GFX0.LCD.LCD1._ON gets called has passed *and*
_STA has been called at least 3 times since. TL;DR: it is a mess.

Until now the always_present_id matching was used to force status
for a whole class of devices, e.g. always enable PWM1 on CHerry Trail
devices.

This commit extends the always_present_id matching code to optionally
als check for a DMI match so that we can also add system specific
quirks to the always_present_id array.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/x86/utils.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
index bd86b809c848..b0e16516adfd 100644
--- a/drivers/acpi/x86/utils.c
+++ b/drivers/acpi/x86/utils.c
@@ -12,6 +12,7 @@
  */
 
 #include <linux/acpi.h>
+#include <linux/dmi.h>
 #include <asm/cpu_device_id.h>
 #include <asm/intel-family.h>
 #include "../internal.h"
@@ -20,6 +21,10 @@
  * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
  * some recent Windows drivers bind to one device but poke at multiple
  * devices at the same time, so the others get hidden.
+ *
+ * Some BIOS-es (temporarily) hide specific APCI devices to work around Windows
+ * driver bugs. We use DMI matching to match known cases of this.
+ *
  * We work around this by always reporting ACPI_STA_DEFAULT for these
  * devices. Note this MUST only be done for devices where this is safe.
  *
@@ -31,14 +36,16 @@
 struct always_present_id {
 	struct acpi_device_id hid[2];
 	struct x86_cpu_id cpu_ids[2];
+	struct dmi_system_id dmi_ids[2]; /* Optional */
 	const char *uid;
 };
 
 #define ICPU(model)	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
 
-#define ENTRY(hid, uid, cpu_models) {					\
+#define ENTRY(hid, uid, cpu_models, dmi...) {				\
 	{ { hid, }, {} },						\
 	{ cpu_models, {} },						\
+	{ { .matches = dmi }, {} },					\
 	uid,								\
 }
 
@@ -47,13 +54,13 @@ static const struct always_present_id always_present_ids[] = {
 	 * Bay / Cherry Trail PWM directly poked by GPU driver in win10,
 	 * but Linux uses a separate PWM driver, harmless if not used.
 	 */
-	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1)),
-	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
+	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1), {}),
+	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
 	/*
 	 * The INT0002 device is necessary to clear wakeup interrupt sources
 	 * on Cherry Trail devices, without it we get nobody cared IRQ msgs.
 	 */
-	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
+	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
 };
 
 bool acpi_device_always_present(struct acpi_device *adev)
@@ -76,6 +83,10 @@ bool acpi_device_always_present(struct acpi_device *adev)
 		if (!x86_match_cpu(always_present_ids[i].cpu_ids))
 			continue;
 
+		if (always_present_ids[i].dmi_ids[0].matches[0].slot &&
+		    !dmi_check_system(always_present_ids[i].dmi_ids))
+			continue;
+
 		if (old_status != ACPI_STA_DEFAULT) /* Log only once */
 			dev_info(&adev->dev,
 				 "Device [%s] is in always present list\n",
-- 
2.13.0

[PATCH 2/3] ACPI / X86: Add Dell Venue 11 Pro 7130 touchscreen to always_present_ids

[Hans de Goede]

The _STA method of the Venue 11 Pro 7130 touchscreen has this ugliness:

                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If ((SDS1 & One) == One)
                    {
                        If (RST1 == Zero)
                        {
                            Return (0x0F)
                        }
                        ElseIf (RST2 == Zero)
                        {
                            RST2 = One
                            TMRV = Timer
                        }
                        Else
                        {
                            Local0 = ((Timer - TMRV) / 0x2710)
                            If (Local0 > TMRI)
                            {
                                RST2 = Zero
                                RST1 = Zero
                            }
                        }
                    }
                    Else
                    {
                        Return (Zero)
                    }
                }

Whereby RST1 gets set by _SB.PCI0.GFX0.LCD.LCD1._ON, this means that
after RST1 has been set first _STA must be called to set TIMER and
then after enough time has elapsed _STA must be called twice more, once
to clear RST1 and once to finally return 0xf before the touchscreen will
show up. Which is just crazy.

This commit adds an always_present_ids entry for the SYNA7500 touchscreen
ACPI node, together with a DMI match for the Venue 11 Pro 7130, fixing the
touchscreen not working on this device.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/x86/utils.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
index b0e16516adfd..eb6caf6f708b 100644
--- a/drivers/acpi/x86/utils.c
+++ b/drivers/acpi/x86/utils.c
@@ -61,6 +61,15 @@ static const struct always_present_id always_present_ids[] = {
 	 * on Cherry Trail devices, without it we get nobody cared IRQ msgs.
 	 */
 	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
+	/*
+	 * On the Dell Venue 11 Pro 7130 the DSDT hides the touchscreen ACPI
+	 * device until a certain time after _SB.PCI0.GFX0.LCD.LCD1._ON gets
+	 * called has passed *and* _STA has been called at least 3 times since.
+	 */
+	ENTRY("SYNA7500", "1", ICPU(INTEL_FAM6_HASWELL_ULT), {
+		DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7130"),
+	      }),
 };
 
 bool acpi_device_always_present(struct acpi_device *adev)
-- 
2.13.0

[PATCH 3/3] ACPI / X86: Add KIOX000A accelerometer on GPD win to always_present_ids array

[Hans de Goede]

The GPD win BIOS dated 20170320 has disabled the accelerometer, the
drivers sometimes cause crashes under Windows and this is how the
manufacturer has solved this :|

I see no other way to keep the accelerometer working under Windows then
adding it to the always_present_ids array.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/x86/utils.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
index eb6caf6f708b..b4fbb9929482 100644
--- a/drivers/acpi/x86/utils.c
+++ b/drivers/acpi/x86/utils.c
@@ -70,6 +70,19 @@ static const struct always_present_id always_present_ids[] = {
 		DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
 		DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7130"),
 	      }),
+	/*
+	 * The GPD win BIOS dated 20170320 has disabled the accelerometer, the
+	 * drivers sometimes cause crashes under Windows and this is how the
+	 * manufacturer has solved this :| Note that the the DMI data is less
+	 * generic then it seems, a board_vendor of "AMI Corporation" is quite
+	 * rare and a board_name of "Default String" also is rare.
+	 */
+	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
+		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
+		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
+		DMI_MATCH(DMI_BIOS_DATE, "03/20/2017")
+	      }),
 };
 
 bool acpi_device_always_present(struct acpi_device *adev)
-- 
2.13.0

Re: [PATCH 3/3] ACPI / X86: Add KIOX000A accelerometer on GPD win to always_present_ids array

[Andy Shevchenko]

On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
> The GPD win BIOS dated 20170320 has disabled the accelerometer, the
> drivers sometimes cause crashes under Windows and this is how the
> manufacturer has solved this :|
> 
> I see no other way to keep the accelerometer working under Windows
> then
> adding it to the always_present_ids array.
> 

> +	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
> +		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> +		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
> +		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
> +		DMI_MATCH(DMI_BIOS_DATE, "03/20/2017")

4 entries for 2 entry array?

> +	      }),
>  };
>  
>  bool acpi_device_always_present(struct acpi_device *adev)

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [PATCH 3/3] ACPI / X86: Add KIOX000A accelerometer on GPD win to always_present_ids array

[Hans de Goede]

Hi,

On 10-07-17 12:22, Andy Shevchenko wrote:
> On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
>> The GPD win BIOS dated 20170320 has disabled the accelerometer, the
>> drivers sometimes cause crashes under Windows and this is how the
>> manufacturer has solved this :|
>>
>> I see no other way to keep the accelerometer working under Windows
>> then
>> adding it to the always_present_ids array.
>>
> 
>> +	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
>> +		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
>> +		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
>> +		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
>> +		DMI_MATCH(DMI_BIOS_DATE, "03/20/2017")
> 
> 4 entries for 2 entry array?

No, there are 2 dmi_system_id array entries, one with the
actual id, one empty to terminate the array. The
dmi_system_id array entry has a matches array which is 4 big:

struct dmi_system_id {
         int (*callback)(const struct dmi_system_id *);
         const char *ident;
         struct dmi_strmatch matches[4];
         void *driver_data;
};

And the ENTRY macro puts the passed in arguments into the matches
array.

Regards,

Hans

Re: [PATCH 3/3] ACPI / X86: Add KIOX000A accelerometer on GPD win to always_present_ids array

[Andy Shevchenko]

On Mon, 2017-07-10 at 12:25 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10-07-17 12:22, Andy Shevchenko wrote:
> > On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
> > > The GPD win BIOS dated 20170320 has disabled the accelerometer,
> > > the
> > > drivers sometimes cause crashes under Windows and this is how the
> > > manufacturer has solved this :|
> > > 
> > > I see no other way to keep the accelerometer working under Windows
> > > then
> > > adding it to the always_present_ids array.
> > > 
> > > +	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
> > > +		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),

> > > +		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
> > > +		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),

Just noticed above, don't think it's a good idea to place kinda defaults
there.

> > > +		DMI_MATCH(DMI_BIOS_DATE, "03/20/2017")
> > 
> > 4 entries for 2 entry array?
> 
> No, there are 2 dmi_system_id array entries, one with the
> actual id, one empty to terminate the array. The
> dmi_system_id array entry has a matches array which is 4 big:
> 
> struct dmi_system_id {
>          int (*callback)(const struct dmi_system_id *);
>          const char *ident;
>          struct dmi_strmatch matches[4];
>          void *driver_data;
> };
> 
> And the ENTRY macro puts the passed in arguments into the matches
> array.

Ah, indeed. Thanks for explanation.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [PATCH 3/3] ACPI / X86: Add KIOX000A accelerometer on GPD win to always_present_ids array

[Hans de Goede]

Hi,

On 10-07-17 12:29, Andy Shevchenko wrote:
> On Mon, 2017-07-10 at 12:25 +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10-07-17 12:22, Andy Shevchenko wrote:
>>> On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
>>>> The GPD win BIOS dated 20170320 has disabled the accelerometer,
>>>> the
>>>> drivers sometimes cause crashes under Windows and this is how the
>>>> manufacturer has solved this :|
>>>>
>>>> I see no other way to keep the accelerometer working under Windows
>>>> then
>>>> adding it to the always_present_ids array.
>>>>
>>>> +	ENTRY("KIOX000A", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {
>>>> +		DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> 
>>>> +		DMI_MATCH(DMI_BOARD_NAME, "Default string"),
>>>> +		DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
> 
> Just noticed above, don't think it's a good idea to place kinda defaults
> there.

That is why there is a comment above the entry:

         /*
          * The GPD win BIOS dated 20170320 has disabled the accelerometer, the
          * drivers sometimes cause crashes under Windows and this is how the
          * manufacturer has solved this :| Note that the the DMI data is less
          * generic then it seems, a board_vendor of "AMI Corporation" is quite
          * rare and a board_name of "Default String" also is rare.
          */

Most Cherry Trail BIOS-es (and we do a CPU-id check for Cherry Trail)
have both DMI_BOARD_NAME and DMI_PRODUCT_NAME set to something more
sensible then "Default string" and other then the GPD win / pocket no
other model that I know of has a DMI_BOARD_NAME of "Default string"

So we can be pretty sure that the combination of Cherry Trail CPU +
these DMI strings + a BIOS-date of "03/20/2017" + having an ACPI
device with a HID of KIOX000A" is unique.

Also note that even if we have a false positive, the KIOX000A driver
will fail with a probe error, unless there is an other i2c device at
the exact same address.

Regards,

Hans

Re: [PATCH 1/3] ACPI / X86: Allow matching always_present_id array entries by DMI

[Andy Shevchenko]

On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
> On some X86 systems the DSDT hides APCI devices to work around Windows
> driver bugs. On one such system the device is even hidden until a
> certain
> time after _SB.PCI0.GFX0.LCD.LCD1._ON gets called has passed *and*
> _STA has been called at least 3 times since. TL;DR: it is a mess.
> 
> Until now the always_present_id matching was used to force status
> for a whole class of devices, e.g. always enable PWM1 on CHerry Trail

Cherry

> devices.
> 
> This commit extends the always_present_id matching code to optionally
> als check for a DMI match so that we can also add system specific
> quirks to the always_present_id array.
> 

I got answers to my questions (see thread), thus, FWIW,

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/acpi/x86/utils.c | 19 +++++++++++++++----
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
> index bd86b809c848..b0e16516adfd 100644
> --- a/drivers/acpi/x86/utils.c
> +++ b/drivers/acpi/x86/utils.c
> @@ -12,6 +12,7 @@
>   */
>  
>  #include <linux/acpi.h>
> +#include <linux/dmi.h>
>  #include <asm/cpu_device_id.h>
>  #include <asm/intel-family.h>
>  #include "../internal.h"
> @@ -20,6 +21,10 @@
>   * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
> because
>   * some recent Windows drivers bind to one device but poke at
> multiple
>   * devices at the same time, so the others get hidden.
> + *
> + * Some BIOS-es (temporarily) hide specific APCI devices to work
> around Windows
> + * driver bugs. We use DMI matching to match known cases of this.
> + *
>   * We work around this by always reporting ACPI_STA_DEFAULT for these
>   * devices. Note this MUST only be done for devices where this is
> safe.
>   *
> @@ -31,14 +36,16 @@
>  struct always_present_id {
>  	struct acpi_device_id hid[2];
>  	struct x86_cpu_id cpu_ids[2];
> +	struct dmi_system_id dmi_ids[2]; /* Optional */
>  	const char *uid;
>  };
>  
>  #define ICPU(model)	{ X86_VENDOR_INTEL, 6, model,
> X86_FEATURE_ANY, }
>  
> -#define ENTRY(hid, uid, cpu_models) {					
> \
> +#define ENTRY(hid, uid, cpu_models, dmi...) {				
> \
>  	{ { hid, }, {} },						
> \
>  	{ cpu_models, {} },						
> \
> +	{ { .matches = dmi }, {} },					
> \
>  	uid,								
> \
>  }
>  
> @@ -47,13 +54,13 @@ static const struct always_present_id
> always_present_ids[] = {
>  	 * Bay / Cherry Trail PWM directly poked by GPU driver in
> win10,
>  	 * but Linux uses a separate PWM driver, harmless if not
> used.
>  	 */
> -	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1)),
> -	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
> +	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1),
> {}),
> +	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
>  	/*
>  	 * The INT0002 device is necessary to clear wakeup interrupt
> sources
>  	 * on Cherry Trail devices, without it we get nobody cared
> IRQ msgs.
>  	 */
> -	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
> +	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
>  };
>  
>  bool acpi_device_always_present(struct acpi_device *adev)
> @@ -76,6 +83,10 @@ bool acpi_device_always_present(struct acpi_device
> *adev)
>  		if (!x86_match_cpu(always_present_ids[i].cpu_ids))
>  			continue;
>  
> +		if (always_present_ids[i].dmi_ids[0].matches[0].slot
> &&
> +		    !dmi_check_system(always_present_ids[i].dmi_ids))
> +			continue;
> +
>  		if (old_status != ACPI_STA_DEFAULT) /* Log only once
> */
>  			dev_info(&adev->dev,
>  				 "Device [%s] is in always present
> list\n",

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [PATCH 1/3] ACPI / X86: Allow matching always_present_id array entries by DMI

[Hans de Goede]

Hi,

On 10-07-17 16:25, Andy Shevchenko wrote:
> On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
>> On some X86 systems the DSDT hides APCI devices to work around Windows
>> driver bugs. On one such system the device is even hidden until a
>> certain
>> time after _SB.PCI0.GFX0.LCD.LCD1._ON gets called has passed *and*
>> _STA has been called at least 3 times since. TL;DR: it is a mess.
>>
>> Until now the always_present_id matching was used to force status
>> for a whole class of devices, e.g. always enable PWM1 on CHerry Trail
> 
> Cherry
> 
>> devices.
>>
>> This commit extends the always_present_id matching code to optionally
>> als check for a DMI match so that we can also add system specific
>> quirks to the always_present_id array.
>>
> 
> I got answers to my questions (see thread), thus, FWIW,
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Thank you, does that apply to the entire set or just the first patch ?

Regards,

Hans



> 
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   drivers/acpi/x86/utils.c | 19 +++++++++++++++----
>>   1 file changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
>> index bd86b809c848..b0e16516adfd 100644
>> --- a/drivers/acpi/x86/utils.c
>> +++ b/drivers/acpi/x86/utils.c
>> @@ -12,6 +12,7 @@
>>    */
>>   
>>   #include <linux/acpi.h>
>> +#include <linux/dmi.h>
>>   #include <asm/cpu_device_id.h>
>>   #include <asm/intel-family.h>
>>   #include "../internal.h"
>> @@ -20,6 +21,10 @@
>>    * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>> because
>>    * some recent Windows drivers bind to one device but poke at
>> multiple
>>    * devices at the same time, so the others get hidden.
>> + *
>> + * Some BIOS-es (temporarily) hide specific APCI devices to work
>> around Windows
>> + * driver bugs. We use DMI matching to match known cases of this.
>> + *
>>    * We work around this by always reporting ACPI_STA_DEFAULT for these
>>    * devices. Note this MUST only be done for devices where this is
>> safe.
>>    *
>> @@ -31,14 +36,16 @@
>>   struct always_present_id {
>>   	struct acpi_device_id hid[2];
>>   	struct x86_cpu_id cpu_ids[2];
>> +	struct dmi_system_id dmi_ids[2]; /* Optional */
>>   	const char *uid;
>>   };
>>   
>>   #define ICPU(model)	{ X86_VENDOR_INTEL, 6, model,
>> X86_FEATURE_ANY, }
>>   
>> -#define ENTRY(hid, uid, cpu_models) {					
>> \
>> +#define ENTRY(hid, uid, cpu_models, dmi...) {				
>> \
>>   	{ { hid, }, {} },						
>> \
>>   	{ cpu_models, {} },						
>> \
>> +	{ { .matches = dmi }, {} },					
>> \
>>   	uid,								
>> \
>>   }
>>   
>> @@ -47,13 +54,13 @@ static const struct always_present_id
>> always_present_ids[] = {
>>   	 * Bay / Cherry Trail PWM directly poked by GPU driver in
>> win10,
>>   	 * but Linux uses a separate PWM driver, harmless if not
>> used.
>>   	 */
>> -	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1)),
>> -	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
>> +	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1),
>> {}),
>> +	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
>>   	/*
>>   	 * The INT0002 device is necessary to clear wakeup interrupt
>> sources
>>   	 * on Cherry Trail devices, without it we get nobody cared
>> IRQ msgs.
>>   	 */
>> -	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
>> +	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
>>   };
>>   
>>   bool acpi_device_always_present(struct acpi_device *adev)
>> @@ -76,6 +83,10 @@ bool acpi_device_always_present(struct acpi_device
>> *adev)
>>   		if (!x86_match_cpu(always_present_ids[i].cpu_ids))
>>   			continue;
>>   
>> +		if (always_present_ids[i].dmi_ids[0].matches[0].slot
>> &&
>> +		    !dmi_check_system(always_present_ids[i].dmi_ids))
>> +			continue;
>> +
>>   		if (old_status != ACPI_STA_DEFAULT) /* Log only once
>> */
>>   			dev_info(&adev->dev,
>>   				 "Device [%s] is in always present
>> list\n",
> 

Re: [PATCH 1/3] ACPI / X86: Allow matching always_present_id array entries by DMI

[Andy Shevchenko]

On Mon, 2017-07-10 at 20:13 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10-07-17 16:25, Andy Shevchenko wrote:
> > On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
> > > On some X86 systems the DSDT hides APCI devices to work around
> > > Windows
> > > driver bugs. On one such system the device is even hidden until a
> > > certain
> > > time after _SB.PCI0.GFX0.LCD.LCD1._ON gets called has passed *and*
> > > _STA has been called at least 3 times since. TL;DR: it is a mess.
> > > 
> > > Until now the always_present_id matching was used to force status
> > > for a whole class of devices, e.g. always enable PWM1 on CHerry
> > > Trail
> > 
> > Cherry
> > 
> > > devices.
> > > 
> > > This commit extends the always_present_id matching code to
> > > optionally
> > > als check for a DMI match so that we can also add system specific
> > > quirks to the always_present_id array.
> > > 
> > 
> > I got answers to my questions (see thread), thus, FWIW,
> > 
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> Thank you, does that apply to the entire set or just the first patch ?

Entire series.

> 
> Regards,
> 
> Hans
> 
> 
> 
> > 
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > ---
> > >   drivers/acpi/x86/utils.c | 19 +++++++++++++++----
> > >   1 file changed, 15 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
> > > index bd86b809c848..b0e16516adfd 100644
> > > --- a/drivers/acpi/x86/utils.c
> > > +++ b/drivers/acpi/x86/utils.c
> > > @@ -12,6 +12,7 @@
> > >    */
> > >   
> > >   #include <linux/acpi.h>
> > > +#include <linux/dmi.h>
> > >   #include <asm/cpu_device_id.h>
> > >   #include <asm/intel-family.h>
> > >   #include "../internal.h"
> > > @@ -20,6 +21,10 @@
> > >    * Some ACPI devices are hidden (status == 0x0) in recent BIOS-
> > > es
> > > because
> > >    * some recent Windows drivers bind to one device but poke at
> > > multiple
> > >    * devices at the same time, so the others get hidden.
> > > + *
> > > + * Some BIOS-es (temporarily) hide specific APCI devices to work
> > > around Windows
> > > + * driver bugs. We use DMI matching to match known cases of this.
> > > + *
> > >    * We work around this by always reporting ACPI_STA_DEFAULT for
> > > these
> > >    * devices. Note this MUST only be done for devices where this
> > > is
> > > safe.
> > >    *
> > > @@ -31,14 +36,16 @@
> > >   struct always_present_id {
> > >   	struct acpi_device_id hid[2];
> > >   	struct x86_cpu_id cpu_ids[2];
> > > +	struct dmi_system_id dmi_ids[2]; /* Optional */
> > >   	const char *uid;
> > >   };
> > >   
> > >   #define ICPU(model)	{ X86_VENDOR_INTEL, 6, model,
> > > X86_FEATURE_ANY, }
> > >   
> > > -#define ENTRY(hid, uid, cpu_models) {				
> > > 	
> > > \
> > > +#define ENTRY(hid, uid, cpu_models, dmi...) {			
> > > 	
> > > \
> > >   	{ { hid, }, {} },					
> > > 	
> > > \
> > >   	{ cpu_models, {} },					
> > > 	
> > > \
> > > +	{ { .matches = dmi }, {} },				
> > > 	
> > > \
> > >   	uid,							
> > > 	
> > > \
> > >   }
> > >   
> > > @@ -47,13 +54,13 @@ static const struct always_present_id
> > > always_present_ids[] = {
> > >   	 * Bay / Cherry Trail PWM directly poked by GPU driver
> > > in
> > > win10,
> > >   	 * but Linux uses a separate PWM driver, harmless if not
> > > used.
> > >   	 */
> > > -	ENTRY("80860F09", "1",
> > > ICPU(INTEL_FAM6_ATOM_SILVERMONT1)),
> > > -	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
> > > +	ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1),
> > > {}),
> > > +	ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT),
> > > {}),
> > >   	/*
> > >   	 * The INT0002 device is necessary to clear wakeup
> > > interrupt
> > > sources
> > >   	 * on Cherry Trail devices, without it we get nobody
> > > cared
> > > IRQ msgs.
> > >   	 */
> > > -	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
> > > +	ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT), {}),
> > >   };
> > >   
> > >   bool acpi_device_always_present(struct acpi_device *adev)
> > > @@ -76,6 +83,10 @@ bool acpi_device_always_present(struct
> > > acpi_device
> > > *adev)
> > >   		if
> > > (!x86_match_cpu(always_present_ids[i].cpu_ids))
> > >   			continue;
> > >   
> > > +		if
> > > (always_present_ids[i].dmi_ids[0].matches[0].slot
> > > &&
> > > +		    !dmi_check_system(always_present_ids[i].dmi_i
> > > ds))
> > > +			continue;
> > > +
> > >   		if (old_status != ACPI_STA_DEFAULT) /* Log only
> > > once
> > > */
> > >   			dev_info(&adev->dev,
> > >   				 "Device [%s] is in always
> > > present
> > > list\n",

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [PATCH 1/3] ACPI / X86: Allow matching always_present_id array entries by DMI

[Rafael J. Wysocki]

On Monday, July 10, 2017 09:39:54 PM Andy Shevchenko wrote:
> On Mon, 2017-07-10 at 20:13 +0200, Hans de Goede wrote:
> > Hi,
> > 
> > On 10-07-17 16:25, Andy Shevchenko wrote:
> > > On Sun, 2017-07-09 at 21:05 +0200, Hans de Goede wrote:
> > > > On some X86 systems the DSDT hides APCI devices to work around
> > > > Windows
> > > > driver bugs. On one such system the device is even hidden until a
> > > > certain
> > > > time after _SB.PCI0.GFX0.LCD.LCD1._ON gets called has passed *and*
> > > > _STA has been called at least 3 times since. TL;DR: it is a mess.
> > > > 
> > > > Until now the always_present_id matching was used to force status
> > > > for a whole class of devices, e.g. always enable PWM1 on CHerry
> > > > Trail
> > > 
> > > Cherry
> > > 
> > > > devices.
> > > > 
> > > > This commit extends the always_present_id matching code to
> > > > optionally
> > > > als check for a DMI match so that we can also add system specific
> > > > quirks to the always_present_id array.
> > > > 
> > > 
> > > I got answers to my questions (see thread), thus, FWIW,
> > > 
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > Thank you, does that apply to the entire set or just the first patch ?
> 
> Entire series.

OK, series applied with your Reviewed-by, thanks!