Hi All,
The purpose of this series is to address a power button wakeup issue on
some platforms where EC events aren't looked for early enough after
wakeup from suspend-to-idle.
The first patch modifies acpi_ev_detect_gpe() to compute a gpe_event_info
if NULL is passed as its second argument and adds a wrapper around it that
is used in the second patch.
The second patch checks the EC GPE in-line after detecting an SCI wakeup
to avoid missing the wakeup event.
Thanks,
Rafael
From: Rafael J. Wysocki <[email protected]>
On platforms where the Low Power S0 Idle _DSM interface is used,
on wakeup from suspend-to-idle, when it is known that the ACPI SCI
has triggered while suspended, dispatch the EC GPE in order to catch
all EC events that may have triggered the wakeup before carrying out
the noirq phase of device resume.
That is needed to handle power button wakeup on some platforms where
the EC goes into a low-power mode during suspend-to-idle and while in
that mode it will discard events after a timeout. If that timeout is
shorter than the time it takes to complete the noirq resume of
devices, looking for EC events after the latter is too late.
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reported-by: Zhang Rui <[email protected]>
Tested-by: Wendy Wang <[email protected]>
---
drivers/acpi/ec.c | 6 ++++++
drivers/acpi/internal.h | 1 +
drivers/acpi/sleep.c | 7 +++++++
3 files changed, 14 insertions(+)
Index: linux-pm/drivers/acpi/ec.c
===================================================================
--- linux-pm.orig/drivers/acpi/ec.c
+++ linux-pm/drivers/acpi/ec.c
@@ -1034,6 +1034,12 @@ void acpi_ec_unblock_transactions(void)
acpi_ec_start(first_ec, true);
}
+void acpi_ec_dispatch_gpe(void)
+{
+ if (first_ec)
+ acpi_dispatch_gpe(NULL, first_ec->gpe);
+}
+
/* --------------------------------------------------------------------------
Event Management
-------------------------------------------------------------------------- */
Index: linux-pm/drivers/acpi/internal.h
===================================================================
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -188,6 +188,7 @@ int acpi_ec_ecdt_probe(void);
int acpi_ec_dsdt_probe(void);
void acpi_ec_block_transactions(void);
void acpi_ec_unblock_transactions(void);
+void acpi_ec_dispatch_gpe(void);
int acpi_ec_add_query_handler(struct acpi_ec *ec, u8 query_bit,
acpi_handle handle, acpi_ec_query_func func,
void *data);
Index: linux-pm/drivers/acpi/sleep.c
===================================================================
--- linux-pm.orig/drivers/acpi/sleep.c
+++ linux-pm/drivers/acpi/sleep.c
@@ -989,6 +989,13 @@ static void acpi_s2idle_wake(void)
!irqd_is_wakeup_armed(irq_get_irq_data(acpi_sci_irq))) {
pm_system_cancel_wakeup();
s2idle_wakeup = true;
+ /*
+ * On some platforms with the LPS0 _DSM device noirq resume
+ * takes too much time for EC wakeup events to survive, so look
+ * for them now.
+ */
+ if (lps0_device_handle)
+ acpi_ec_dispatch_gpe();
}
}
From: Rafael J. Wysocki <[email protected]>
Introduce acpi_dispatch_gpe() as a wrapper around acpi_ev_detect_gpe()
for checking if the given GPE (as represented by a GPE device handle
and a GPE number) is currently active and dispatching it (if that's
the case) outside of interrupt context.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/acpica/evgpe.c | 6 ++++++
drivers/acpi/acpica/evxfgpe.c | 22 ++++++++++++++++++++++
include/acpi/acpixf.h | 1 +
3 files changed, 29 insertions(+)
Index: linux-pm/drivers/acpi/acpica/evgpe.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpica/evgpe.c
+++ linux-pm/drivers/acpi/acpica/evgpe.c
@@ -634,6 +634,12 @@ acpi_ev_detect_gpe(struct acpi_namespace
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+ if (!gpe_event_info) {
+ gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+ if (!gpe_event_info)
+ goto error_exit;
+ }
+
/* Get the info block for the entire GPE register */
gpe_register_info = gpe_event_info->register_info;
Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
+++ linux-pm/drivers/acpi/acpica/evxfgpe.c
@@ -639,6 +639,28 @@ ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
/*******************************************************************************
*
+ * FUNCTION: acpi_gispatch_gpe
+ *
+ * PARAMETERS: gpe_device - Parent GPE Device. NULL for GPE0/GPE1
+ * gpe_number - GPE level within the GPE block
+ *
+ * RETURN: None
+ *
+ * DESCRIPTION: Detect and dispatch a General Purpose Event to either a function
+ * (e.g. EC) or method (e.g. _Lxx/_Exx) handler.
+ *
+ ******************************************************************************/
+void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number)
+{
+ ACPI_FUNCTION_TRACE(acpi_dispatch_gpe);
+
+ acpi_ev_detect_gpe(gpe_device, NULL, gpe_number);
+}
+
+ACPI_EXPORT_SYMBOL(acpi_dispatch_gpe)
+
+/*******************************************************************************
+ *
* FUNCTION: acpi_finish_gpe
*
* PARAMETERS: gpe_device - Namespace node for the GPE Block
Index: linux-pm/include/acpi/acpixf.h
===================================================================
--- linux-pm.orig/include/acpi/acpixf.h
+++ linux-pm/include/acpi/acpixf.h
@@ -753,6 +753,7 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_sta
u32 gpe_number,
acpi_event_status
*event_status))
+void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number);
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_disable_all_gpes(void))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_enable_all_runtime_gpes(void))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_enable_all_wakeup_gpes(void))
I'm not sure why this is necessary, please explain.
Is the implication here that some driver is going to poll on acpi_dispatch_gpe?
Bob
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:[email protected]]
> Sent: Wednesday, May 16, 2018 5:12 AM
> To: Linux ACPI <[email protected]>
> Cc: Zhang, Rui <[email protected]>; Linux PM <linux-
> [email protected]>; LKML <[email protected]>; Schmauss, Erik
> <[email protected]>; Moore, Robert <[email protected]>; Wang,
> Wendy <[email protected]>
> Subject: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()
>
> From: Rafael J. Wysocki <[email protected]>
>
> Introduce acpi_dispatch_gpe() as a wrapper around acpi_ev_detect_gpe()
> for checking if the given GPE (as represented by a GPE device handle and
> a GPE number) is currently active and dispatching it (if that's the
> case) outside of interrupt context.
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> ---
> drivers/acpi/acpica/evgpe.c | 6 ++++++
> drivers/acpi/acpica/evxfgpe.c | 22 ++++++++++++++++++++++
> include/acpi/acpixf.h | 1 +
> 3 files changed, 29 insertions(+)
>
> Index: linux-pm/drivers/acpi/acpica/evgpe.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/acpica/evgpe.c
> +++ linux-pm/drivers/acpi/acpica/evgpe.c
> @@ -634,6 +634,12 @@ acpi_ev_detect_gpe(struct acpi_namespace
>
> flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
>
> + if (!gpe_event_info) {
> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device,
> gpe_number);
> + if (!gpe_event_info)
> + goto error_exit;
> + }
> +
> /* Get the info block for the entire GPE register */
>
> gpe_register_info = gpe_event_info->register_info;
> Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> @@ -639,6 +639,28 @@ ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
>
>
> /***********************************************************************
> ********
> *
> + * FUNCTION: acpi_gispatch_gpe
> + *
> + * PARAMETERS: gpe_device - Parent GPE Device. NULL for
> GPE0/GPE1
> + * gpe_number - GPE level within the GPE block
> + *
> + * RETURN: None
> + *
> + * DESCRIPTION: Detect and dispatch a General Purpose Event to either a
> function
> + * (e.g. EC) or method (e.g. _Lxx/_Exx) handler.
> + *
> +
> +***********************************************************************
> +*******/ void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number)
> +{
> + ACPI_FUNCTION_TRACE(acpi_dispatch_gpe);
> +
> + acpi_ev_detect_gpe(gpe_device, NULL, gpe_number); }
> +
> +ACPI_EXPORT_SYMBOL(acpi_dispatch_gpe)
> +
> +/**********************************************************************
> +*********
> + *
> * FUNCTION: acpi_finish_gpe
> *
> * PARAMETERS: gpe_device - Namespace node for the GPE Block
> Index: linux-pm/include/acpi/acpixf.h
> ===================================================================
> --- linux-pm.orig/include/acpi/acpixf.h
> +++ linux-pm/include/acpi/acpixf.h
> @@ -753,6 +753,7 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_sta
> u32 gpe_number,
> acpi_event_status
> *event_status))
> +void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number);
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_disable_all_gpes(void))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_runtime_gpes(void))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_wakeup_gpes(void))
On Wed, May 16, 2018 at 9:18 PM, Moore, Robert <[email protected]> wrote:
> I'm not sure why this is necessary, please explain.
>
> Is the implication here that some driver is going to poll on acpi_dispatch_gpe?
Not a driver, but the core part of resume from suspend-to-idle and it
needs to call it for the EC GPE specifically to avoid missing events
that will be discarded on some platforms if the EC is not poked at
within specific time since when the GPE status changed.
IOW, the use case is in patch [2/2]. :-)
I do realize, however, that you may not want this upstream as it is
strictly Linux-specific and will probably stay this way forever
(suspend-to-idle is a Linux concept and I'm not aware of any OSes
doing it).
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:[email protected]]
>> Sent: Wednesday, May 16, 2018 5:12 AM
>> To: Linux ACPI <[email protected]>
>> Cc: Zhang, Rui <[email protected]>; Linux PM <linux-
>> [email protected]>; LKML <[email protected]>; Schmauss, Erik
>> <[email protected]>; Moore, Robert <[email protected]>; Wang,
>> Wendy <[email protected]>
>> Subject: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()
>>
>> From: Rafael J. Wysocki <[email protected]>
>>
>> Introduce acpi_dispatch_gpe() as a wrapper around acpi_ev_detect_gpe()
>> for checking if the given GPE (as represented by a GPE device handle and
>> a GPE number) is currently active and dispatching it (if that's the
>> case) outside of interrupt context.
>>
>> Signed-off-by: Rafael J. Wysocki <[email protected]>
>> ---
>> drivers/acpi/acpica/evgpe.c | 6 ++++++
>> drivers/acpi/acpica/evxfgpe.c | 22 ++++++++++++++++++++++
>> include/acpi/acpixf.h | 1 +
>> 3 files changed, 29 insertions(+)
>>
>> Index: linux-pm/drivers/acpi/acpica/evgpe.c
>> ===================================================================
>> --- linux-pm.orig/drivers/acpi/acpica/evgpe.c
>> +++ linux-pm/drivers/acpi/acpica/evgpe.c
>> @@ -634,6 +634,12 @@ acpi_ev_detect_gpe(struct acpi_namespace
>>
>> flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
>>
>> + if (!gpe_event_info) {
>> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device,
>> gpe_number);
>> + if (!gpe_event_info)
>> + goto error_exit;
>> + }
>> +
>> /* Get the info block for the entire GPE register */
>>
>> gpe_register_info = gpe_event_info->register_info;
>> Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
>> ===================================================================
>> --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
>> +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
>> @@ -639,6 +639,28 @@ ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
>>
>>
>> /***********************************************************************
>> ********
>> *
>> + * FUNCTION: acpi_gispatch_gpe
>> + *
>> + * PARAMETERS: gpe_device - Parent GPE Device. NULL for
>> GPE0/GPE1
>> + * gpe_number - GPE level within the GPE block
>> + *
>> + * RETURN: None
>> + *
>> + * DESCRIPTION: Detect and dispatch a General Purpose Event to either a
>> function
>> + * (e.g. EC) or method (e.g. _Lxx/_Exx) handler.
>> + *
>> +
>> +***********************************************************************
>> +*******/ void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number)
>> +{
>> + ACPI_FUNCTION_TRACE(acpi_dispatch_gpe);
>> +
>> + acpi_ev_detect_gpe(gpe_device, NULL, gpe_number); }
>> +
>> +ACPI_EXPORT_SYMBOL(acpi_dispatch_gpe)
>> +
>> +/**********************************************************************
>> +*********
>> + *
>> * FUNCTION: acpi_finish_gpe
>> *
>> * PARAMETERS: gpe_device - Namespace node for the GPE Block
>> Index: linux-pm/include/acpi/acpixf.h
>> ===================================================================
>> --- linux-pm.orig/include/acpi/acpixf.h
>> +++ linux-pm/include/acpi/acpixf.h
>> @@ -753,6 +753,7 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_sta
>> u32 gpe_number,
>> acpi_event_status
>> *event_status))
>> +void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number);
>> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
>> acpi_disable_all_gpes(void))
>> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
>> acpi_enable_all_runtime_gpes(void))
>> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
>> acpi_enable_all_wakeup_gpes(void))
>
Hi Rafael,
I love your patch! Yet something to improve:
[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.17-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafael-J-Wysocki/ACPI-PM-Dispatch-EC-GPE-early-on-s2idle-resume-if-LPS0-_DSM-is-used/20180518-070817
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
drivers/acpi/ec.o: In function `acpi_ec_dispatch_gpe':
>> ec.c:(.text+0x239c): undefined reference to `acpi_dispatch_gpe'
ec.c:(.text+0x239c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `acpi_dispatch_gpe'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Rafael,
On 18 May 2018 at 08:10, kbuild test robot <[email protected]> wrote:
> Hi Rafael,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on pm/linux-next]
> [also build test ERROR on v4.17-rc5]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Rafael-J-Wysocki/ACPI-PM-Dispatch-EC-GPE-early-on-s2idle-resume-if-LPS0-_DSM-is-used/20180518-070817
> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
> drivers/acpi/ec.o: In function `acpi_ec_dispatch_gpe':
>>> ec.c:(.text+0x239c): undefined reference to `acpi_dispatch_gpe'
> ec.c:(.text+0x239c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `acpi_dispatch_gpe'
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
This breaks arm64 builds, would you mind to drop the offending patch
from your linux-next branch?
In case you haven't got time to check, I think the problem is caused
by CONFIG_ACPI_REDUCED_HARDWARE_ONLY being set for arm64 builds. I can
try to fix the problem, if you are busy and want help with it?
Kind regards
Uffe
On Fri, May 25, 2018 at 8:49 AM, Ulf Hansson <[email protected]> wrote:
> Rafael,
>
> On 18 May 2018 at 08:10, kbuild test robot <[email protected]> wrote:
>> Hi Rafael,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on pm/linux-next]
>> [also build test ERROR on v4.17-rc5]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>
>> url: https://github.com/0day-ci/linux/commits/Rafael-J-Wysocki/ACPI-PM-Dispatch-EC-GPE-early-on-s2idle-resume-if-LPS0-_DSM-is-used/20180518-070817
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
>> config: arm64-defconfig (attached as .config)
>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> make.cross ARCH=arm64
>>
>> All errors (new ones prefixed by >>):
>>
>> drivers/acpi/ec.o: In function `acpi_ec_dispatch_gpe':
>>>> ec.c:(.text+0x239c): undefined reference to `acpi_dispatch_gpe'
>> ec.c:(.text+0x239c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `acpi_dispatch_gpe'
>>
>> ---
>> 0-DAY kernel test infrastructure Open Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
> This breaks arm64 builds, would you mind to drop the offending patch
> from your linux-next branch?
Not really, but I can fix it.
> In case you haven't got time to check, I think the problem is caused
> by CONFIG_ACPI_REDUCED_HARDWARE_ONLY being set for arm64 builds. I can
> try to fix the problem, if you are busy and want help with it?
I'll have a look.
On Fri, May 25, 2018 at 10:08 AM, Rafael J. Wysocki <[email protected]> wrote:
> On Fri, May 25, 2018 at 8:49 AM, Ulf Hansson <[email protected]> wrote:
>> Rafael,
>>
>> On 18 May 2018 at 08:10, kbuild test robot <[email protected]> wrote:
>>> Hi Rafael,
>>>
>>> I love your patch! Yet something to improve:
>>>
>>> [auto build test ERROR on pm/linux-next]
>>> [also build test ERROR on v4.17-rc5]
>>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>>
>>> url: https://github.com/0day-ci/linux/commits/Rafael-J-Wysocki/ACPI-PM-Dispatch-EC-GPE-early-on-s2idle-resume-if-LPS0-_DSM-is-used/20180518-070817
>>> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
>>> config: arm64-defconfig (attached as .config)
>>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>>> reproduce:
>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> # save the attached .config to linux build tree
>>> make.cross ARCH=arm64
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>> drivers/acpi/ec.o: In function `acpi_ec_dispatch_gpe':
>>>>> ec.c:(.text+0x239c): undefined reference to `acpi_dispatch_gpe'
>>> ec.c:(.text+0x239c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `acpi_dispatch_gpe'
>>>
>>> ---
>>> 0-DAY kernel test infrastructure Open Source Technology Center
>>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>>
>> This breaks arm64 builds, would you mind to drop the offending patch
>> from your linux-next branch?
>
> Not really, but I can fix it.
Should be fixed now, sorry for the breakage.
On 25 May 2018 at 10:48, Rafael J. Wysocki <[email protected]> wrote:
> On Fri, May 25, 2018 at 10:08 AM, Rafael J. Wysocki <[email protected]> wrote:
>> On Fri, May 25, 2018 at 8:49 AM, Ulf Hansson <[email protected]> wrote:
>>> Rafael,
>>>
>>> On 18 May 2018 at 08:10, kbuild test robot <[email protected]> wrote:
>>>> Hi Rafael,
>>>>
>>>> I love your patch! Yet something to improve:
>>>>
>>>> [auto build test ERROR on pm/linux-next]
>>>> [also build test ERROR on v4.17-rc5]
>>>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>>>
>>>> url: https://github.com/0day-ci/linux/commits/Rafael-J-Wysocki/ACPI-PM-Dispatch-EC-GPE-early-on-s2idle-resume-if-LPS0-_DSM-is-used/20180518-070817
>>>> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
>>>> config: arm64-defconfig (attached as .config)
>>>> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>>>> reproduce:
>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>>> chmod +x ~/bin/make.cross
>>>> # save the attached .config to linux build tree
>>>> make.cross ARCH=arm64
>>>>
>>>> All errors (new ones prefixed by >>):
>>>>
>>>> drivers/acpi/ec.o: In function `acpi_ec_dispatch_gpe':
>>>>>> ec.c:(.text+0x239c): undefined reference to `acpi_dispatch_gpe'
>>>> ec.c:(.text+0x239c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `acpi_dispatch_gpe'
>>>>
>>>> ---
>>>> 0-DAY kernel test infrastructure Open Source Technology Center
>>>> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>>>
>>> This breaks arm64 builds, would you mind to drop the offending patch
>>> from your linux-next branch?
>>
>> Not really, but I can fix it.
>
> Should be fixed now, sorry for the breakage.
Thanks, yes it builds fine now!
Kind regards
Uffe