Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1708046 > unrolled thread

[PATCH 0/3] ACPI: Initialize GPEs before the initial namespace scan

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] ACPI: Initialize GPEs before the initial namespace scan "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-10 00:50 +0200
    [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-10 00:50 +0200
      RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs  earlier "Zheng, Lv" <lv.zheng@intel.com> - 2017-08-10 04:00 +0200
        Re: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-08-10 18:20 +0200
          RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs  earlier "Zheng, Lv" <lv.zheng@intel.com> - 2017-08-11 08:20 +0200
    Re: [PATCH 0/3] ACPI: Initialize GPEs before the initial namespace  scan Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-08-10 12:00 +0200

#1708046 — [PATCH 0/3] ACPI: Initialize GPEs before the initial namespace scan

Hi,

This is exceptional for at least two reasons.

First, we need it now to work around boot problems on multiple platforms
already seen in the field (which are shipping products).

Second, the ACPICA changes in this series are kind of Linux-specific, because
they are related to how Linux carries out the initialization of devices, which
very well may be different from what the other OSes using ACPICA do.

For these reasons, I'd like to make the following ACPICA changes in Linux
only for the time being and then decide whether or not to take them into
the upstream.  If there are major concerns about that, please let me know.

The issue at hand is that some platforms with Thunderbolt controllers won't
boot if there are any Thunderbolt devices connected to them at boot time (if
the devices are connected later, everything works as expected).  That turns
out to be related to a complicated sequence of events involving the platform
firmware which needs to happen in exactly the right order at the right time
for things to work and that requires GPEs to be enabled before enumerating
the PCI bus.

The first patch changes ACPICA to check the status of runtime GPEs before
enabling them for the first time in order to avoid missing events (that
is key for edge-triggered GPEs) and to process them early enough.

The second one makes it possible to change the ordering of initialization
between GPEs and devices, and the third one actually changes that ordering.

The patches are based on Mika's work, so kudos to him.

Thanks,
Rafael

[toc] | [next] | [standalone]

#1708047 — [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Runtime GPEs have corresponding _Lxx/_Exx methods and are enabled
automatically during the initialization of the ACPI subsystem through
acpi_update_all_gpes() with the assumption that acpi_setup_gpe_for_wake()
will be called in advance for all of the GPEs pointed to by _PRW
objects in the namespace that may be affected by acpi_update_all_gpes().
That is, acpi_ev_initialize_gpe_block() can only be called for a GPE
block after acpi_setup_gpe_for_wake() has been called for all of the
_PRW (wakeup) GPEs in it.

The platform firmware on some systems, however, expects GPEs to be
enabled before the enumeration of devices which is when
acpi_setup_gpe_for_wake() is called and that goes against the above
assumption.

For this reason, introduce a new flag to be set by
acpi_ev_initialize_gpe_block() when automatically enabling a GPE
to indicate to acpi_setup_gpe_for_wake() that it needs to drop the
reference to the GPE coming from acpi_ev_initialize_gpe_block()
and modify acpi_setup_gpe_for_wake() accordingly.  These changes
allow acpi_setup_gpe_for_wake() and acpi_ev_initialize_gpe_block()
to be invoked in any order.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/acpi/acpica/evgpeblk.c |    2 ++
 drivers/acpi/acpica/evxfgpe.c  |    8 ++++++++
 include/acpi/actypes.h         |    3 ++-
 3 files changed, 12 insertions(+), 1 deletion(-)

Index: linux-pm/drivers/acpi/acpica/evgpeblk.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpica/evgpeblk.c
+++ linux-pm/drivers/acpi/acpica/evgpeblk.c
@@ -496,6 +496,8 @@ acpi_ev_initialize_gpe_block(struct acpi
 				continue;
 			}
 
+			gpe_event_info->flags |= ACPI_GPE_AUTO_ENABLED;
+
 			if (event_status & ACPI_EVENT_FLAG_STATUS_SET) {
 				ACPI_INFO(("GPE 0x%02X active on init",
 					   gpe_number));
Index: linux-pm/include/acpi/actypes.h
===================================================================
--- linux-pm.orig/include/acpi/actypes.h
+++ linux-pm/include/acpi/actypes.h
@@ -783,7 +783,7 @@ typedef u32 acpi_event_status;
  *   |  | | |  +-- Type of dispatch:to method, handler, notify, or none
  *   |  | | +----- Interrupt type: edge or level triggered
  *   |  | +------- Is a Wake GPE
- *   |  +--------- Is GPE masked by the software GPE masking mechanism
+ *   |  +--------- Has been enabled automatically at init time
  *   +------------ <Reserved>
  */
 #define ACPI_GPE_DISPATCH_NONE          (u8) 0x00
@@ -799,6 +799,7 @@ typedef u32 acpi_event_status;
 #define ACPI_GPE_XRUPT_TYPE_MASK        (u8) 0x08
 
 #define ACPI_GPE_CAN_WAKE               (u8) 0x10
+#define ACPI_GPE_AUTO_ENABLED           (u8) 0x20
 
 /*
  * Flags for GPE and Lock interfaces
Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
+++ linux-pm/drivers/acpi/acpica/evxfgpe.c
@@ -435,6 +435,14 @@ acpi_setup_gpe_for_wake(acpi_handle wake
 		 */
 		gpe_event_info->flags =
 		    (ACPI_GPE_DISPATCH_NOTIFY | ACPI_GPE_LEVEL_TRIGGERED);
+	} else if (gpe_event_info->flags & ACPI_GPE_AUTO_ENABLED) {
+		/*
+		 * A reference to this GPE has been added during the GPE block
+		 * initialization, so drop it now to prevent the GPE from being
+		 * permanently enabled and clear its ACPI_GPE_AUTO_ENABLED flag.
+		 */
+		(void)acpi_ev_remove_gpe_reference(gpe_event_info);
+		gpe_event_info->flags &= ~ACPI_GPE_AUTO_ENABLED;
 	}
 
 	/*

[toc] | [prev] | [next] | [standalone]

#1708134 — RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

Hi, Rafael

For this patch, I have a concern.

> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Subject: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier
> 
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Runtime GPEs have corresponding _Lxx/_Exx methods and are enabled
> automatically during the initialization of the ACPI subsystem through
> acpi_update_all_gpes() with the assumption that acpi_setup_gpe_for_wake()
> will be called in advance for all of the GPEs pointed to by _PRW
> objects in the namespace that may be affected by acpi_update_all_gpes().
> That is, acpi_ev_initialize_gpe_block() can only be called for a GPE
> block after acpi_setup_gpe_for_wake() has been called for all of the
> _PRW (wakeup) GPEs in it.
> 
> The platform firmware on some systems, however, expects GPEs to be
> enabled before the enumeration of devices which is when
> acpi_setup_gpe_for_wake() is called and that goes against the above
> assumption.
> 
> For this reason, introduce a new flag to be set by
> acpi_ev_initialize_gpe_block() when automatically enabling a GPE
> to indicate to acpi_setup_gpe_for_wake() that it needs to drop the
> reference to the GPE coming from acpi_ev_initialize_gpe_block()
> and modify acpi_setup_gpe_for_wake() accordingly.  These changes
> allow acpi_setup_gpe_for_wake() and acpi_ev_initialize_gpe_block()
> to be invoked in any order.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  drivers/acpi/acpica/evgpeblk.c |    2 ++
>  drivers/acpi/acpica/evxfgpe.c  |    8 ++++++++
>  include/acpi/actypes.h         |    3 ++-
>  3 files changed, 12 insertions(+), 1 deletion(-)
> 
> Index: linux-pm/drivers/acpi/acpica/evgpeblk.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/acpica/evgpeblk.c
> +++ linux-pm/drivers/acpi/acpica/evgpeblk.c
> @@ -496,6 +496,8 @@ acpi_ev_initialize_gpe_block(struct acpi
>  				continue;
>  			}
> 
> +			gpe_event_info->flags |= ACPI_GPE_AUTO_ENABLED;
> +
>  			if (event_status & ACPI_EVENT_FLAG_STATUS_SET) {
>  				ACPI_INFO(("GPE 0x%02X active on init",
>  					   gpe_number));
> Index: linux-pm/include/acpi/actypes.h
> ===================================================================
> --- linux-pm.orig/include/acpi/actypes.h
> +++ linux-pm/include/acpi/actypes.h
> @@ -783,7 +783,7 @@ typedef u32 acpi_event_status;
>   *   |  | | |  +-- Type of dispatch:to method, handler, notify, or none
>   *   |  | | +----- Interrupt type: edge or level triggered
>   *   |  | +------- Is a Wake GPE
> - *   |  +--------- Is GPE masked by the software GPE masking mechanism
> + *   |  +--------- Has been enabled automatically at init time
>   *   +------------ <Reserved>
>   */
>  #define ACPI_GPE_DISPATCH_NONE          (u8) 0x00
> @@ -799,6 +799,7 @@ typedef u32 acpi_event_status;
>  #define ACPI_GPE_XRUPT_TYPE_MASK        (u8) 0x08
> 
>  #define ACPI_GPE_CAN_WAKE               (u8) 0x10
> +#define ACPI_GPE_AUTO_ENABLED           (u8) 0x20
> 
>  /*
>   * Flags for GPE and Lock interfaces
> Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> @@ -435,6 +435,14 @@ acpi_setup_gpe_for_wake(acpi_handle wake
>  		 */
>  		gpe_event_info->flags =
>  		    (ACPI_GPE_DISPATCH_NOTIFY | ACPI_GPE_LEVEL_TRIGGERED);
> +	} else if (gpe_event_info->flags & ACPI_GPE_AUTO_ENABLED) {
> +		/*
> +		 * A reference to this GPE has been added during the GPE block
> +		 * initialization, so drop it now to prevent the GPE from being
> +		 * permanently enabled and clear its ACPI_GPE_AUTO_ENABLED flag.
> +		 */
> +		(void)acpi_ev_remove_gpe_reference(gpe_event_info);
> +		gpe_event_info->flags &= ~ACPI_GPE_AUTO_ENABLED;

The problem is if the GPE is shared, how can we know decrement reference
once can sufficiently convert it into wakeup dispatcher owned GPE?

Thanks and best regards
Lv

[toc] | [prev] | [next] | [standalone]

#1708801 — Re: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

On Thursday, August 10, 2017 3:52:05 AM CEST Zheng, Lv wrote:
> Hi, Rafael
> 
> For this patch, I have a concern.
> 
> > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > Subject: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier
> > 
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > 
> > Runtime GPEs have corresponding _Lxx/_Exx methods and are enabled
> > automatically during the initialization of the ACPI subsystem through
> > acpi_update_all_gpes() with the assumption that acpi_setup_gpe_for_wake()
> > will be called in advance for all of the GPEs pointed to by _PRW
> > objects in the namespace that may be affected by acpi_update_all_gpes().
> > That is, acpi_ev_initialize_gpe_block() can only be called for a GPE
> > block after acpi_setup_gpe_for_wake() has been called for all of the
> > _PRW (wakeup) GPEs in it.
> > 
> > The platform firmware on some systems, however, expects GPEs to be
> > enabled before the enumeration of devices which is when
> > acpi_setup_gpe_for_wake() is called and that goes against the above
> > assumption.
> > 
> > For this reason, introduce a new flag to be set by
> > acpi_ev_initialize_gpe_block() when automatically enabling a GPE
> > to indicate to acpi_setup_gpe_for_wake() that it needs to drop the
> > reference to the GPE coming from acpi_ev_initialize_gpe_block()
> > and modify acpi_setup_gpe_for_wake() accordingly.  These changes
> > allow acpi_setup_gpe_for_wake() and acpi_ev_initialize_gpe_block()
> > to be invoked in any order.
> > 
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >  drivers/acpi/acpica/evgpeblk.c |    2 ++
> >  drivers/acpi/acpica/evxfgpe.c  |    8 ++++++++
> >  include/acpi/actypes.h         |    3 ++-
> >  3 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > Index: linux-pm/drivers/acpi/acpica/evgpeblk.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/acpica/evgpeblk.c
> > +++ linux-pm/drivers/acpi/acpica/evgpeblk.c
> > @@ -496,6 +496,8 @@ acpi_ev_initialize_gpe_block(struct acpi
> >  				continue;
> >  			}
> > 
> > +			gpe_event_info->flags |= ACPI_GPE_AUTO_ENABLED;
> > +
> >  			if (event_status & ACPI_EVENT_FLAG_STATUS_SET) {
> >  				ACPI_INFO(("GPE 0x%02X active on init",
> >  					   gpe_number));
> > Index: linux-pm/include/acpi/actypes.h
> > ===================================================================
> > --- linux-pm.orig/include/acpi/actypes.h
> > +++ linux-pm/include/acpi/actypes.h
> > @@ -783,7 +783,7 @@ typedef u32 acpi_event_status;
> >   *   |  | | |  +-- Type of dispatch:to method, handler, notify, or none
> >   *   |  | | +----- Interrupt type: edge or level triggered
> >   *   |  | +------- Is a Wake GPE
> > - *   |  +--------- Is GPE masked by the software GPE masking mechanism
> > + *   |  +--------- Has been enabled automatically at init time
> >   *   +------------ <Reserved>
> >   */
> >  #define ACPI_GPE_DISPATCH_NONE          (u8) 0x00
> > @@ -799,6 +799,7 @@ typedef u32 acpi_event_status;
> >  #define ACPI_GPE_XRUPT_TYPE_MASK        (u8) 0x08
> > 
> >  #define ACPI_GPE_CAN_WAKE               (u8) 0x10
> > +#define ACPI_GPE_AUTO_ENABLED           (u8) 0x20
> > 
> >  /*
> >   * Flags for GPE and Lock interfaces
> > Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> > +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> > @@ -435,6 +435,14 @@ acpi_setup_gpe_for_wake(acpi_handle wake
> >  		 */
> >  		gpe_event_info->flags =
> >  		    (ACPI_GPE_DISPATCH_NOTIFY | ACPI_GPE_LEVEL_TRIGGERED);
> > +	} else if (gpe_event_info->flags & ACPI_GPE_AUTO_ENABLED) {
> > +		/*
> > +		 * A reference to this GPE has been added during the GPE block
> > +		 * initialization, so drop it now to prevent the GPE from being
> > +		 * permanently enabled and clear its ACPI_GPE_AUTO_ENABLED flag.
> > +		 */
> > +		(void)acpi_ev_remove_gpe_reference(gpe_event_info);
> > +		gpe_event_info->flags &= ~ACPI_GPE_AUTO_ENABLED;
> 
> The problem is if the GPE is shared, how can we know decrement reference
> once can sufficiently convert it into wakeup dispatcher owned GPE?

Even if it is shared, the current code will not enable it if it sees
ACPI_GPE_CAN_WAKE set.

We can change that logic, but that should be a separate patch IMO and
this is not related to the problem at hand.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1709282 — RE: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier

Hi,

> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Subject: Re: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier
> 
> On Thursday, August 10, 2017 3:52:05 AM CEST Zheng, Lv wrote:
> > Hi, Rafael
> >
> > For this patch, I have a concern.
> >
> > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > Subject: [PATCH 2/3] ACPICA: Make it possible to enable runtime GPEs earlier
> > >
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > Runtime GPEs have corresponding _Lxx/_Exx methods and are enabled
> > > automatically during the initialization of the ACPI subsystem through
> > > acpi_update_all_gpes() with the assumption that acpi_setup_gpe_for_wake()
> > > will be called in advance for all of the GPEs pointed to by _PRW
> > > objects in the namespace that may be affected by acpi_update_all_gpes().
> > > That is, acpi_ev_initialize_gpe_block() can only be called for a GPE
> > > block after acpi_setup_gpe_for_wake() has been called for all of the
> > > _PRW (wakeup) GPEs in it.
> > >
> > > The platform firmware on some systems, however, expects GPEs to be
> > > enabled before the enumeration of devices which is when
> > > acpi_setup_gpe_for_wake() is called and that goes against the above
> > > assumption.
> > >
> > > For this reason, introduce a new flag to be set by
> > > acpi_ev_initialize_gpe_block() when automatically enabling a GPE
> > > to indicate to acpi_setup_gpe_for_wake() that it needs to drop the
> > > reference to the GPE coming from acpi_ev_initialize_gpe_block()
> > > and modify acpi_setup_gpe_for_wake() accordingly.  These changes
> > > allow acpi_setup_gpe_for_wake() and acpi_ev_initialize_gpe_block()
> > > to be invoked in any order.
> > >
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > ---
> > >  drivers/acpi/acpica/evgpeblk.c |    2 ++
> > >  drivers/acpi/acpica/evxfgpe.c  |    8 ++++++++
> > >  include/acpi/actypes.h         |    3 ++-
> > >  3 files changed, 12 insertions(+), 1 deletion(-)
> > >
> > > Index: linux-pm/drivers/acpi/acpica/evgpeblk.c
> > > ===================================================================
> > > --- linux-pm.orig/drivers/acpi/acpica/evgpeblk.c
> > > +++ linux-pm/drivers/acpi/acpica/evgpeblk.c
> > > @@ -496,6 +496,8 @@ acpi_ev_initialize_gpe_block(struct acpi
> > >  				continue;
> > >  			}
> > >
> > > +			gpe_event_info->flags |= ACPI_GPE_AUTO_ENABLED;
> > > +
> > >  			if (event_status & ACPI_EVENT_FLAG_STATUS_SET) {
> > >  				ACPI_INFO(("GPE 0x%02X active on init",
> > >  					   gpe_number));
> > > Index: linux-pm/include/acpi/actypes.h
> > > ===================================================================
> > > --- linux-pm.orig/include/acpi/actypes.h
> > > +++ linux-pm/include/acpi/actypes.h
> > > @@ -783,7 +783,7 @@ typedef u32 acpi_event_status;
> > >   *   |  | | |  +-- Type of dispatch:to method, handler, notify, or none
> > >   *   |  | | +----- Interrupt type: edge or level triggered
> > >   *   |  | +------- Is a Wake GPE
> > > - *   |  +--------- Is GPE masked by the software GPE masking mechanism
> > > + *   |  +--------- Has been enabled automatically at init time
> > >   *   +------------ <Reserved>
> > >   */
> > >  #define ACPI_GPE_DISPATCH_NONE          (u8) 0x00
> > > @@ -799,6 +799,7 @@ typedef u32 acpi_event_status;
> > >  #define ACPI_GPE_XRUPT_TYPE_MASK        (u8) 0x08
> > >
> > >  #define ACPI_GPE_CAN_WAKE               (u8) 0x10
> > > +#define ACPI_GPE_AUTO_ENABLED           (u8) 0x20
> > >
> > >  /*
> > >   * Flags for GPE and Lock interfaces
> > > Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> > > ===================================================================
> > > --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> > > +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> > > @@ -435,6 +435,14 @@ acpi_setup_gpe_for_wake(acpi_handle wake
> > >  		 */
> > >  		gpe_event_info->flags =
> > >  		    (ACPI_GPE_DISPATCH_NOTIFY | ACPI_GPE_LEVEL_TRIGGERED);
> > > +	} else if (gpe_event_info->flags & ACPI_GPE_AUTO_ENABLED) {
> > > +		/*
> > > +		 * A reference to this GPE has been added during the GPE block
> > > +		 * initialization, so drop it now to prevent the GPE from being
> > > +		 * permanently enabled and clear its ACPI_GPE_AUTO_ENABLED flag.
> > > +		 */
> > > +		(void)acpi_ev_remove_gpe_reference(gpe_event_info);
> > > +		gpe_event_info->flags &= ~ACPI_GPE_AUTO_ENABLED;
> >
> > The problem is if the GPE is shared, how can we know decrement reference
> > once can sufficiently convert it into wakeup dispatcher owned GPE?
> 
> Even if it is shared, the current code will not enable it if it sees
> ACPI_GPE_CAN_WAKE set.
> 
> We can change that logic, but that should be a separate patch IMO and
> this is not related to the problem at hand.

OK, I see.
We can enhance that on top of these fixes.

Thanks,
Lv

[toc] | [prev] | [next] | [standalone]

#1708383 — Re: [PATCH 0/3] ACPI: Initialize GPEs before the initial namespace scan

On Thu, Aug 10, 2017 at 12:29:12AM +0200, Rafael J. Wysocki wrote:
> Hi,
> 
> This is exceptional for at least two reasons.
> 
> First, we need it now to work around boot problems on multiple platforms
> already seen in the field (which are shipping products).
> 
> Second, the ACPICA changes in this series are kind of Linux-specific, because
> they are related to how Linux carries out the initialization of devices, which
> very well may be different from what the other OSes using ACPICA do.
> 
> For these reasons, I'd like to make the following ACPICA changes in Linux
> only for the time being and then decide whether or not to take them into
> the upstream.  If there are major concerns about that, please let me know.
> 
> The issue at hand is that some platforms with Thunderbolt controllers won't
> boot if there are any Thunderbolt devices connected to them at boot time (if
> the devices are connected later, everything works as expected).  That turns
> out to be related to a complicated sequence of events involving the platform
> firmware which needs to happen in exactly the right order at the right time
> for things to work and that requires GPEs to be enabled before enumerating
> the PCI bus.
> 
> The first patch changes ACPICA to check the status of runtime GPEs before
> enabling them for the first time in order to avoid missing events (that
> is key for edge-triggered GPEs) and to process them early enough.
> 
> The second one makes it possible to change the ordering of initialization
> between GPEs and devices, and the third one actually changes that ordering.
> 
> The patches are based on Mika's work, so kudos to him.

Thank you for taking care of this! I've tested the series on Intel Skull
Canyon NUC, Dell XPS 9350, 9550 and 9365, and it fixes the issue on all
of them.

Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web