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

[Hans de Goede]

Hi,

On 21-04-17 12:40, Rafael J. Wysocki wrote:

On Friday, April 21, 2017 12:42:31 PM Hans de Goede wrote:

HI,



[cut]


And in that path, which I seem to have overlooked before, the
acpi_set_device_status() call is too early for invoking
acpi_device_always_present(adev), so the latter should be called
directly from acpi_add_single_object() like

   acpi_init_device_object(device, handle, type, sta);
   if (acpi_device_always_present(adev))
   acpi_set_device_status(adev, ACPI_STA_DEFAULT);


That is not necessary, the place(s) where we care about status being
fixed-up for always-present devices, so that they get scanned / their
platform device initiated, is in acpi_bus_attach() which
already calls acpi_bus_get_status() and thus gets the
acpi_device_always_present() check applied before checking.

For hotplugged devices there are acpi_scan_bus_check and
acpi_scan_device_check but those both also already call
acpi_bus_get_status() before checking adev->status.


OK

Which probably means that we don't need to initialize adev->status
in acpi_init_device_object() to anything meaningful, do we?


Right, I don't think that is necessary. But maybe it is necessary
for some special cases (e.g. power resources) ?


For power resources _STA is defined differently at all and we don't
even call acpi_add_single_object() for them. :-)

Are there any other special cases in which that may matter?


Not that I'm aware of, but I'm in no way an expert when it comes
to the ACPI subsystem.

Regards,

Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rafael J. Wysocki]

On Friday, April 21, 2017 12:42:31 PM Hans de Goede wrote:
> HI,
> 

[cut]

> >>> And in that path, which I seem to have overlooked before, the
> >>> acpi_set_device_status() call is too early for invoking
> >>> acpi_device_always_present(adev), so the latter should be called
> >>> directly from acpi_add_single_object() like
> >>>
> >>>   acpi_init_device_object(device, handle, type, sta);
> >>>   if (acpi_device_always_present(adev))
> >>>   acpi_set_device_status(adev, ACPI_STA_DEFAULT);
> >>
> >> That is not necessary, the place(s) where we care about status being
> >> fixed-up for always-present devices, so that they get scanned / their
> >> platform device initiated, is in acpi_bus_attach() which
> >> already calls acpi_bus_get_status() and thus gets the
> >> acpi_device_always_present() check applied before checking.
> >>
> >> For hotplugged devices there are acpi_scan_bus_check and
> >> acpi_scan_device_check but those both also already call
> >> acpi_bus_get_status() before checking adev->status.
> > 
> > OK
> > 
> > Which probably means that we don't need to initialize adev->status
> > in acpi_init_device_object() to anything meaningful, do we?
> 
> Right, I don't think that is necessary. But maybe it is necessary
> for some special cases (e.g. power resources) ?

For power resources _STA is defined differently at all and we don't
even call acpi_add_single_object() for them. :-)

Are there any other special cases in which that may matter?

Thanks,
Rafael

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rafael J. Wysocki]

On Friday, April 21, 2017 11:59:34 AM Hans de Goede wrote:
> Hi,
> 
> On 19-04-17 22:14, Rafael J. Wysocki wrote:
> > On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede  wrote:
> >> Several Bay / Cherry Trail 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 Cherry Trail 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.
> >>
> >> This causes the PWM controller to get hidden, which means Linux cannot
> >> control the backlight level on cht based tablets / laptops.
> >>
> >> Since loading the driver for this does no harm (the only in kernel user
> >> of it is the i915 driver, which will only uses it when it needs it), this
> >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> >> for the LPSS PWM device, fixing the lack of backlight control.
> >>
> >> Signed-off-by: Hans de Goede 
> >> ---
> >> Changes in v2:
> >> -Use pr_debug instead of ACPI_DEBUG_PRINT
> >> Changes in v3:
> >> -Un-inline acpi_set_device_status and do the always_present_device_ids
> >>   table check inside the un-inlined version of it
> >> Changes in v4:
> >> -Use dev_info instead of pr_debug
> >> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
> >>   for devices present on other models then for which the quirk is intended 
> >> and
> >>   to avoid enabling unrelated ACPI devices which happen to use the same HID
> >> Changes in v5:
> >> -Only do the dev_info once per device (acpi_set_device_status gets called
> >>   multiple times per device during boot)
> >> Changes in v6:
> >> -Allow specifying more then one CPU-model for a single HID
> >> -Not only match the HID but also the UID, like on Cherry Trail, on some Bay
> >>   Trail Windows 10 tablets we need to enable the PWM controller to get 
> >> working
> >>   backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM 
> >> controllers
> >>   and we only need the first one. UID matching will allows adding an entry 
> >> for
> >>   Bay Trail which only enables the first PWM controller
> >> Changes in v7:
> >> -Put the actual x86 specific matching code and table with always present
> >>   device HID + UID + CPU model entries in a new x86/x86_utils.c file which
> >>   provides an acpi_device_always_present() helper function on x86, on
> >>   non x86 a stub which always returns false is provided
> >> -Squash in the addition of the Bay Trail PWM entry in the table as it
> >>   is there for the same reasons as the Cherry Trail entry is there
> 
> 
> 
> >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> >> index 34fbe02..4d952cc 100644
> >> --- a/drivers/acpi/bus.c
> >> +++ b/drivers/acpi/bus.c
> >> @@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
> >>   }
> >>   EXPORT_SYMBOL(acpi_bus_get_status);
> >>
> >> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
> >> +{
> >> +   u32 *status = (u32 *)>status;
> >> +
> >> +   if (acpi_device_always_present(adev))
> >> +   *status = ACPI_STA_DEFAULT;
> >> +   else
> >> +   *status = sta;
> > 
> > *((u32 *)>status) = acpi_device_always_present(adev) ?
> > ACPI_STA_DEFAULT : sta;
> > 
> > and I guess it could still be static inline?
> > 
> > But that said, evaluating _STA for the always present devices is
> > pointless (as Lukas noticed), so why not to modify
> > acpi_bus_get_status() to do something like:
> > 
> >  if (acpi_device_always_present(adev)) {
> >  acpi_set_device_status(adev, ACPI_STA_DEFAULT);
> >  return 0;
> >  }
> > 
> > upfront
> 
> Hehe, my v1 of this patch actually did the check in acpi_bus_get_status()
> I moved it to acpi_set_device_status() on your request. Moving it back
> is fine with me and indeed seems cleaner.
> 
> > and modify the other path invoking acpi_set_device_status() accordingly.
> > 
> > And in that path, which I seem to have overlooked before, the
> > acpi_set_device_status() call is too early for invoking
> > acpi_device_always_present(adev), so the latter should be called
> > directly from acpi_add_single_object() like
> > 
> >  acpi_init_device_object(device, handle, type, sta);
> >  if (acpi_device_always_present(adev))
> >  acpi_set_device_status(adev, ACPI_STA_DEFAULT);
> 
> That is not necessary, the place(s) where we care about status being
> fixed-up for always-present devices, so that they get scanned / their
> platform device initiated, is in acpi_bus_attach() which
> 

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

[Hans de Goede]

HI,

On 21-04-17 12:33, Rafael J. Wysocki wrote:

On Friday, April 21, 2017 11:59:34 AM Hans de Goede wrote:

Hi,

On 19-04-17 22:14, Rafael J. Wysocki wrote:

On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede  wrote:

Several Bay / Cherry Trail 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 Cherry Trail 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.

This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.

Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only uses it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the LPSS PWM device, fixing the lack of backlight control.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use pr_debug instead of ACPI_DEBUG_PRINT
Changes in v3:
-Un-inline acpi_set_device_status and do the always_present_device_ids
   table check inside the un-inlined version of it
Changes in v4:
-Use dev_info instead of pr_debug
-Not only check for ACPI HID but also for CPU (SoC) model so as to not
   for devices present on other models then for which the quirk is intended and
   to avoid enabling unrelated ACPI devices which happen to use the same HID
Changes in v5:
-Only do the dev_info once per device (acpi_set_device_status gets called
   multiple times per device during boot)
Changes in v6:
-Allow specifying more then one CPU-model for a single HID
-Not only match the HID but also the UID, like on Cherry Trail, on some Bay
   Trail Windows 10 tablets we need to enable the PWM controller to get working
   backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
   and we only need the first one. UID matching will allows adding an entry for
   Bay Trail which only enables the first PWM controller
Changes in v7:
-Put the actual x86 specific matching code and table with always present
   device HID + UID + CPU model entries in a new x86/x86_utils.c file which
   provides an acpi_device_always_present() helper function on x86, on
   non x86 a stub which always returns false is provided
-Squash in the addition of the Bay Trail PWM entry in the table as it
   is there for the same reasons as the Cherry Trail entry is there





diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..4d952cc 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
   }
   EXPORT_SYMBOL(acpi_bus_get_status);

+void acpi_set_device_status(struct acpi_device *adev, u32 sta)
+{
+   u32 *status = (u32 *)>status;
+
+   if (acpi_device_always_present(adev))
+   *status = ACPI_STA_DEFAULT;
+   else
+   *status = sta;


*((u32 *)>status) = acpi_device_always_present(adev) ?
ACPI_STA_DEFAULT : sta;

and I guess it could still be static inline?

But that said, evaluating _STA for the always present devices is
pointless (as Lukas noticed), so why not to modify
acpi_bus_get_status() to do something like:

  if (acpi_device_always_present(adev)) {
  acpi_set_device_status(adev, ACPI_STA_DEFAULT);
  return 0;
  }

upfront


Hehe, my v1 of this patch actually did the check in acpi_bus_get_status()
I moved it to acpi_set_device_status() on your request. Moving it back
is fine with me and indeed seems cleaner.


and modify the other path invoking acpi_set_device_status() accordingly.

And in that path, which I seem to have overlooked before, the
acpi_set_device_status() call is too early for invoking
acpi_device_always_present(adev), so the latter should be called
directly from acpi_add_single_object() like

  acpi_init_device_object(device, handle, type, sta);
  if (acpi_device_always_present(adev))
  acpi_set_device_status(adev, ACPI_STA_DEFAULT);


That is not necessary, the place(s) where we care about status being
fixed-up for always-present devices, so that they get scanned / their
platform device initiated, is in acpi_bus_attach() which
already calls acpi_bus_get_status() and thus gets the
acpi_device_always_present() check applied before checking.

For hotplugged devices there are acpi_scan_bus_check and
acpi_scan_device_check but those both also already call
acpi_bus_get_status() before checking adev->status.


OK

Which probably means that we don't need to initialize adev->status
in acpi_init_device_object() to anything meaningful, do we?


Right, I 

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

[Hans de Goede]

Hi,

On 19-04-17 22:14, Rafael J. Wysocki wrote:

On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede  wrote:

Several Bay / Cherry Trail 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 Cherry Trail 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.

This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.

Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only uses it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the LPSS PWM device, fixing the lack of backlight control.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use pr_debug instead of ACPI_DEBUG_PRINT
Changes in v3:
-Un-inline acpi_set_device_status and do the always_present_device_ids
  table check inside the un-inlined version of it
Changes in v4:
-Use dev_info instead of pr_debug
-Not only check for ACPI HID but also for CPU (SoC) model so as to not
  for devices present on other models then for which the quirk is intended and
  to avoid enabling unrelated ACPI devices which happen to use the same HID
Changes in v5:
-Only do the dev_info once per device (acpi_set_device_status gets called
  multiple times per device during boot)
Changes in v6:
-Allow specifying more then one CPU-model for a single HID
-Not only match the HID but also the UID, like on Cherry Trail, on some Bay
  Trail Windows 10 tablets we need to enable the PWM controller to get working
  backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
  and we only need the first one. UID matching will allows adding an entry for
  Bay Trail which only enables the first PWM controller
Changes in v7:
-Put the actual x86 specific matching code and table with always present
  device HID + UID + CPU model entries in a new x86/x86_utils.c file which
  provides an acpi_device_always_present() helper function on x86, on
  non x86 a stub which always returns false is provided
-Squash in the addition of the Bay Trail PWM entry in the table as it
  is there for the same reasons as the Cherry Trail entry is there





diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..4d952cc 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
  }
  EXPORT_SYMBOL(acpi_bus_get_status);

+void acpi_set_device_status(struct acpi_device *adev, u32 sta)
+{
+   u32 *status = (u32 *)>status;
+
+   if (acpi_device_always_present(adev))
+   *status = ACPI_STA_DEFAULT;
+   else
+   *status = sta;


*((u32 *)>status) = acpi_device_always_present(adev) ?
ACPI_STA_DEFAULT : sta;

and I guess it could still be static inline?

But that said, evaluating _STA for the always present devices is
pointless (as Lukas noticed), so why not to modify
acpi_bus_get_status() to do something like:

 if (acpi_device_always_present(adev)) {
 acpi_set_device_status(adev, ACPI_STA_DEFAULT);
 return 0;
 }

upfront


Hehe, my v1 of this patch actually did the check in acpi_bus_get_status()
I moved it to acpi_set_device_status() on your request. Moving it back
is fine with me and indeed seems cleaner.


and modify the other path invoking acpi_set_device_status() accordingly.

And in that path, which I seem to have overlooked before, the
acpi_set_device_status() call is too early for invoking
acpi_device_always_present(adev), so the latter should be called
directly from acpi_add_single_object() like

 acpi_init_device_object(device, handle, type, sta);
 if (acpi_device_always_present(adev))
 acpi_set_device_status(adev, ACPI_STA_DEFAULT);


That is not necessary, the place(s) where we care about status being
fixed-up for always-present devices, so that they get scanned / their
platform device initiated, is in acpi_bus_attach() which
already calls acpi_bus_get_status() and thus gets the
acpi_device_always_present() check applied before checking.

For hotplugged devices there are acpi_scan_bus_check and
acpi_scan_device_check but those both also already call
acpi_bus_get_status() before checking adev->status.

So just adding the check to acpi_bus_get_status(), as I did in
v1 is sufficient.

Note that the end result is still significantly cleaner then v1
as we're now using the acpi_device_always_present() which makes
the drivers/acpi/bus.c changes a lot cleaner.

I'll go and test this and 

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

[Rafael J. Wysocki]

On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede  wrote:
> Several Bay / Cherry Trail 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 Cherry Trail 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.
>
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
>
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only uses it when it needs it), this
> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> for the LPSS PWM device, fixing the lack of backlight control.
>
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Use pr_debug instead of ACPI_DEBUG_PRINT
> Changes in v3:
> -Un-inline acpi_set_device_status and do the always_present_device_ids
>  table check inside the un-inlined version of it
> Changes in v4:
> -Use dev_info instead of pr_debug
> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
>  for devices present on other models then for which the quirk is intended and
>  to avoid enabling unrelated ACPI devices which happen to use the same HID
> Changes in v5:
> -Only do the dev_info once per device (acpi_set_device_status gets called
>  multiple times per device during boot)
> Changes in v6:
> -Allow specifying more then one CPU-model for a single HID
> -Not only match the HID but also the UID, like on Cherry Trail, on some Bay
>  Trail Windows 10 tablets we need to enable the PWM controller to get working
>  backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
>  and we only need the first one. UID matching will allows adding an entry for
>  Bay Trail which only enables the first PWM controller
> Changes in v7:
> -Put the actual x86 specific matching code and table with always present
>  device HID + UID + CPU model entries in a new x86/x86_utils.c file which
>  provides an acpi_device_always_present() helper function on x86, on
>  non x86 a stub which always returns false is provided
> -Squash in the addition of the Bay Trail PWM entry in the table as it
>  is there for the same reasons as the Cherry Trail entry is there
> ---
>  drivers/acpi/Makefile|  1 +
>  drivers/acpi/bus.c   | 10 ++
>  drivers/acpi/x86/x86_utils.c | 85 
> 
>  include/acpi/acpi_bus.h  | 15 +---
>  4 files changed, 106 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/acpi/x86/x86_utils.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index d78065c..f3940ac 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -50,6 +50,7 @@ acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
>  acpi-y += sysfs.o
>  acpi-y += property.o
>  acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
> +acpi-$(CONFIG_X86) += x86/x86_utils.o
>  acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
>  acpi-$(CONFIG_ACPI_NUMA)   += numa.o
>  acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 34fbe02..4d952cc 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
>  }
>  EXPORT_SYMBOL(acpi_bus_get_status);
>
> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
> +{
> +   u32 *status = (u32 *)>status;
> +
> +   if (acpi_device_always_present(adev))
> +   *status = ACPI_STA_DEFAULT;
> +   else
> +   *status = sta;

*((u32 *)>status) = acpi_device_always_present(adev) ?
ACPI_STA_DEFAULT : sta;

and I guess it could still be static inline?

But that said, evaluating _STA for the always present devices is
pointless (as Lukas noticed), so why not to modify
acpi_bus_get_status() to do something like:

if (acpi_device_always_present(adev)) {
acpi_set_device_status(adev, ACPI_STA_DEFAULT);
return 0;
}

upfront and modify the other path invoking acpi_set_device_status() accordingly.

And in that path, which I seem to have overlooked before, the
acpi_set_device_status() call is too early for invoking
acpi_device_always_present(adev), so the latter should be called
directly from acpi_add_single_object() like

acpi_init_device_object(device, handle, type, sta);
if (acpi_device_always_present(adev))
acpi_set_device_status(adev, ACPI_STA_DEFAULT);

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

[Hans de Goede]

Several Bay / Cherry Trail 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 Cherry Trail 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.

This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.

Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only uses it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the LPSS PWM device, fixing the lack of backlight control.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use pr_debug instead of ACPI_DEBUG_PRINT
Changes in v3:
-Un-inline acpi_set_device_status and do the always_present_device_ids
 table check inside the un-inlined version of it
Changes in v4:
-Use dev_info instead of pr_debug
-Not only check for ACPI HID but also for CPU (SoC) model so as to not
 for devices present on other models then for which the quirk is intended and
 to avoid enabling unrelated ACPI devices which happen to use the same HID
Changes in v5:
-Only do the dev_info once per device (acpi_set_device_status gets called
 multiple times per device during boot)
Changes in v6:
-Allow specifying more then one CPU-model for a single HID
-Not only match the HID but also the UID, like on Cherry Trail, on some Bay
 Trail Windows 10 tablets we need to enable the PWM controller to get working
 backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
 and we only need the first one. UID matching will allows adding an entry for
 Bay Trail which only enables the first PWM controller
Changes in v7:
-Put the actual x86 specific matching code and table with always present
 device HID + UID + CPU model entries in a new x86/x86_utils.c file which
 provides an acpi_device_always_present() helper function on x86, on
 non x86 a stub which always returns false is provided
-Squash in the addition of the Bay Trail PWM entry in the table as it
 is there for the same reasons as the Cherry Trail entry is there
---
 drivers/acpi/Makefile|  1 +
 drivers/acpi/bus.c   | 10 ++
 drivers/acpi/x86/x86_utils.c | 85 
 include/acpi/acpi_bus.h  | 15 +---
 4 files changed, 106 insertions(+), 5 deletions(-)
 create mode 100644 drivers/acpi/x86/x86_utils.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index d78065c..f3940ac 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -50,6 +50,7 @@ acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
 acpi-y += sysfs.o
 acpi-y += property.o
 acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
+acpi-$(CONFIG_X86) += x86/x86_utils.o
 acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
 acpi-$(CONFIG_ACPI_NUMA)   += numa.o
 acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..4d952cc 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
 }
 EXPORT_SYMBOL(acpi_bus_get_status);
 
+void acpi_set_device_status(struct acpi_device *adev, u32 sta)
+{
+   u32 *status = (u32 *)>status;
+
+   if (acpi_device_always_present(adev))
+   *status = ACPI_STA_DEFAULT;
+   else
+   *status = sta;
+}
+
 void acpi_bus_private_data_handler(acpi_handle handle,
   void *context)
 {
diff --git a/drivers/acpi/x86/x86_utils.c b/drivers/acpi/x86/x86_utils.c
new file mode 100644
index 000..74f1237
--- /dev/null
+++ b/drivers/acpi/x86/x86_utils.c
@@ -0,0 +1,85 @@
+/*
+ *  X86 ACPI Utility Functions
+ *
+ * Copyright (C) 2017 Hans de Goede 
+ *
+ * Based on various non upstream patches to support the CHT Whiskey Cove PMIC:
+ * Copyright (C) 2013-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include "../internal.h"
+
+/*
+ * 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.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for