Hi Yu, On Mon, Oct 26, 2015 at 01:33:10AM +0000, Chen, Yu C wrote: > Hi, Fengguang, > I've forgotten to add --thread-shallow when doing git format-patch, thanks!
Never mind, --thread-shallow helps but won't be unnecessary. I'll improve the patchset detection logic. Thanks, Fengguang > > -----Original Message----- > > From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm- > > ow...@vger.kernel.org] On Behalf Of Fengguang Wu > > Sent: Monday, October 26, 2015 9:22 AM > > To: Chen, Yu C > > Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang, Rui; > > Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > > p...@vger.kernel.org; sta...@vger.kernel.org; Li, Philip > > Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting for events > > > > On Sun, Oct 25, 2015 at 10:08:29AM +0800, Chen, Yu C wrote: > > > This should not be a valid warning IMO, because PATCH 2/3 is based on > > > PATCH 1/3, and the warning of implicit declaration is defined in PATCH > > > 1/3. > > > > Yes sorry, the robot treats the patchset as 3 independent patches: > > > > 2754 N L Oct 25 Chen Yu ( 34:0) [PATCH 2/3][v2] ACPI: Using > > correct irq > > when waiting for events > > 2756 N L Oct 25 Chen Yu ( 52:0) [PATCH 3/3][v2] ACPI / PM: Fix > > incorrect > > wakeup irq setting before suspend-to-idle > > 2757 N L Oct 25 Chen Yu ( 75:0) [PATCH 1/3][v2] ACPI: Using > > correct irq > > when uninstalling acpi irq handler > > > > And the root cause is, the 3 patches are likely sent one by one _out of > > order_. > > And there is no in-reply-to field to help reorder them into a logical > > patchset. > > > > Thanks, > > Fengguang > > > > > > -----Original Message----- > > > > From: lkp > > > > Sent: Sunday, October 25, 2015 1:19 AM > > > > To: Chen, Yu C > > > > Cc: kbuild-...@01.org; r...@rjwysocki.net; l...@kernel.org; Zhang, > > > > Rui; Zheng, Lv; linux-a...@vger.kernel.org; > > > > linux-kernel@vger.kernel.org; linux- p...@vger.kernel.org; Chen, Yu C; > > > > sta...@vger.kernel.org > > > > Subject: Re: [PATCH 2/3][v2] ACPI: Using correct irq when waiting > > > > for events > > > > > > > > Hi Chen, > > > > > > > > [auto build test ERROR on pm/linux-next -- if it's inappropriate > > > > base, please suggest rules for selecting the more suitable base] > > > > > > > > url: https://github.com/0day-ci/linux/commits/Chen-Yu/ACPI-Using- > > > > correct-irq-when-waiting-for-events/20151025-010210 > > > > config: x86_64-randconfig-x015-201543 (attached as .config) > > > > reproduce: > > > > # save the attached .config to linux build tree > > > > make ARCH=x86_64 > > > > > > > > All error/warnings (new ones prefixed by >>): > > > > > > > > In file included from include/uapi/linux/stddef.h:1:0, > > > > from include/linux/stddef.h:4, > > > > from include/uapi/linux/posix_types.h:4, > > > > from include/uapi/linux/types.h:13, > > > > from include/linux/types.h:5, > > > > from include/linux/list.h:4, > > > > from include/linux/module.h:9, > > > > from drivers/acpi/osl.c:26: > > > > drivers/acpi/osl.c: In function 'acpi_os_wait_events_complete': > > > > >> drivers/acpi/osl.c:1183:6: error: implicit declaration of > > > > >> function > > > > 'acpi_sci_irq_valid' [-Werror=implicit-function-declaration] > > > > if (acpi_sci_irq_valid()) > > > > ^ > > > > include/linux/compiler.h:147:28: note: in definition of macro > > > > '__trace_if' > > > > if (__builtin_constant_p((cond)) ? !!(cond) : \ > > > > ^ > > > > >> drivers/acpi/osl.c:1183:2: note: in expansion of macro 'if' > > > > if (acpi_sci_irq_valid()) > > > > ^ > > > > >> drivers/acpi/osl.c:1184:23: error: 'acpi_sci_irq' undeclared > > > > >> (first use in this > > > > function) > > > > synchronize_hardirq(acpi_sci_irq); > > > > ^ > > > > drivers/acpi/osl.c:1184:23: note: each undeclared identifier is > > > > reported only once for each function it appears in > > > > cc1: some warnings being treated as errors > > > > > > > > vim +/acpi_sci_irq_valid +1183 drivers/acpi/osl.c > > > > > > > > 1177 void acpi_os_wait_events_complete(void) > > > > 1178 { > > > > 1179 /* > > > > 1180 * Make sure the GPE handler or the fixed event > > handler is > > > > not used > > > > 1181 * on another CPU after removal. > > > > 1182 */ > > > > > 1183 if (acpi_sci_irq_valid()) > > > > > 1184 synchronize_hardirq(acpi_sci_irq); > > > > 1185 flush_workqueue(kacpid_wq); > > > > 1186 flush_workqueue(kacpi_notify_wq); > > > > 1187 } > > > > > > > > --- > > > > 0-DAY kernel test infrastructure Open Source Technology > > > > Center > > > > https://lists.01.org/pipermail/kbuild-all Intel > > > > Corporation > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-pm" in the > > body of a message to majord...@vger.kernel.org More majordomo info at > > http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
