* Build regression in next-20150331 @ 2015-03-31 18:39 Tyler Baker 2015-03-31 23:03 ` Rafael J. Wysocki 0 siblings, 1 reply; 11+ messages in thread From: Tyler Baker @ 2015-03-31 18:39 UTC (permalink / raw) To: linux-arm-kernel Hi Thomas, Rafael, I was notified this morning by the kernelci.org system that a new build error has been detected in next-20150331[0][1][2]. It seems that "clockevents: Remove CONFIG_GENERIC_CLOCKEVENTS_BUILD" c9439b1d6eb4ada5c2faf3970ac0d2bc4bd20e14 is the culprit. Initially, I reported these failures to John Stultz and his response is below. *snip* I suspect we either need to enable GENERIC_CLOCKEVENTS on those three hardware types, or if that's not possible, rework the definitions. Or something like (copy-paste whitespace corruption below.. only for reference, don't apply): diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h index 2a1563a..6da40c0 100644 --- a/kernel/time/tick-internal.h +++ b/kernel/time/tick-internal.h @@ -107,12 +107,13 @@ static inline void tick_resume_broadcast(void) { } static inline bool tick_resume_check_broadcast(void) { return false; } static inline void tick_broadcast_init(void) { } static inline int tick_broadcast_update_freq(struct clock_event_device *dev, u32 freq) { return -ENODEV; } - +#ifdef CONFIG_GENERIC_CLOCKEVENTS /* Set the periodic handler in non broadcast mode */ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) { dev->event_handler = tick_handle_periodic; } +#endif #endif /* !BROADCAST */ *snip* Any chance either of you can reproduce this issue on your end? Cheers, Tyler [0] http://storage.kernelci.org/next/next-20150331/arm-ep93xx_defconfig/build.log [1] http://storage.kernelci.org/next/next-20150331/arm-ebsa110_defconfig/build.log [2] http://storage.kernelci.org/next/next-20150331/arm-rpc_defconfig/build.log ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-03-31 18:39 Build regression in next-20150331 Tyler Baker @ 2015-03-31 23:03 ` Rafael J. Wysocki 2015-03-31 23:27 ` Rafael J. Wysocki 0 siblings, 1 reply; 11+ messages in thread From: Rafael J. Wysocki @ 2015-03-31 23:03 UTC (permalink / raw) To: linux-arm-kernel On Tuesday, March 31, 2015 11:39:37 AM Tyler Baker wrote: > Hi Thomas, Rafael, > > I was notified this morning by the kernelci.org system that a new > build error has been detected in next-20150331[0][1][2]. It seems that > "clockevents: Remove CONFIG_GENERIC_CLOCKEVENTS_BUILD" > c9439b1d6eb4ada5c2faf3970ac0d2bc4bd20e14 is the culprit. > > Initially, I reported these failures to John Stultz and his response is below. > > *snip* > > I suspect we either need to enable GENERIC_CLOCKEVENTS on those three > hardware types, or if that's not possible, rework the definitions. > > Or something like (copy-paste whitespace corruption below.. only for > reference, don't apply): > > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h > index 2a1563a..6da40c0 100644 > --- a/kernel/time/tick-internal.h > +++ b/kernel/time/tick-internal.h > @@ -107,12 +107,13 @@ static inline void tick_resume_broadcast(void) { } > static inline bool tick_resume_check_broadcast(void) { return false; } > static inline void tick_broadcast_init(void) { } > static inline int tick_broadcast_update_freq(struct > clock_event_device *dev, u32 freq) { return -ENODEV; } > - > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > /* Set the periodic handler in non broadcast mode */ > static inline void tick_set_periodic_handler(struct > clock_event_device *dev, int broadcast) > { > dev->event_handler = tick_handle_periodic; > } > +#endif > #endif /* !BROADCAST */ > > *snip* > > Any chance either of you can reproduce this issue on your end? Can you please tell me if the appended patch helps? Rafael --- kernel/time/tick-internal.h | 4 ++++ 1 file changed, 4 insertions(+) Index: linux-pm/kernel/time/tick-internal.h =================================================================== --- linux-pm.orig/kernel/time/tick-internal.h +++ linux-pm/kernel/time/tick-internal.h @@ -107,11 +107,15 @@ static inline bool tick_resume_check_bro static inline void tick_broadcast_init(void) { } static inline int tick_broadcast_update_freq(struct clock_event_device *dev, u32 freq) { return -ENODEV; } +#ifdef CONFIG_GENERIC_CLOCKEVENTS /* Set the periodic handler in non broadcast mode */ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) { dev->event_handler = tick_handle_periodic; } +#else +static void tick_handle_periodic(struct clock_event_device *dev) { } +#endif #endif /* !BROADCAST */ /* Functions related to oneshot broadcasting */ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-03-31 23:03 ` Rafael J. Wysocki @ 2015-03-31 23:27 ` Rafael J. Wysocki 2015-04-01 3:37 ` Tyler Baker 0 siblings, 1 reply; 11+ messages in thread From: Rafael J. Wysocki @ 2015-03-31 23:27 UTC (permalink / raw) To: linux-arm-kernel On Wednesday, April 01, 2015 01:03:52 AM Rafael J. Wysocki wrote: > On Tuesday, March 31, 2015 11:39:37 AM Tyler Baker wrote: > > Hi Thomas, Rafael, > > > > I was notified this morning by the kernelci.org system that a new > > build error has been detected in next-20150331[0][1][2]. It seems that > > "clockevents: Remove CONFIG_GENERIC_CLOCKEVENTS_BUILD" > > c9439b1d6eb4ada5c2faf3970ac0d2bc4bd20e14 is the culprit. > > > > Initially, I reported these failures to John Stultz and his response is below. > > > > *snip* > > > > I suspect we either need to enable GENERIC_CLOCKEVENTS on those three > > hardware types, or if that's not possible, rework the definitions. > > > > Or something like (copy-paste whitespace corruption below.. only for > > reference, don't apply): > > > > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h > > index 2a1563a..6da40c0 100644 > > --- a/kernel/time/tick-internal.h > > +++ b/kernel/time/tick-internal.h > > @@ -107,12 +107,13 @@ static inline void tick_resume_broadcast(void) { } > > static inline bool tick_resume_check_broadcast(void) { return false; } > > static inline void tick_broadcast_init(void) { } > > static inline int tick_broadcast_update_freq(struct > > clock_event_device *dev, u32 freq) { return -ENODEV; } > > - > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > > /* Set the periodic handler in non broadcast mode */ > > static inline void tick_set_periodic_handler(struct > > clock_event_device *dev, int broadcast) > > { > > dev->event_handler = tick_handle_periodic; > > } > > +#endif > > #endif /* !BROADCAST */ > > > > *snip* > > > > Any chance either of you can reproduce this issue on your end? > > Can you please tell me if the appended patch helps? Scratch that, wrong patch. Please try the one below instead. Rafael --- kernel/time/tick-internal.h | 2 ++ 1 file changed, 2 insertions(+) Index: linux-pm/kernel/time/tick-internal.h =================================================================== --- linux-pm.orig/kernel/time/tick-internal.h +++ linux-pm/kernel/time/tick-internal.h @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_ /* Set the periodic handler in non broadcast mode */ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) { +#ifdef CONFIG_GENERIC_CLOCKEVENTS dev->event_handler = tick_handle_periodic; +#endif } #endif /* !BROADCAST */ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-03-31 23:27 ` Rafael J. Wysocki @ 2015-04-01 3:37 ` Tyler Baker 2015-04-01 21:46 ` Rafael J. Wysocki 0 siblings, 1 reply; 11+ messages in thread From: Tyler Baker @ 2015-04-01 3:37 UTC (permalink / raw) To: linux-arm-kernel Hi Rafael, On 31 March 2015 at 16:27, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Wednesday, April 01, 2015 01:03:52 AM Rafael J. Wysocki wrote: >> On Tuesday, March 31, 2015 11:39:37 AM Tyler Baker wrote: >> > Hi Thomas, Rafael, >> > >> > I was notified this morning by the kernelci.org system that a new >> > build error has been detected in next-20150331[0][1][2]. It seems that >> > "clockevents: Remove CONFIG_GENERIC_CLOCKEVENTS_BUILD" >> > c9439b1d6eb4ada5c2faf3970ac0d2bc4bd20e14 is the culprit. >> > >> > Initially, I reported these failures to John Stultz and his response is below. >> > >> > *snip* >> > >> > I suspect we either need to enable GENERIC_CLOCKEVENTS on those three >> > hardware types, or if that's not possible, rework the definitions. >> > >> > Or something like (copy-paste whitespace corruption below.. only for >> > reference, don't apply): >> > >> > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h >> > index 2a1563a..6da40c0 100644 >> > --- a/kernel/time/tick-internal.h >> > +++ b/kernel/time/tick-internal.h >> > @@ -107,12 +107,13 @@ static inline void tick_resume_broadcast(void) { } >> > static inline bool tick_resume_check_broadcast(void) { return false; } >> > static inline void tick_broadcast_init(void) { } >> > static inline int tick_broadcast_update_freq(struct >> > clock_event_device *dev, u32 freq) { return -ENODEV; } >> > - >> > +#ifdef CONFIG_GENERIC_CLOCKEVENTS >> > /* Set the periodic handler in non broadcast mode */ >> > static inline void tick_set_periodic_handler(struct >> > clock_event_device *dev, int broadcast) >> > { >> > dev->event_handler = tick_handle_periodic; >> > } >> > +#endif >> > #endif /* !BROADCAST */ >> > >> > *snip* >> > >> > Any chance either of you can reproduce this issue on your end? >> >> Can you please tell me if the appended patch helps? > > Scratch that, wrong patch. > > Please try the one below instead. > > Rafael > > > --- > kernel/time/tick-internal.h | 2 ++ > 1 file changed, 2 insertions(+) > > Index: linux-pm/kernel/time/tick-internal.h > =================================================================== > --- linux-pm.orig/kernel/time/tick-internal.h > +++ linux-pm/kernel/time/tick-internal.h > @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_ > /* Set the periodic handler in non broadcast mode */ > static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) > { > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > dev->event_handler = tick_handle_periodic; > +#endif > } > #endif /* !BROADCAST */ Thanks for the quick response. I've applied this patch on top of next-20150331 and I can confirm this fixes the build error reported in this thread. The test results can be found here[0]. > > Cheers, Tyler [0] http://kernelci.org/build/tbaker/kernel/v4.0-rc6-7993-gb448f49+gcc-linaro-4.9-2015.02/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-04-01 3:37 ` Tyler Baker @ 2015-04-01 21:46 ` Rafael J. Wysocki 2015-04-02 8:29 ` Peter Zijlstra 0 siblings, 1 reply; 11+ messages in thread From: Rafael J. Wysocki @ 2015-04-01 21:46 UTC (permalink / raw) To: linux-arm-kernel On Tuesday, March 31, 2015 08:37:32 PM Tyler Baker wrote: > Hi Rafael, > > On 31 March 2015 at 16:27, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Wednesday, April 01, 2015 01:03:52 AM Rafael J. Wysocki wrote: > >> On Tuesday, March 31, 2015 11:39:37 AM Tyler Baker wrote: > >> > Hi Thomas, Rafael, > >> > > >> > I was notified this morning by the kernelci.org system that a new > >> > build error has been detected in next-20150331[0][1][2]. It seems that > >> > "clockevents: Remove CONFIG_GENERIC_CLOCKEVENTS_BUILD" > >> > c9439b1d6eb4ada5c2faf3970ac0d2bc4bd20e14 is the culprit. [cut] > > > > Please try the one below instead. > > > > Rafael > > > > > > --- > > kernel/time/tick-internal.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > Index: linux-pm/kernel/time/tick-internal.h > > =================================================================== > > --- linux-pm.orig/kernel/time/tick-internal.h > > +++ linux-pm/kernel/time/tick-internal.h > > @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_ > > /* Set the periodic handler in non broadcast mode */ > > static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) > > { > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > > dev->event_handler = tick_handle_periodic; > > +#endif > > } > > #endif /* !BROADCAST */ > > Thanks for the quick response. I've applied this patch on top of > next-20150331 and I can confirm this fixes the build error reported in > this thread. The test results can be found here[0]. OK, thanks for verifying. Peter, do you think the above is acceptable or do I need to do anything more sophisticated to fix this? [The alternative would be probably to prepare an empty definition of tick_handle_periodic() for CONFIG_GENERIC_CLOCKEVENTS and move the definition of struct clock_event_device from under that Kconfig option.] Rafael ^ permalink raw reply [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-04-01 21:46 ` Rafael J. Wysocki @ 2015-04-02 8:29 ` Peter Zijlstra 2015-04-02 22:09 ` Rafael J. Wysocki 2015-04-03 2:59 ` Tyler Baker 0 siblings, 2 replies; 11+ messages in thread From: Peter Zijlstra @ 2015-04-02 8:29 UTC (permalink / raw) To: linux-arm-kernel On Wed, Apr 01, 2015 at 11:46:10PM +0200, Rafael J. Wysocki wrote: > > > --- > > > kernel/time/tick-internal.h | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > Index: linux-pm/kernel/time/tick-internal.h > > > =================================================================== > > > --- linux-pm.orig/kernel/time/tick-internal.h > > > +++ linux-pm/kernel/time/tick-internal.h > > > @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_ > > > /* Set the periodic handler in non broadcast mode */ > > > static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) > > > { > > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > > > dev->event_handler = tick_handle_periodic; > > > +#endif > > > } > > > #endif /* !BROADCAST */ > Peter, do you think the above is acceptable or do I need to do anything more > sophisticated to fix this? [The alternative would be probably to prepare an > empty definition of tick_handle_periodic() for CONFIG_GENERIC_CLOCKEVENTS and > move the definition of struct clock_event_device from under that Kconfig > option.] Does not something like the below make more sense? The entire broadcast thing doesn't make sense if we don't have generic_clockevents. Should we wrap more in generic_clockevents there? --- kernel/time/tick-internal.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h index 2a1563a..5569e65 100644 --- a/kernel/time/tick-internal.h +++ b/kernel/time/tick-internal.h @@ -81,6 +81,7 @@ static inline int tick_check_oneshot_change(int allow_nohz) { return 0; } #endif /* !TICK_ONESHOT */ /* Broadcasting support */ +#ifdef CONFIG_GENERIC_CLOCKEVENTS #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu); extern void tick_install_broadcast_device(struct clock_event_device *dev); @@ -114,6 +115,7 @@ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int dev->event_handler = tick_handle_periodic; } #endif /* !BROADCAST */ +#endif /* GENERIC */ /* Functions related to oneshot broadcasting */ #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT) ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-04-02 8:29 ` Peter Zijlstra @ 2015-04-02 22:09 ` Rafael J. Wysocki 2015-04-03 2:59 ` Tyler Baker 1 sibling, 0 replies; 11+ messages in thread From: Rafael J. Wysocki @ 2015-04-02 22:09 UTC (permalink / raw) To: linux-arm-kernel On Thursday, April 02, 2015 10:29:17 AM Peter Zijlstra wrote: > On Wed, Apr 01, 2015 at 11:46:10PM +0200, Rafael J. Wysocki wrote: > > > > > --- > > > > kernel/time/tick-internal.h | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > Index: linux-pm/kernel/time/tick-internal.h > > > > =================================================================== > > > > --- linux-pm.orig/kernel/time/tick-internal.h > > > > +++ linux-pm/kernel/time/tick-internal.h > > > > @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_ > > > > /* Set the periodic handler in non broadcast mode */ > > > > static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) > > > > { > > > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > > > > dev->event_handler = tick_handle_periodic; > > > > +#endif > > > > } > > > > #endif /* !BROADCAST */ > > > Peter, do you think the above is acceptable or do I need to do anything more > > sophisticated to fix this? [The alternative would be probably to prepare an > > empty definition of tick_handle_periodic() for CONFIG_GENERIC_CLOCKEVENTS and > > move the definition of struct clock_event_device from under that Kconfig > > option.] > > > Does not something like the below make more sense? The entire broadcast > thing doesn't make sense if we don't have generic_clockevents. > > Should we wrap more in generic_clockevents there? Well, it does make sense, but does it work? Tyler, can you please test the Peter's patch too? > --- > kernel/time/tick-internal.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h > index 2a1563a..5569e65 100644 > --- a/kernel/time/tick-internal.h > +++ b/kernel/time/tick-internal.h > @@ -81,6 +81,7 @@ static inline int tick_check_oneshot_change(int allow_nohz) { return 0; } > #endif /* !TICK_ONESHOT */ > > /* Broadcasting support */ > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST > extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu); > extern void tick_install_broadcast_device(struct clock_event_device *dev); > @@ -114,6 +115,7 @@ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int > dev->event_handler = tick_handle_periodic; > } > #endif /* !BROADCAST */ > +#endif /* GENERIC */ > > /* Functions related to oneshot broadcasting */ > #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT) -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-04-02 8:29 ` Peter Zijlstra 2015-04-02 22:09 ` Rafael J. Wysocki @ 2015-04-03 2:59 ` Tyler Baker 2015-04-03 11:07 ` Rafael J. Wysocki 1 sibling, 1 reply; 11+ messages in thread From: Tyler Baker @ 2015-04-03 2:59 UTC (permalink / raw) To: linux-arm-kernel On 2 April 2015 at 01:29, Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, Apr 01, 2015 at 11:46:10PM +0200, Rafael J. Wysocki wrote: > >> > > --- >> > > kernel/time/tick-internal.h | 2 ++ >> > > 1 file changed, 2 insertions(+) >> > > >> > > Index: linux-pm/kernel/time/tick-internal.h >> > > =================================================================== >> > > --- linux-pm.orig/kernel/time/tick-internal.h >> > > +++ linux-pm/kernel/time/tick-internal.h >> > > @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_ >> > > /* Set the periodic handler in non broadcast mode */ >> > > static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) >> > > { >> > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS >> > > dev->event_handler = tick_handle_periodic; >> > > +#endif >> > > } >> > > #endif /* !BROADCAST */ > >> Peter, do you think the above is acceptable or do I need to do anything more >> sophisticated to fix this? [The alternative would be probably to prepare an >> empty definition of tick_handle_periodic() for CONFIG_GENERIC_CLOCKEVENTS and >> move the definition of struct clock_event_device from under that Kconfig >> option.] > > > Does not something like the below make more sense? The entire broadcast > thing doesn't make sense if we don't have generic_clockevents. > > Should we wrap more in generic_clockevents there? > > --- > kernel/time/tick-internal.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h > index 2a1563a..5569e65 100644 > --- a/kernel/time/tick-internal.h > +++ b/kernel/time/tick-internal.h > @@ -81,6 +81,7 @@ static inline int tick_check_oneshot_change(int allow_nohz) { return 0; } > #endif /* !TICK_ONESHOT */ > > /* Broadcasting support */ > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST > extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu); > extern void tick_install_broadcast_device(struct clock_event_device *dev); > @@ -114,6 +115,7 @@ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int > dev->event_handler = tick_handle_periodic; > } > #endif /* !BROADCAST */ > +#endif /* GENERIC */ > > /* Functions related to oneshot broadcasting */ > #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT) Tested-by: Tyler Baker <tyler.baker@linaro.org> Looks good to me. Applied on top of next-20150402[0]: --- kernel/time/tick-internal.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h index 2a1563a..e332bb4 100644 --- a/kernel/time/tick-internal.h +++ b/kernel/time/tick-internal.h @@ -81,6 +81,7 @@ static inline int tick_check_oneshot_change(int allow_nohz) { return 0; } #endif /* !TICK_ONESHOT */ /* Broadcasting support */ +#ifdef CONFIG_GENERIC_CLOCKEVENTS #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu); extern void tick_install_broadcast_device(struct clock_event_device *dev); @@ -114,7 +115,7 @@ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int dev->event_handler = tick_handle_periodic; } #endif /* !BROADCAST */ +#endif /* GENERIC */ /* Functions related to oneshot broadcasting */ #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT) extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc); --- Tyler [0] http://kernelci.org/build/tbaker/kernel/v4.0-rc6-8742-g76c8cce3+gcc-linaro-4.9-2015.02/ ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-04-03 2:59 ` Tyler Baker @ 2015-04-03 11:07 ` Rafael J. Wysocki 2015-04-03 14:24 ` Peter Zijlstra 0 siblings, 1 reply; 11+ messages in thread From: Rafael J. Wysocki @ 2015-04-03 11:07 UTC (permalink / raw) To: linux-arm-kernel On Thursday, April 02, 2015 07:59:53 PM Tyler Baker wrote: > On 2 April 2015 at 01:29, Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, Apr 01, 2015 at 11:46:10PM +0200, Rafael J. Wysocki wrote: > > > >> > > --- > >> > > kernel/time/tick-internal.h | 2 ++ > >> > > 1 file changed, 2 insertions(+) > >> > > > >> > > Index: linux-pm/kernel/time/tick-internal.h > >> > > =================================================================== > >> > > --- linux-pm.orig/kernel/time/tick-internal.h > >> > > +++ linux-pm/kernel/time/tick-internal.h > >> > > @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_ > >> > > /* Set the periodic handler in non broadcast mode */ > >> > > static inline void tick_set_periodic_handler(struct clock_event_device *dev, int broadcast) > >> > > { > >> > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > >> > > dev->event_handler = tick_handle_periodic; > >> > > +#endif > >> > > } > >> > > #endif /* !BROADCAST */ > > > >> Peter, do you think the above is acceptable or do I need to do anything more > >> sophisticated to fix this? [The alternative would be probably to prepare an > >> empty definition of tick_handle_periodic() for CONFIG_GENERIC_CLOCKEVENTS and > >> move the definition of struct clock_event_device from under that Kconfig > >> option.] > > > > > > Does not something like the below make more sense? The entire broadcast > > thing doesn't make sense if we don't have generic_clockevents. > > > > Should we wrap more in generic_clockevents there? > > > > --- > > kernel/time/tick-internal.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h > > index 2a1563a..5569e65 100644 > > --- a/kernel/time/tick-internal.h > > +++ b/kernel/time/tick-internal.h > > @@ -81,6 +81,7 @@ static inline int tick_check_oneshot_change(int allow_nohz) { return 0; } > > #endif /* !TICK_ONESHOT */ > > > > /* Broadcasting support */ > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > > #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST > > extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu); > > extern void tick_install_broadcast_device(struct clock_event_device *dev); > > @@ -114,6 +115,7 @@ static inline void tick_set_periodic_handler(struct clock_event_device *dev, int > > dev->event_handler = tick_handle_periodic; > > } > > #endif /* !BROADCAST */ > > +#endif /* GENERIC */ > > > > /* Functions related to oneshot broadcasting */ > > #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT) > > Tested-by: Tyler Baker <tyler.baker@linaro.org> > > Looks good to me. > > Applied on top of next-20150402[0]: Cool, so FWIW Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Peter, I'm assiming that you'll make sure this goes into tip/timers/core. > --- > kernel/time/tick-internal.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h > index 2a1563a..e332bb4 100644 > --- a/kernel/time/tick-internal.h > +++ b/kernel/time/tick-internal.h > @@ -81,6 +81,7 @@ static inline int tick_check_oneshot_change(int > allow_nohz) { return 0; } > #endif /* !TICK_ONESHOT */ > > /* Broadcasting support */ > +#ifdef CONFIG_GENERIC_CLOCKEVENTS > #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST > extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu); > extern void tick_install_broadcast_device(struct clock_event_device *dev); > @@ -114,7 +115,7 @@ static inline void > tick_set_periodic_handler(struct clock_event_device *dev, int > dev->event_handler = tick_handle_periodic; > } > #endif /* !BROADCAST */ > +#endif /* GENERIC */ > /* Functions related to oneshot broadcasting */ > #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && > defined(CONFIG_TICK_ONESHOT) > extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc); > --- > > Tyler > > [0] http://kernelci.org/build/tbaker/kernel/v4.0-rc6-8742-g76c8cce3+gcc-linaro-4.9-2015.02/ -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-04-03 11:07 ` Rafael J. Wysocki @ 2015-04-03 14:24 ` Peter Zijlstra 2015-04-07 17:08 ` Tyler Baker 0 siblings, 1 reply; 11+ messages in thread From: Peter Zijlstra @ 2015-04-03 14:24 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 03, 2015 at 01:07:19PM +0200, Rafael J. Wysocki wrote: > Peter, I'm assiming that you'll make sure this goes into tip/timers/core. I'll double check, but I think Ingo did a similar thing when he applied your patches. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Build regression in next-20150331 2015-04-03 14:24 ` Peter Zijlstra @ 2015-04-07 17:08 ` Tyler Baker 0 siblings, 0 replies; 11+ messages in thread From: Tyler Baker @ 2015-04-07 17:08 UTC (permalink / raw) To: linux-arm-kernel On 3 April 2015 at 07:24, Peter Zijlstra <peterz@infradead.org> wrote: > On Fri, Apr 03, 2015 at 01:07:19PM +0200, Rafael J. Wysocki wrote: >> Peter, I'm assiming that you'll make sure this goes into tip/timers/core. > > I'll double check, but I think Ingo did a similar thing when he applied > your patches. Fix has been included next-20150407, this build regression is resolved[0]. Thanks, Tyler [0] http://kernelci.org/build/next/kernel/next-20150407/ ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-04-07 17:08 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-03-31 18:39 Build regression in next-20150331 Tyler Baker 2015-03-31 23:03 ` Rafael J. Wysocki 2015-03-31 23:27 ` Rafael J. Wysocki 2015-04-01 3:37 ` Tyler Baker 2015-04-01 21:46 ` Rafael J. Wysocki 2015-04-02 8:29 ` Peter Zijlstra 2015-04-02 22:09 ` Rafael J. Wysocki 2015-04-03 2:59 ` Tyler Baker 2015-04-03 11:07 ` Rafael J. Wysocki 2015-04-03 14:24 ` Peter Zijlstra 2015-04-07 17:08 ` Tyler Baker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).