LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* linux-next: manual merge of the tip tree with the pm tree
@ 2015-03-31  7:58 Stephen Rothwell
  2015-03-31 22:23 ` Rafael J. Wysocki
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2015-03-31  7:58 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Viresh Kumar

[-- Attachment #1: Type: text/plain, Size: 4225 bytes --]

Hi all,

Today's linux-next merge of the tip tree got conflicts in
include/linux/clockchips.h, kernel/time/tick-broadcast.c,
kernel/time/tick-common.c and kernel/time/tick-internal.h between
commit 01b9fdf7e540 ("tick: Move core only declarations and functions
to core") (and others) from the pm tree and commit 77e32c89a711
("clockevents: Manage device's state separately for the core") (and
others) from the tip tree.

I fixed it up (I *think* I may have figured it all out, but please
check - see below and teh final tree later) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/clockchips.h
index 4350d7101982,e20232c3320a..000000000000
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
diff --cc kernel/time/tick-broadcast.c
index f8e27cd0b7ab,f0f8ee9dbc28..000000000000
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@@ -553,9 -541,10 +553,9 @@@ static int tick_broadcast_set_event(str
  	return ret;
  }
  
 -int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
 +static void tick_resume_broadcast_oneshot(struct clock_event_device *bc)
  {
- 	clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
+ 	clockevents_set_state(bc, CLOCK_EVT_STATE_ONESHOT);
 -	return 0;
  }
  
  /*
diff --cc kernel/time/tick-common.c
index d9e769e31ee4,a5b877130ae9..000000000000
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@@ -386,19 -380,13 +387,20 @@@ void tick_suspend_local(void
  	clockevents_shutdown(td->evtdev);
  }
  
 -void tick_resume(void)
 +/**
 + * tick_resume_local - Resume the local tick device
 + *
 + * Called from the local CPU for unfreeze or XEN resume magic.
 + *
 + * No locks required. Nothing can change the per cpu device.
 + */
 +void tick_resume_local(void)
  {
  	struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
 -	int broadcast = tick_resume_broadcast();
 +	bool broadcast = tick_resume_check_broadcast();
  
- 	clockevents_set_mode(td->evtdev, CLOCK_EVT_MODE_RESUME);
+ 	clockevents_tick_resume(td->evtdev);
+ 
  	if (!broadcast) {
  		if (td->mode == TICKDEV_MODE_PERIODIC)
  			tick_setup_periodic(td->evtdev, 0);
diff --cc kernel/time/tick-internal.h
index 1c7560a533d5,98700e4a2000..000000000000
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@@ -27,31 -30,15 +27,32 @@@ extern void tick_resume(void)
  extern bool tick_check_replacement(struct clock_event_device *curdev,
  				   struct clock_event_device *newdev);
  extern void tick_install_replacement(struct clock_event_device *dev);
 +extern int tick_is_oneshot_available(void);
 +extern struct tick_device *tick_get_device(int cpu);
 +
 +/* Check, if the device is functional or a dummy for broadcast */
 +static inline int tick_device_is_functional(struct clock_event_device *dev)
 +{
 +	return !(dev->features & CLOCK_EVT_FEAT_DUMMY);
 +}
  
  extern void clockevents_shutdown(struct clock_event_device *dev);
+ extern int clockevents_tick_resume(struct clock_event_device *dev);
 -
 +extern void clockevents_exchange_device(struct clock_event_device *old,
 +					struct clock_event_device *new);
- extern void clockevents_set_mode(struct clock_event_device *dev,
- 				 enum clock_event_mode mode);
++extern void clockevents_set_state(struct clock_event_device *dev,
++				  enum clock_event_state state);
 +extern int clockevents_program_event(struct clock_event_device *dev,
 +				     ktime_t expires, bool force);
 +extern void clockevents_handle_noop(struct clock_event_device *dev);
 +extern int __clockevents_update_freq(struct clock_event_device *dev, u32 freq);
  extern ssize_t sysfs_get_uname(const char *buf, char *dst, size_t cnt);
 +#else
 +static inline void tick_suspend(void) { }
 +static inline void tick_resume(void) { }
 +#endif /* GENERIC_CLOCKEVENTS */
  
 -/*
 - * NO_HZ / high resolution timer shared code
 - */
 +/* Oneshot related functions */
  #ifdef CONFIG_TICK_ONESHOT
  extern void tick_setup_oneshot(struct clock_event_device *newdev,
  			       void (*handler)(struct clock_event_device *),

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2015-03-31  7:58 linux-next: manual merge of the tip tree with the pm tree Stephen Rothwell
@ 2015-03-31 22:23 ` Rafael J. Wysocki
  0 siblings, 0 replies; 38+ messages in thread
From: Rafael J. Wysocki @ 2015-03-31 22:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Viresh Kumar

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Tuesday, March 31, 2015 06:58:44 PM Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got conflicts in
> include/linux/clockchips.h, kernel/time/tick-broadcast.c,
> kernel/time/tick-common.c and kernel/time/tick-internal.h between
> commit 01b9fdf7e540 ("tick: Move core only declarations and functions
> to core") (and others) from the pm tree and commit 77e32c89a711
> ("clockevents: Manage device's state separately for the core") (and
> others) from the tip tree.
> 
> I fixed it up (I *think* I may have figured it all out, but please
> check - see below and teh final tree later) and can carry the fix as
> necessary (no action is required).

The resolution looks good from the PM tree perspective, thanks!

Rafael

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2021-02-17  5:07 Stephen Rothwell
  2021-02-17 10:15 ` Andy Shevchenko
@ 2021-02-22  0:34 ` Stephen Rothwell
  1 sibling, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2021-02-22  0:34 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Andy Shevchenko, Borislav Petkov, Linux Kernel Mailing List,
	Linux Next Mailing List, Rafael J. Wysocki, Zheng Yongjun

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

Hi all,

On Wed, 17 Feb 2021 16:07:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/platform/intel-mid/device_libs/platform_bt.c
> 
> between commit:
> 
>   4590d98f5a4f ("sfi: Remove framework for deprecated firmware")
> 
> from the pm tree and commit:
> 
>   bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon")
> 
> from the tip tree.
> 
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

This is now a conflict between the pm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2021-02-17  5:07 Stephen Rothwell
@ 2021-02-17 10:15 ` Andy Shevchenko
  2021-02-22  0:34 ` Stephen Rothwell
  1 sibling, 0 replies; 38+ messages in thread
From: Andy Shevchenko @ 2021-02-17 10:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki, Andy Shevchenko, Borislav Petkov,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Rafael J. Wysocki, Zheng Yongjun

On Wed, Feb 17, 2021 at 7:38 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
>   arch/x86/platform/intel-mid/device_libs/platform_bt.c
>
> between commit:
>
>   4590d98f5a4f ("sfi: Remove framework for deprecated firmware")
>
> from the pm tree and commit:
>
>   bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon")
>
> from the tip tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

Yes, the file removal is the right thing to do.
Thanks!

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2021-02-17  5:07 Stephen Rothwell
  2021-02-17 10:15 ` Andy Shevchenko
  2021-02-22  0:34 ` Stephen Rothwell
  0 siblings, 2 replies; 38+ messages in thread
From: Stephen Rothwell @ 2021-02-17  5:07 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Andy Shevchenko, Borislav Petkov, Linux Kernel Mailing List,
	Linux Next Mailing List, Rafael J. Wysocki, Zheng Yongjun

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/platform/intel-mid/device_libs/platform_bt.c

between commit:

  4590d98f5a4f ("sfi: Remove framework for deprecated firmware")

from the pm tree and commit:

  bdb154f074a6 ("x86/platform/intel-mid: Convert comma to semicolon")

from the tip tree.

I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2018-10-08 10:05 ` Rafael J. Wysocki
@ 2018-10-08 10:41   ` Andy Shevchenko
  0 siblings, 0 replies; 38+ messages in thread
From: Andy Shevchenko @ 2018-10-08 10:41 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, Oct 08, 2018 at 12:05:02PM +0200, Rafael J. Wysocki wrote:
> On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote:
> > 
> > --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Transfer-Encoding: quoted-printable
> > 
> > Hi all,
> > 
> > Today's linux-next merge of the tip tree got a conflict in:
> > 
> >   drivers/idle/intel_idle.c
> > 
> > between commit:
> > 
> >   a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")
> > 
> > from the pm tree and commit:
> > 
> >   f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
> > 
> > from the tip tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> > 
> > --=20
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc drivers/idle/intel_idle.c
> > index 791b8a366e6e,c4bb67ed8da3..000000000000
> > --- a/drivers/idle/intel_idle.c
> > +++ b/drivers/idle/intel_idle.c
> > @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
> >   	.disable_promotion_to_c1e =3D true,
> >   };
> >  =20
> >  -#define ICPU(model, cpu) \
> >  -	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
> >  -
> >   static const struct x86_cpu_id intel_idle_ids[] __initconst =3D {
> >  -	ICPU(INTEL_FAM6_NEHALEM_EP,		idle_cpu_nehalem),
> >  -	ICPU(INTEL_FAM6_NEHALEM,		idle_cpu_nehalem),
> >  -	ICPU(INTEL_FAM6_NEHALEM_G,		idle_cpu_nehalem),
> >  -	ICPU(INTEL_FAM6_WESTMERE,		idle_cpu_nehalem),
> >  -	ICPU(INTEL_FAM6_WESTMERE_EP,		idle_cpu_nehalem),
> >  -	ICPU(INTEL_FAM6_NEHALEM_EX,		idle_cpu_nehalem),
> >  -	ICPU(INTEL_FAM6_ATOM_BONNELL,		idle_cpu_atom),
> >  -	ICPU(INTEL_FAM6_ATOM_BONNELL_MID,		idle_cpu_lincroft),
> >  -	ICPU(INTEL_FAM6_WESTMERE_EX,		idle_cpu_nehalem),
> >  -	ICPU(INTEL_FAM6_SANDYBRIDGE,		idle_cpu_snb),
> >  -	ICPU(INTEL_FAM6_SANDYBRIDGE_X,		idle_cpu_snb),
> >  -	ICPU(INTEL_FAM6_ATOM_SALTWELL,		idle_cpu_atom),
> >  -	ICPU(INTEL_FAM6_ATOM_SILVERMONT,	idle_cpu_byt),
> >  -	ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,	idle_cpu_tangier),
> >  -	ICPU(INTEL_FAM6_ATOM_AIRMONT,		idle_cpu_cht),
> >  -	ICPU(INTEL_FAM6_IVYBRIDGE,		idle_cpu_ivb),
> >  -	ICPU(INTEL_FAM6_IVYBRIDGE_X,		idle_cpu_ivt),
> >  -	ICPU(INTEL_FAM6_HASWELL_CORE,		idle_cpu_hsw),
> >  -	ICPU(INTEL_FAM6_HASWELL_X,		idle_cpu_hsw),
> >  -	ICPU(INTEL_FAM6_HASWELL_ULT,		idle_cpu_hsw),
> >  -	ICPU(INTEL_FAM6_HASWELL_GT3E,		idle_cpu_hsw),
> >  -	ICPU(INTEL_FAM6_ATOM_SILVERMONT_X,	idle_cpu_avn),
> >  -	ICPU(INTEL_FAM6_BROADWELL_CORE,		idle_cpu_bdw),
> >  -	ICPU(INTEL_FAM6_BROADWELL_GT3E,		idle_cpu_bdw),
> >  -	ICPU(INTEL_FAM6_BROADWELL_X,		idle_cpu_bdw),
> >  -	ICPU(INTEL_FAM6_BROADWELL_XEON_D,	idle_cpu_bdw),
> >  -	ICPU(INTEL_FAM6_SKYLAKE_MOBILE,		idle_cpu_skl),
> >  -	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,	idle_cpu_skl),
> >  -	ICPU(INTEL_FAM6_KABYLAKE_MOBILE,	idle_cpu_skl),
> >  -	ICPU(INTEL_FAM6_KABYLAKE_DESKTOP,	idle_cpu_skl),
> >  -	ICPU(INTEL_FAM6_SKYLAKE_X,		idle_cpu_skx),
> >  -	ICPU(INTEL_FAM6_XEON_PHI_KNL,		idle_cpu_knl),
> >  -	ICPU(INTEL_FAM6_XEON_PHI_KNM,		idle_cpu_knl),
> >  -	ICPU(INTEL_FAM6_ATOM_GOLDMONT,		idle_cpu_bxt),
> >  -	ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,	idle_cpu_bxt),
> >  -	ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,	idle_cpu_dnv),
> >  +	INTEL_CPU_FAM6(NEHALEM_EP,		idle_cpu_nehalem),
> >  +	INTEL_CPU_FAM6(NEHALEM,			idle_cpu_nehalem),
> >  +	INTEL_CPU_FAM6(NEHALEM_G,		idle_cpu_nehalem),
> >  +	INTEL_CPU_FAM6(WESTMERE,		idle_cpu_nehalem),
> >  +	INTEL_CPU_FAM6(WESTMERE_EP,		idle_cpu_nehalem),
> >  +	INTEL_CPU_FAM6(NEHALEM_EX,		idle_cpu_nehalem),
> > - 	INTEL_CPU_FAM6(ATOM_PINEVIEW,		idle_cpu_atom),
> > - 	INTEL_CPU_FAM6(ATOM_LINCROFT,		idle_cpu_lincroft),
> > ++	INTEL_CPU_FAM6(ATOM_BONNELL,		idle_cpu_atom),
> > ++	INTEL_CPU_FAM6(ATOM_BONNELL_MID,	idle_cpu_lincroft),
> >  +	INTEL_CPU_FAM6(WESTMERE_EX,		idle_cpu_nehalem),
> >  +	INTEL_CPU_FAM6(SANDYBRIDGE,		idle_cpu_snb),
> >  +	INTEL_CPU_FAM6(SANDYBRIDGE_X,		idle_cpu_snb),
> > - 	INTEL_CPU_FAM6(ATOM_CEDARVIEW,		idle_cpu_atom),
> > - 	INTEL_CPU_FAM6(ATOM_SILVERMONT1,	idle_cpu_byt),
> > - 	INTEL_CPU_FAM6(ATOM_MERRIFIELD,		idle_cpu_tangier),
> > ++	INTEL_CPU_FAM6(ATOM_SALTWELL,		idle_cpu_atom),
> > ++	INTEL_CPU_FAM6(ATOM_SILVERMONT,		idle_cpu_byt),
> > ++	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	idle_cpu_tangier),
> >  +	INTEL_CPU_FAM6(ATOM_AIRMONT,		idle_cpu_cht),
> >  +	INTEL_CPU_FAM6(IVYBRIDGE,		idle_cpu_ivb),
> >  +	INTEL_CPU_FAM6(IVYBRIDGE_X,		idle_cpu_ivt),
> >  +	INTEL_CPU_FAM6(HASWELL_CORE,		idle_cpu_hsw),
> >  +	INTEL_CPU_FAM6(HASWELL_X,		idle_cpu_hsw),
> >  +	INTEL_CPU_FAM6(HASWELL_ULT,		idle_cpu_hsw),
> >  +	INTEL_CPU_FAM6(HASWELL_GT3E,		idle_cpu_hsw),
> > - 	INTEL_CPU_FAM6(ATOM_SILVERMONT2,	idle_cpu_avn),
> > ++	INTEL_CPU_FAM6(ATOM_SILVERMONT_X,	idle_cpu_avn),
> >  +	INTEL_CPU_FAM6(BROADWELL_CORE,		idle_cpu_bdw),
> >  +	INTEL_CPU_FAM6(BROADWELL_GT3E,		idle_cpu_bdw),
> >  +	INTEL_CPU_FAM6(BROADWELL_X,		idle_cpu_bdw),
> >  +	INTEL_CPU_FAM6(BROADWELL_XEON_D,	idle_cpu_bdw),
> >  +	INTEL_CPU_FAM6(SKYLAKE_MOBILE,		idle_cpu_skl),
> >  +	INTEL_CPU_FAM6(SKYLAKE_DESKTOP,		idle_cpu_skl),
> >  +	INTEL_CPU_FAM6(KABYLAKE_MOBILE,		idle_cpu_skl),
> >  +	INTEL_CPU_FAM6(KABYLAKE_DESKTOP,	idle_cpu_skl),
> >  +	INTEL_CPU_FAM6(SKYLAKE_X,		idle_cpu_skx),
> >  +	INTEL_CPU_FAM6(XEON_PHI_KNL,		idle_cpu_knl),
> >  +	INTEL_CPU_FAM6(XEON_PHI_KNM,		idle_cpu_knl),
> >  +	INTEL_CPU_FAM6(ATOM_GOLDMONT,		idle_cpu_bxt),
> > - 	INTEL_CPU_FAM6(ATOM_GEMINI_LAKE,	idle_cpu_bxt),
> > - 	INTEL_CPU_FAM6(ATOM_DENVERTON,		idle_cpu_dnv),
> > ++	INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS,	idle_cpu_bxt),
> > ++	INTEL_CPU_FAM6(ATOM_GOLDMONT_X,		idle_cpu_dnv),
> >   	{}
> >   };
> >  =20
> > 
> > --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> > Content-Type: application/pgp-signature
> > Content-Description: OpenPGP digital signature
> > 
> > 
> > --Sig_/8A/3tsSoWQOAryCmuI_nxw6--
> > 
> 
> This looks good to me.  Andy?

Either to me.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2018-10-08 10:06 ` Rafael J. Wysocki
@ 2018-10-08 10:34   ` Andy Shevchenko
  0 siblings, 0 replies; 38+ messages in thread
From: Andy Shevchenko @ 2018-10-08 10:34 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Stephen Rothwell, Andy Shevchenko, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra (Intel),
	linux-next, Linux Kernel Mailing List

On Mon, Oct 8, 2018 at 1:11 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote:
> >
> > --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Transfer-Encoding: quoted-printable
> >
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> >   drivers/powercap/intel_rapl.c
> >
> > between commit:
> >
> >   17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")
> >
> > from the pm tree and commit:
> >
> >   f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
> >
> > from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > --=20
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc drivers/powercap/intel_rapl.c
> > index bb92874b1175,8cbfcce57a06..000000000000
> > --- a/drivers/powercap/intel_rapl.c
> > +++ b/drivers/powercap/intel_rapl.c
> > @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
> >       .compute_time_window =3D rapl_compute_time_window_atom,
> >   };
> >  =20
> >  -#define RAPL_CPU(_model, _ops) {                    \
> >  -            .vendor =3D X86_VENDOR_INTEL,           \
> >  -            .family =3D 6,                          \
> >  -            .model =3D _model,                      \
> >  -            .driver_data =3D (kernel_ulong_t)&_ops, \
> >  -            }
> >  -
> >   static const struct x86_cpu_id rapl_ids[] __initconst =3D {
> >  -    RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,        rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,      rapl_defaults_core),
> >  -
> >  -    RAPL_CPU(INTEL_FAM6_IVYBRIDGE,          rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,        rapl_defaults_core),
> >  -
> >  -    RAPL_CPU(INTEL_FAM6_HASWELL_CORE,       rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_HASWELL_ULT,        rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_HASWELL_GT3E,       rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_HASWELL_X,          rapl_defaults_hsw_server),
> >  -
> >  -    RAPL_CPU(INTEL_FAM6_BROADWELL_CORE,     rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E,     rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,   rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_BROADWELL_X,        rapl_defaults_hsw_server),
> >  -
> >  -    RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,    rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE,     rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_SKYLAKE_X,          rapl_defaults_hsw_server),
> >  -    RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,    rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,   rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE,  rapl_defaults_core),
> >  -
> >  -    RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,    rapl_defaults_byt),
> >  -    RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,       rapl_defaults_cht),
> >  -    RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,        rapl_defaults_tng),
> >  -    RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID,   rapl_defaults_ann),
> >  -    RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,      rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS, rapl_defaults_core),
> >  -    RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,    rapl_defaults_core),
> >  -
> >  -    RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL,       rapl_defaults_hsw_server),
> >  -    RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM,       rapl_defaults_hsw_server),
> >  +    INTEL_CPU_FAM6(SANDYBRIDGE,             rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(SANDYBRIDGE_X,           rapl_defaults_core),
> >  +
> >  +    INTEL_CPU_FAM6(IVYBRIDGE,               rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(IVYBRIDGE_X,             rapl_defaults_core),
> >  +
> >  +    INTEL_CPU_FAM6(HASWELL_CORE,            rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(HASWELL_ULT,             rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(HASWELL_GT3E,            rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(HASWELL_X,               rapl_defaults_hsw_server),
> >  +
> >  +    INTEL_CPU_FAM6(BROADWELL_CORE,          rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(BROADWELL_GT3E,          rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(BROADWELL_XEON_D,        rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(BROADWELL_X,             rapl_defaults_hsw_server),
> >  +
> >  +    INTEL_CPU_FAM6(SKYLAKE_DESKTOP,         rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(SKYLAKE_MOBILE,          rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(SKYLAKE_X,               rapl_defaults_hsw_server),
> >  +    INTEL_CPU_FAM6(KABYLAKE_MOBILE,         rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(KABYLAKE_DESKTOP,        rapl_defaults_core),
> >  +    INTEL_CPU_FAM6(CANNONLAKE_MOBILE,       rapl_defaults_core),
> >  +
> > -     INTEL_CPU_FAM6(ATOM_SILVERMONT1,        rapl_defaults_byt),
> > ++    INTEL_CPU_FAM6(ATOM_SILVERMONT,         rapl_defaults_byt),
> >  +    INTEL_CPU_FAM6(ATOM_AIRMONT,            rapl_defaults_cht),
> > -     INTEL_CPU_FAM6(ATOM_MERRIFIELD,         rapl_defaults_tng),
> > -     INTEL_CPU_FAM6(ATOM_MOOREFIELD,         rapl_defaults_ann),
> > ++    INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,     rapl_defaults_tng),
> > ++    INTEL_CPU_FAM6(ATOM_AIRMONT_MID,        rapl_defaults_ann),
> >  +    INTEL_CPU_FAM6(ATOM_GOLDMONT,           rapl_defaults_core),
> > -     INTEL_CPU_FAM6(ATOM_GEMINI_LAKE,        rapl_defaults_core),
> > -     INTEL_CPU_FAM6(ATOM_DENVERTON,          rapl_defaults_core),
> > ++    INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS,      rapl_defaults_core),
> > ++    INTEL_CPU_FAM6(ATOM_GOLDMONT_X,         rapl_defaults_core),
> >  +
> >  +    INTEL_CPU_FAM6(XEON_PHI_KNL,            rapl_defaults_hsw_server),
> >  +    INTEL_CPU_FAM6(XEON_PHI_KNM,            rapl_defaults_hsw_server),
> >       {}
> >   };
> >   MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
> >
> > --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> > Content-Type: application/pgp-signature
> > Content-Description: OpenPGP digital signature
> >
> >
> > --Sig_/bNRy8ryxcqLmcoGqvlETGhp--
>
> This looks good to me too.  Andy, any concerns?

Nope, looks good to me!

--
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2018-10-08  2:44 Stephen Rothwell
@ 2018-10-08 10:06 ` Rafael J. Wysocki
  2018-10-08 10:34   ` Andy Shevchenko
  0 siblings, 1 reply; 38+ messages in thread
From: Rafael J. Wysocki @ 2018-10-08 10:06 UTC (permalink / raw)
  To: Stephen Rothwell, Andy Shevchenko
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Monday, October 8, 2018 4:44:49 AM CEST Stephen Rothwell wrote:
> 
> --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
> 
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/powercap/intel_rapl.c
> 
> between commit:
> 
>   17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")
> 
> from the pm tree and commit:
> 
>   f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> --=20
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/powercap/intel_rapl.c
> index bb92874b1175,8cbfcce57a06..000000000000
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
>   	.compute_time_window =3D rapl_compute_time_window_atom,
>   };
>  =20
>  -#define RAPL_CPU(_model, _ops) {			\
>  -		.vendor =3D X86_VENDOR_INTEL,		\
>  -		.family =3D 6,				\
>  -		.model =3D _model,			\
>  -		.driver_data =3D (kernel_ulong_t)&_ops,	\
>  -		}
>  -
>   static const struct x86_cpu_id rapl_ids[] __initconst =3D {
>  -	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,	rapl_defaults_core),
>  -
>  -	RAPL_CPU(INTEL_FAM6_IVYBRIDGE,		rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,	rapl_defaults_core),
>  -
>  -	RAPL_CPU(INTEL_FAM6_HASWELL_CORE,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_HASWELL_ULT,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_HASWELL_GT3E,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_HASWELL_X,		rapl_defaults_hsw_server),
>  -
>  -	RAPL_CPU(INTEL_FAM6_BROADWELL_CORE,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_BROADWELL_X,	rapl_defaults_hsw_server),
>  -
>  -	RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_SKYLAKE_X,		rapl_defaults_hsw_server),
>  -	RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE,	rapl_defaults_core),
>  -
>  -	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,	rapl_defaults_byt),
>  -	RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,	rapl_defaults_cht),
>  -	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,	rapl_defaults_tng),
>  -	RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID,	rapl_defaults_ann),
>  -	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,	rapl_defaults_core),
>  -	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,	rapl_defaults_core),
>  -
>  -	RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL,	rapl_defaults_hsw_server),
>  -	RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM,	rapl_defaults_hsw_server),
>  +	INTEL_CPU_FAM6(SANDYBRIDGE,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(SANDYBRIDGE_X,		rapl_defaults_core),
>  +
>  +	INTEL_CPU_FAM6(IVYBRIDGE,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(IVYBRIDGE_X,		rapl_defaults_core),
>  +
>  +	INTEL_CPU_FAM6(HASWELL_CORE,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(HASWELL_ULT,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(HASWELL_GT3E,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(HASWELL_X,		rapl_defaults_hsw_server),
>  +
>  +	INTEL_CPU_FAM6(BROADWELL_CORE,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(BROADWELL_GT3E,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(BROADWELL_XEON_D,	rapl_defaults_core),
>  +	INTEL_CPU_FAM6(BROADWELL_X,		rapl_defaults_hsw_server),
>  +
>  +	INTEL_CPU_FAM6(SKYLAKE_DESKTOP,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(SKYLAKE_MOBILE,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(SKYLAKE_X,		rapl_defaults_hsw_server),
>  +	INTEL_CPU_FAM6(KABYLAKE_MOBILE,		rapl_defaults_core),
>  +	INTEL_CPU_FAM6(KABYLAKE_DESKTOP,	rapl_defaults_core),
>  +	INTEL_CPU_FAM6(CANNONLAKE_MOBILE,	rapl_defaults_core),
>  +
> - 	INTEL_CPU_FAM6(ATOM_SILVERMONT1,	rapl_defaults_byt),
> ++	INTEL_CPU_FAM6(ATOM_SILVERMONT,		rapl_defaults_byt),
>  +	INTEL_CPU_FAM6(ATOM_AIRMONT,		rapl_defaults_cht),
> - 	INTEL_CPU_FAM6(ATOM_MERRIFIELD,		rapl_defaults_tng),
> - 	INTEL_CPU_FAM6(ATOM_MOOREFIELD,		rapl_defaults_ann),
> ++	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	rapl_defaults_tng),
> ++	INTEL_CPU_FAM6(ATOM_AIRMONT_MID,	rapl_defaults_ann),
>  +	INTEL_CPU_FAM6(ATOM_GOLDMONT,		rapl_defaults_core),
> - 	INTEL_CPU_FAM6(ATOM_GEMINI_LAKE,	rapl_defaults_core),
> - 	INTEL_CPU_FAM6(ATOM_DENVERTON,		rapl_defaults_core),
> ++	INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS,	rapl_defaults_core),
> ++	INTEL_CPU_FAM6(ATOM_GOLDMONT_X,		rapl_defaults_core),
>  +
>  +	INTEL_CPU_FAM6(XEON_PHI_KNL,		rapl_defaults_hsw_server),
>  +	INTEL_CPU_FAM6(XEON_PHI_KNM,		rapl_defaults_hsw_server),
>   	{}
>   };
>   MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
> 
> --Sig_/bNRy8ryxcqLmcoGqvlETGhp
> Content-Type: application/pgp-signature
> Content-Description: OpenPGP digital signature
> 
> 
> --Sig_/bNRy8ryxcqLmcoGqvlETGhp--

This looks good to me too.  Andy, any concerns?



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2018-10-08  2:40 Stephen Rothwell
@ 2018-10-08 10:05 ` Rafael J. Wysocki
  2018-10-08 10:41   ` Andy Shevchenko
  0 siblings, 1 reply; 38+ messages in thread
From: Rafael J. Wysocki @ 2018-10-08 10:05 UTC (permalink / raw)
  To: Stephen Rothwell, Andy Shevchenko
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List

On Monday, October 8, 2018 4:40:20 AM CEST Stephen Rothwell wrote:
> 
> --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
> 
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/idle/intel_idle.c
> 
> between commit:
> 
>   a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")
> 
> from the pm tree and commit:
> 
>   f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> --=20
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/idle/intel_idle.c
> index 791b8a366e6e,c4bb67ed8da3..000000000000
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
> @@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
>   	.disable_promotion_to_c1e =3D true,
>   };
>  =20
>  -#define ICPU(model, cpu) \
>  -	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
>  -
>   static const struct x86_cpu_id intel_idle_ids[] __initconst =3D {
>  -	ICPU(INTEL_FAM6_NEHALEM_EP,		idle_cpu_nehalem),
>  -	ICPU(INTEL_FAM6_NEHALEM,		idle_cpu_nehalem),
>  -	ICPU(INTEL_FAM6_NEHALEM_G,		idle_cpu_nehalem),
>  -	ICPU(INTEL_FAM6_WESTMERE,		idle_cpu_nehalem),
>  -	ICPU(INTEL_FAM6_WESTMERE_EP,		idle_cpu_nehalem),
>  -	ICPU(INTEL_FAM6_NEHALEM_EX,		idle_cpu_nehalem),
>  -	ICPU(INTEL_FAM6_ATOM_BONNELL,		idle_cpu_atom),
>  -	ICPU(INTEL_FAM6_ATOM_BONNELL_MID,		idle_cpu_lincroft),
>  -	ICPU(INTEL_FAM6_WESTMERE_EX,		idle_cpu_nehalem),
>  -	ICPU(INTEL_FAM6_SANDYBRIDGE,		idle_cpu_snb),
>  -	ICPU(INTEL_FAM6_SANDYBRIDGE_X,		idle_cpu_snb),
>  -	ICPU(INTEL_FAM6_ATOM_SALTWELL,		idle_cpu_atom),
>  -	ICPU(INTEL_FAM6_ATOM_SILVERMONT,	idle_cpu_byt),
>  -	ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,	idle_cpu_tangier),
>  -	ICPU(INTEL_FAM6_ATOM_AIRMONT,		idle_cpu_cht),
>  -	ICPU(INTEL_FAM6_IVYBRIDGE,		idle_cpu_ivb),
>  -	ICPU(INTEL_FAM6_IVYBRIDGE_X,		idle_cpu_ivt),
>  -	ICPU(INTEL_FAM6_HASWELL_CORE,		idle_cpu_hsw),
>  -	ICPU(INTEL_FAM6_HASWELL_X,		idle_cpu_hsw),
>  -	ICPU(INTEL_FAM6_HASWELL_ULT,		idle_cpu_hsw),
>  -	ICPU(INTEL_FAM6_HASWELL_GT3E,		idle_cpu_hsw),
>  -	ICPU(INTEL_FAM6_ATOM_SILVERMONT_X,	idle_cpu_avn),
>  -	ICPU(INTEL_FAM6_BROADWELL_CORE,		idle_cpu_bdw),
>  -	ICPU(INTEL_FAM6_BROADWELL_GT3E,		idle_cpu_bdw),
>  -	ICPU(INTEL_FAM6_BROADWELL_X,		idle_cpu_bdw),
>  -	ICPU(INTEL_FAM6_BROADWELL_XEON_D,	idle_cpu_bdw),
>  -	ICPU(INTEL_FAM6_SKYLAKE_MOBILE,		idle_cpu_skl),
>  -	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,	idle_cpu_skl),
>  -	ICPU(INTEL_FAM6_KABYLAKE_MOBILE,	idle_cpu_skl),
>  -	ICPU(INTEL_FAM6_KABYLAKE_DESKTOP,	idle_cpu_skl),
>  -	ICPU(INTEL_FAM6_SKYLAKE_X,		idle_cpu_skx),
>  -	ICPU(INTEL_FAM6_XEON_PHI_KNL,		idle_cpu_knl),
>  -	ICPU(INTEL_FAM6_XEON_PHI_KNM,		idle_cpu_knl),
>  -	ICPU(INTEL_FAM6_ATOM_GOLDMONT,		idle_cpu_bxt),
>  -	ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,	idle_cpu_bxt),
>  -	ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,	idle_cpu_dnv),
>  +	INTEL_CPU_FAM6(NEHALEM_EP,		idle_cpu_nehalem),
>  +	INTEL_CPU_FAM6(NEHALEM,			idle_cpu_nehalem),
>  +	INTEL_CPU_FAM6(NEHALEM_G,		idle_cpu_nehalem),
>  +	INTEL_CPU_FAM6(WESTMERE,		idle_cpu_nehalem),
>  +	INTEL_CPU_FAM6(WESTMERE_EP,		idle_cpu_nehalem),
>  +	INTEL_CPU_FAM6(NEHALEM_EX,		idle_cpu_nehalem),
> - 	INTEL_CPU_FAM6(ATOM_PINEVIEW,		idle_cpu_atom),
> - 	INTEL_CPU_FAM6(ATOM_LINCROFT,		idle_cpu_lincroft),
> ++	INTEL_CPU_FAM6(ATOM_BONNELL,		idle_cpu_atom),
> ++	INTEL_CPU_FAM6(ATOM_BONNELL_MID,	idle_cpu_lincroft),
>  +	INTEL_CPU_FAM6(WESTMERE_EX,		idle_cpu_nehalem),
>  +	INTEL_CPU_FAM6(SANDYBRIDGE,		idle_cpu_snb),
>  +	INTEL_CPU_FAM6(SANDYBRIDGE_X,		idle_cpu_snb),
> - 	INTEL_CPU_FAM6(ATOM_CEDARVIEW,		idle_cpu_atom),
> - 	INTEL_CPU_FAM6(ATOM_SILVERMONT1,	idle_cpu_byt),
> - 	INTEL_CPU_FAM6(ATOM_MERRIFIELD,		idle_cpu_tangier),
> ++	INTEL_CPU_FAM6(ATOM_SALTWELL,		idle_cpu_atom),
> ++	INTEL_CPU_FAM6(ATOM_SILVERMONT,		idle_cpu_byt),
> ++	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	idle_cpu_tangier),
>  +	INTEL_CPU_FAM6(ATOM_AIRMONT,		idle_cpu_cht),
>  +	INTEL_CPU_FAM6(IVYBRIDGE,		idle_cpu_ivb),
>  +	INTEL_CPU_FAM6(IVYBRIDGE_X,		idle_cpu_ivt),
>  +	INTEL_CPU_FAM6(HASWELL_CORE,		idle_cpu_hsw),
>  +	INTEL_CPU_FAM6(HASWELL_X,		idle_cpu_hsw),
>  +	INTEL_CPU_FAM6(HASWELL_ULT,		idle_cpu_hsw),
>  +	INTEL_CPU_FAM6(HASWELL_GT3E,		idle_cpu_hsw),
> - 	INTEL_CPU_FAM6(ATOM_SILVERMONT2,	idle_cpu_avn),
> ++	INTEL_CPU_FAM6(ATOM_SILVERMONT_X,	idle_cpu_avn),
>  +	INTEL_CPU_FAM6(BROADWELL_CORE,		idle_cpu_bdw),
>  +	INTEL_CPU_FAM6(BROADWELL_GT3E,		idle_cpu_bdw),
>  +	INTEL_CPU_FAM6(BROADWELL_X,		idle_cpu_bdw),
>  +	INTEL_CPU_FAM6(BROADWELL_XEON_D,	idle_cpu_bdw),
>  +	INTEL_CPU_FAM6(SKYLAKE_MOBILE,		idle_cpu_skl),
>  +	INTEL_CPU_FAM6(SKYLAKE_DESKTOP,		idle_cpu_skl),
>  +	INTEL_CPU_FAM6(KABYLAKE_MOBILE,		idle_cpu_skl),
>  +	INTEL_CPU_FAM6(KABYLAKE_DESKTOP,	idle_cpu_skl),
>  +	INTEL_CPU_FAM6(SKYLAKE_X,		idle_cpu_skx),
>  +	INTEL_CPU_FAM6(XEON_PHI_KNL,		idle_cpu_knl),
>  +	INTEL_CPU_FAM6(XEON_PHI_KNM,		idle_cpu_knl),
>  +	INTEL_CPU_FAM6(ATOM_GOLDMONT,		idle_cpu_bxt),
> - 	INTEL_CPU_FAM6(ATOM_GEMINI_LAKE,	idle_cpu_bxt),
> - 	INTEL_CPU_FAM6(ATOM_DENVERTON,		idle_cpu_dnv),
> ++	INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS,	idle_cpu_bxt),
> ++	INTEL_CPU_FAM6(ATOM_GOLDMONT_X,		idle_cpu_dnv),
>   	{}
>   };
>  =20
> 
> --Sig_/8A/3tsSoWQOAryCmuI_nxw6
> Content-Type: application/pgp-signature
> Content-Description: OpenPGP digital signature
> 
> 
> --Sig_/8A/3tsSoWQOAryCmuI_nxw6--
> 

This looks good to me.  Andy?



^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2018-10-08  2:44 Stephen Rothwell
  2018-10-08 10:06 ` Rafael J. Wysocki
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2018-10-08  2:44 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andy Shevchenko

[-- Attachment #1: Type: text/plain, Size: 4861 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/powercap/intel_rapl.c

between commit:

  17ed15183c24 ("powercap: RAPL: Get rid of custom RAPL_CPU() macro")

from the pm tree and commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/powercap/intel_rapl.c
index bb92874b1175,8cbfcce57a06..000000000000
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@@ -1133,40 -1133,47 +1133,40 @@@ static const struct rapl_defaults rapl_
  	.compute_time_window = rapl_compute_time_window_atom,
  };
  
 -#define RAPL_CPU(_model, _ops) {			\
 -		.vendor = X86_VENDOR_INTEL,		\
 -		.family = 6,				\
 -		.model = _model,			\
 -		.driver_data = (kernel_ulong_t)&_ops,	\
 -		}
 -
  static const struct x86_cpu_id rapl_ids[] __initconst = {
 -	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_SANDYBRIDGE_X,	rapl_defaults_core),
 -
 -	RAPL_CPU(INTEL_FAM6_IVYBRIDGE,		rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_IVYBRIDGE_X,	rapl_defaults_core),
 -
 -	RAPL_CPU(INTEL_FAM6_HASWELL_CORE,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_HASWELL_ULT,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_HASWELL_GT3E,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_HASWELL_X,		rapl_defaults_hsw_server),
 -
 -	RAPL_CPU(INTEL_FAM6_BROADWELL_CORE,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_BROADWELL_GT3E,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_BROADWELL_XEON_D,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_BROADWELL_X,	rapl_defaults_hsw_server),
 -
 -	RAPL_CPU(INTEL_FAM6_SKYLAKE_DESKTOP,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_SKYLAKE_MOBILE,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_SKYLAKE_X,		rapl_defaults_hsw_server),
 -	RAPL_CPU(INTEL_FAM6_KABYLAKE_MOBILE,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_KABYLAKE_DESKTOP,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_CANNONLAKE_MOBILE,	rapl_defaults_core),
 -
 -	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT,	rapl_defaults_byt),
 -	RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,	rapl_defaults_cht),
 -	RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT_MID,	rapl_defaults_tng),
 -	RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT_MID,	rapl_defaults_ann),
 -	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,	rapl_defaults_core),
 -	RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT_X,	rapl_defaults_core),
 -
 -	RAPL_CPU(INTEL_FAM6_XEON_PHI_KNL,	rapl_defaults_hsw_server),
 -	RAPL_CPU(INTEL_FAM6_XEON_PHI_KNM,	rapl_defaults_hsw_server),
 +	INTEL_CPU_FAM6(SANDYBRIDGE,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(SANDYBRIDGE_X,		rapl_defaults_core),
 +
 +	INTEL_CPU_FAM6(IVYBRIDGE,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(IVYBRIDGE_X,		rapl_defaults_core),
 +
 +	INTEL_CPU_FAM6(HASWELL_CORE,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(HASWELL_ULT,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(HASWELL_GT3E,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(HASWELL_X,		rapl_defaults_hsw_server),
 +
 +	INTEL_CPU_FAM6(BROADWELL_CORE,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(BROADWELL_GT3E,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(BROADWELL_XEON_D,	rapl_defaults_core),
 +	INTEL_CPU_FAM6(BROADWELL_X,		rapl_defaults_hsw_server),
 +
 +	INTEL_CPU_FAM6(SKYLAKE_DESKTOP,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(SKYLAKE_MOBILE,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(SKYLAKE_X,		rapl_defaults_hsw_server),
 +	INTEL_CPU_FAM6(KABYLAKE_MOBILE,		rapl_defaults_core),
 +	INTEL_CPU_FAM6(KABYLAKE_DESKTOP,	rapl_defaults_core),
 +	INTEL_CPU_FAM6(CANNONLAKE_MOBILE,	rapl_defaults_core),
 +
- 	INTEL_CPU_FAM6(ATOM_SILVERMONT1,	rapl_defaults_byt),
++	INTEL_CPU_FAM6(ATOM_SILVERMONT,		rapl_defaults_byt),
 +	INTEL_CPU_FAM6(ATOM_AIRMONT,		rapl_defaults_cht),
- 	INTEL_CPU_FAM6(ATOM_MERRIFIELD,		rapl_defaults_tng),
- 	INTEL_CPU_FAM6(ATOM_MOOREFIELD,		rapl_defaults_ann),
++	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	rapl_defaults_tng),
++	INTEL_CPU_FAM6(ATOM_AIRMONT_MID,	rapl_defaults_ann),
 +	INTEL_CPU_FAM6(ATOM_GOLDMONT,		rapl_defaults_core),
- 	INTEL_CPU_FAM6(ATOM_GEMINI_LAKE,	rapl_defaults_core),
- 	INTEL_CPU_FAM6(ATOM_DENVERTON,		rapl_defaults_core),
++	INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS,	rapl_defaults_core),
++	INTEL_CPU_FAM6(ATOM_GOLDMONT_X,		rapl_defaults_core),
 +
 +	INTEL_CPU_FAM6(XEON_PHI_KNL,		rapl_defaults_hsw_server),
 +	INTEL_CPU_FAM6(XEON_PHI_KNM,		rapl_defaults_hsw_server),
  	{}
  };
  MODULE_DEVICE_TABLE(x86cpu, rapl_ids);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2018-10-08  2:40 Stephen Rothwell
  2018-10-08 10:05 ` Rafael J. Wysocki
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2018-10-08  2:40 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Andy Shevchenko

[-- Attachment #1: Type: text/plain, Size: 5265 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/idle/intel_idle.c

between commit:

  a4a008e53c9e ("intel_idle: Get rid of custom ICPU() macro")

from the pm tree and commit:

  f2c4db1bd807 ("x86/cpu: Sanitize FAM6_ATOM naming")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/idle/intel_idle.c
index 791b8a366e6e,c4bb67ed8da3..000000000000
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -1066,43 -1066,46 +1066,43 @@@ static const struct idle_cpu idle_cpu_d
  	.disable_promotion_to_c1e = true,
  };
  
 -#define ICPU(model, cpu) \
 -	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
 -
  static const struct x86_cpu_id intel_idle_ids[] __initconst = {
 -	ICPU(INTEL_FAM6_NEHALEM_EP,		idle_cpu_nehalem),
 -	ICPU(INTEL_FAM6_NEHALEM,		idle_cpu_nehalem),
 -	ICPU(INTEL_FAM6_NEHALEM_G,		idle_cpu_nehalem),
 -	ICPU(INTEL_FAM6_WESTMERE,		idle_cpu_nehalem),
 -	ICPU(INTEL_FAM6_WESTMERE_EP,		idle_cpu_nehalem),
 -	ICPU(INTEL_FAM6_NEHALEM_EX,		idle_cpu_nehalem),
 -	ICPU(INTEL_FAM6_ATOM_BONNELL,		idle_cpu_atom),
 -	ICPU(INTEL_FAM6_ATOM_BONNELL_MID,		idle_cpu_lincroft),
 -	ICPU(INTEL_FAM6_WESTMERE_EX,		idle_cpu_nehalem),
 -	ICPU(INTEL_FAM6_SANDYBRIDGE,		idle_cpu_snb),
 -	ICPU(INTEL_FAM6_SANDYBRIDGE_X,		idle_cpu_snb),
 -	ICPU(INTEL_FAM6_ATOM_SALTWELL,		idle_cpu_atom),
 -	ICPU(INTEL_FAM6_ATOM_SILVERMONT,	idle_cpu_byt),
 -	ICPU(INTEL_FAM6_ATOM_SILVERMONT_MID,	idle_cpu_tangier),
 -	ICPU(INTEL_FAM6_ATOM_AIRMONT,		idle_cpu_cht),
 -	ICPU(INTEL_FAM6_IVYBRIDGE,		idle_cpu_ivb),
 -	ICPU(INTEL_FAM6_IVYBRIDGE_X,		idle_cpu_ivt),
 -	ICPU(INTEL_FAM6_HASWELL_CORE,		idle_cpu_hsw),
 -	ICPU(INTEL_FAM6_HASWELL_X,		idle_cpu_hsw),
 -	ICPU(INTEL_FAM6_HASWELL_ULT,		idle_cpu_hsw),
 -	ICPU(INTEL_FAM6_HASWELL_GT3E,		idle_cpu_hsw),
 -	ICPU(INTEL_FAM6_ATOM_SILVERMONT_X,	idle_cpu_avn),
 -	ICPU(INTEL_FAM6_BROADWELL_CORE,		idle_cpu_bdw),
 -	ICPU(INTEL_FAM6_BROADWELL_GT3E,		idle_cpu_bdw),
 -	ICPU(INTEL_FAM6_BROADWELL_X,		idle_cpu_bdw),
 -	ICPU(INTEL_FAM6_BROADWELL_XEON_D,	idle_cpu_bdw),
 -	ICPU(INTEL_FAM6_SKYLAKE_MOBILE,		idle_cpu_skl),
 -	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP,	idle_cpu_skl),
 -	ICPU(INTEL_FAM6_KABYLAKE_MOBILE,	idle_cpu_skl),
 -	ICPU(INTEL_FAM6_KABYLAKE_DESKTOP,	idle_cpu_skl),
 -	ICPU(INTEL_FAM6_SKYLAKE_X,		idle_cpu_skx),
 -	ICPU(INTEL_FAM6_XEON_PHI_KNL,		idle_cpu_knl),
 -	ICPU(INTEL_FAM6_XEON_PHI_KNM,		idle_cpu_knl),
 -	ICPU(INTEL_FAM6_ATOM_GOLDMONT,		idle_cpu_bxt),
 -	ICPU(INTEL_FAM6_ATOM_GOLDMONT_PLUS,	idle_cpu_bxt),
 -	ICPU(INTEL_FAM6_ATOM_GOLDMONT_X,	idle_cpu_dnv),
 +	INTEL_CPU_FAM6(NEHALEM_EP,		idle_cpu_nehalem),
 +	INTEL_CPU_FAM6(NEHALEM,			idle_cpu_nehalem),
 +	INTEL_CPU_FAM6(NEHALEM_G,		idle_cpu_nehalem),
 +	INTEL_CPU_FAM6(WESTMERE,		idle_cpu_nehalem),
 +	INTEL_CPU_FAM6(WESTMERE_EP,		idle_cpu_nehalem),
 +	INTEL_CPU_FAM6(NEHALEM_EX,		idle_cpu_nehalem),
- 	INTEL_CPU_FAM6(ATOM_PINEVIEW,		idle_cpu_atom),
- 	INTEL_CPU_FAM6(ATOM_LINCROFT,		idle_cpu_lincroft),
++	INTEL_CPU_FAM6(ATOM_BONNELL,		idle_cpu_atom),
++	INTEL_CPU_FAM6(ATOM_BONNELL_MID,	idle_cpu_lincroft),
 +	INTEL_CPU_FAM6(WESTMERE_EX,		idle_cpu_nehalem),
 +	INTEL_CPU_FAM6(SANDYBRIDGE,		idle_cpu_snb),
 +	INTEL_CPU_FAM6(SANDYBRIDGE_X,		idle_cpu_snb),
- 	INTEL_CPU_FAM6(ATOM_CEDARVIEW,		idle_cpu_atom),
- 	INTEL_CPU_FAM6(ATOM_SILVERMONT1,	idle_cpu_byt),
- 	INTEL_CPU_FAM6(ATOM_MERRIFIELD,		idle_cpu_tangier),
++	INTEL_CPU_FAM6(ATOM_SALTWELL,		idle_cpu_atom),
++	INTEL_CPU_FAM6(ATOM_SILVERMONT,		idle_cpu_byt),
++	INTEL_CPU_FAM6(ATOM_SILVERMONT_MID,	idle_cpu_tangier),
 +	INTEL_CPU_FAM6(ATOM_AIRMONT,		idle_cpu_cht),
 +	INTEL_CPU_FAM6(IVYBRIDGE,		idle_cpu_ivb),
 +	INTEL_CPU_FAM6(IVYBRIDGE_X,		idle_cpu_ivt),
 +	INTEL_CPU_FAM6(HASWELL_CORE,		idle_cpu_hsw),
 +	INTEL_CPU_FAM6(HASWELL_X,		idle_cpu_hsw),
 +	INTEL_CPU_FAM6(HASWELL_ULT,		idle_cpu_hsw),
 +	INTEL_CPU_FAM6(HASWELL_GT3E,		idle_cpu_hsw),
- 	INTEL_CPU_FAM6(ATOM_SILVERMONT2,	idle_cpu_avn),
++	INTEL_CPU_FAM6(ATOM_SILVERMONT_X,	idle_cpu_avn),
 +	INTEL_CPU_FAM6(BROADWELL_CORE,		idle_cpu_bdw),
 +	INTEL_CPU_FAM6(BROADWELL_GT3E,		idle_cpu_bdw),
 +	INTEL_CPU_FAM6(BROADWELL_X,		idle_cpu_bdw),
 +	INTEL_CPU_FAM6(BROADWELL_XEON_D,	idle_cpu_bdw),
 +	INTEL_CPU_FAM6(SKYLAKE_MOBILE,		idle_cpu_skl),
 +	INTEL_CPU_FAM6(SKYLAKE_DESKTOP,		idle_cpu_skl),
 +	INTEL_CPU_FAM6(KABYLAKE_MOBILE,		idle_cpu_skl),
 +	INTEL_CPU_FAM6(KABYLAKE_DESKTOP,	idle_cpu_skl),
 +	INTEL_CPU_FAM6(SKYLAKE_X,		idle_cpu_skx),
 +	INTEL_CPU_FAM6(XEON_PHI_KNL,		idle_cpu_knl),
 +	INTEL_CPU_FAM6(XEON_PHI_KNM,		idle_cpu_knl),
 +	INTEL_CPU_FAM6(ATOM_GOLDMONT,		idle_cpu_bxt),
- 	INTEL_CPU_FAM6(ATOM_GEMINI_LAKE,	idle_cpu_bxt),
- 	INTEL_CPU_FAM6(ATOM_DENVERTON,		idle_cpu_dnv),
++	INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS,	idle_cpu_bxt),
++	INTEL_CPU_FAM6(ATOM_GOLDMONT_X,		idle_cpu_dnv),
  	{}
  };
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2018-03-23 21:09   ` Rafael J. Wysocki
@ 2018-03-24  8:15     ` Ingo Molnar
  0 siblings, 0 replies; 38+ messages in thread
From: Ingo Molnar @ 2018-03-24  8:15 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List, Claudio Scordino


* Rafael J. Wysocki <rjw@rjwysocki.net> wrote:

> On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote:
> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Hi all,
> > > 
> > > Today's linux-next merge of the tip tree got a conflict in:
> > > 
> > >   kernel/sched/cpufreq_schedutil.c
> > > 
> > > between commit:
> > > 
> > >   0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")
> > 
> > Rafael, could you please send that to the scheduler tree?
> 
> You can apply from
> 
> https://patchwork.kernel.org/patch/10278127/
> 
> and I will drop it from my tree.
> 
> Thanks!

Great - Thomas picked it up and it's now in tip:sched/core:

  e97a90f7069b: sched/cpufreq: Rate limits for SCHED_DEADLINE

and it should hit -next on Monday.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2018-03-23  6:09 ` Ingo Molnar
@ 2018-03-23 21:09   ` Rafael J. Wysocki
  2018-03-24  8:15     ` Ingo Molnar
  0 siblings, 1 reply; 38+ messages in thread
From: Rafael J. Wysocki @ 2018-03-23 21:09 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, Linux-Next Mailing List,
	Linux Kernel Mailing List, Claudio Scordino

On Friday, March 23, 2018 7:09:24 AM CET Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the tip tree got a conflict in:
> > 
> >   kernel/sched/cpufreq_schedutil.c
> > 
> > between commit:
> > 
> >   0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")
> 
> Rafael, could you please send that to the scheduler tree?

You can apply from

https://patchwork.kernel.org/patch/10278127/

and I will drop it from my tree.

Thanks!

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2018-03-23  2:20 Stephen Rothwell
@ 2018-03-23  6:09 ` Ingo Molnar
  2018-03-23 21:09   ` Rafael J. Wysocki
  0 siblings, 1 reply; 38+ messages in thread
From: Ingo Molnar @ 2018-03-23  6:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki, Linux-Next Mailing List,
	Linux Kernel Mailing List, Claudio Scordino


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   kernel/sched/cpufreq_schedutil.c
> 
> between commit:
> 
>   0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")

Rafael, could you please send that to the scheduler tree?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2018-03-23  2:20 Stephen Rothwell
  2018-03-23  6:09 ` Ingo Molnar
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2018-03-23  2:20 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Claudio Scordino

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  kernel/sched/cpufreq_schedutil.c

between commit:

  0953feed3400 ("cpufreq: schedutil: rate limits for SCHED_DEADLINE")

from the pm tree and commit:

  8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/sched/cpufreq_schedutil.c
index 04d3fe9ba7d2,89fe78ecb88c..000000000000
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@@ -280,11 -276,9 +286,11 @@@ static void sugov_update_single(struct 
  	unsigned int next_f;
  	bool busy;
  
- 	sugov_set_iowait_boost(sg_cpu, time);
+ 	sugov_set_iowait_boost(sg_cpu, time, flags);
  	sg_cpu->last_update = time;
  
 +	ignore_dl_rate_limit(sg_cpu, sg_policy);
 +
  	if (!sugov_should_update_freq(sg_policy, time))
  		return;
  
@@@ -366,12 -353,7 +365,9 @@@ sugov_update_shared(struct update_util_
  
  	raw_spin_lock(&sg_policy->update_lock);
  
 +	ignore_dl_rate_limit(sg_cpu, sg_policy);
 +
- 	sugov_get_util(sg_cpu);
- 	sg_cpu->flags = flags;
- 
- 	sugov_set_iowait_boost(sg_cpu, time);
+ 	sugov_set_iowait_boost(sg_cpu, time, flags);
  	sg_cpu->last_update = time;
  
  	if (sugov_should_update_freq(sg_policy, time)) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2017-11-06  2:10 Stephen Rothwell
@ 2017-11-06 13:09 ` Rafael J. Wysocki
  0 siblings, 0 replies; 38+ messages in thread
From: Rafael J. Wysocki @ 2017-11-06 13:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux-Next Mailing List, Linux Kernel Mailing List, Jason Baron,
	Andy Lutomirski

On Monday, November 6, 2017 3:10:40 AM CET Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/idle/intel_idle.c
> 
> between commit:
> 
>   0563bb7ba67e ("intel_idle: replace conditionals with static_cpu_has(X86_FEATURE_ARAT)")
> 
> from the pm tree and commit:
> 
>   675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The fix looks good to me, thanks!

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2017-11-06  2:10 Stephen Rothwell
  2017-11-06 13:09 ` Rafael J. Wysocki
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2017-11-06  2:10 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jason Baron,
	Andy Lutomirski

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/idle/intel_idle.c

between commit:

  0563bb7ba67e ("intel_idle: replace conditionals with static_cpu_has(X86_FEATURE_ARAT)")

from the pm tree and commit:

  675357362aeb ("Revert "x86/mm: Stop calling leave_mm() in idle code"")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/idle/intel_idle.c
index 5db5e3176f6a,f0b06b14e782..000000000000
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@@ -913,24 -913,19 +913,25 @@@ static __cpuidle int intel_idle(struct 
  	struct cpuidle_state *state = &drv->states[index];
  	unsigned long eax = flg2MWAIT(state->flags);
  	unsigned int cstate;
 +	bool uninitialized_var(tick);
+ 	int cpu = smp_processor_id();
  
 -	cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
 -
  	/*
- 	 * NB: if CPUIDLE_FLAG_TLB_FLUSHED is set, this idle transition
- 	 * will probably flush the TLB.  It's not guaranteed to flush
- 	 * the TLB, though, so it's not clear that we can do anything
- 	 * useful with this knowledge.
+ 	 * leave_mm() to avoid costly and often unnecessary wakeups
+ 	 * for flushing the user TLB's associated with the active mm.
  	 */
+ 	if (state->flags & CPUIDLE_FLAG_TLB_FLUSHED)
+ 		leave_mm(cpu);
  
 -	if (!(lapic_timer_reliable_states & (1 << (cstate))))
 -		tick_broadcast_enter();
 +	if (!static_cpu_has(X86_FEATURE_ARAT)) {
 +		cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) &
 +				MWAIT_CSTATE_MASK) + 1;
 +		tick = false;
 +		if (!(lapic_timer_reliable_states & (1 << (cstate)))) {
 +			tick = true;
 +			tick_broadcast_enter();
 +		}
 +	}
  
  	mwait_idle_with_hints(eax, ecx);
  

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2017-08-11  4:06 Stephen Rothwell
@ 2017-09-04  4:43 ` Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2017-09-04  4:43 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Viresh Kumar

Hi all,

On Fri, 11 Aug 2017 14:06:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   kernel/sched/fair.c
> 
> between commit:
> 
>   674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")
> 
> from the pm tree and commit:
> 
>   a030d7381d8b ("sched/fair: Call cpufreq update util handlers less frequently on UP")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/sched/fair.c
> index d378d02fdfcb,8d5868771cb3..000000000000
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st
>   }
>   #endif /* CONFIG_FAIR_GROUP_SCHED */
>   
> + static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
> + {
>  -	if (&this_rq()->cfs == cfs_rq) {
> ++	struct rq *rq = rq_of(cfs_rq);
> ++
> ++	if (&rq->cfs == cfs_rq) {
> + 		/*
> + 		 * There are a few boundary cases this might miss but it should
> + 		 * get called often enough that that should (hopefully) not be
> + 		 * a real problem -- added to that it only calls on the local
> + 		 * CPU, so if we enqueue remotely we'll miss an update, but
> + 		 * the next tick/schedule should update.
> + 		 *
> + 		 * It will not get called when we go idle, because the idle
> + 		 * thread is a different class (!fair), nor will the utilization
> + 		 * number include things like RT tasks.
> + 		 *
> + 		 * As is, the util number is not freq-invariant (we'd have to
> + 		 * implement arch_scale_freq_capacity() for that).
> + 		 *
> + 		 * See cpu_util().
> + 		 */
>  -		cpufreq_update_util(rq_of(cfs_rq), 0);
> ++		cpufreq_update_util(rq, 0);
> + 	}
> + }
> + 
>   #ifdef CONFIG_SMP
>   /*
>    * Approximate:

Just a reminder that the above conflict still exists.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2017-08-11  4:06 Stephen Rothwell
  2017-09-04  4:43 ` Stephen Rothwell
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2017-08-11  4:06 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Viresh Kumar

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  kernel/sched/fair.c

between commit:

  674e75411fc2 ("sched: cpufreq: Allow remote cpufreq callbacks")

from the pm tree and commit:

  a030d7381d8b ("sched/fair: Call cpufreq update util handlers less frequently on UP")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/sched/fair.c
index d378d02fdfcb,8d5868771cb3..000000000000
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@@ -2790,6 -2801,29 +2801,31 @@@ static inline void update_cfs_shares(st
  }
  #endif /* CONFIG_FAIR_GROUP_SCHED */
  
+ static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
+ {
 -	if (&this_rq()->cfs == cfs_rq) {
++	struct rq *rq = rq_of(cfs_rq);
++
++	if (&rq->cfs == cfs_rq) {
+ 		/*
+ 		 * There are a few boundary cases this might miss but it should
+ 		 * get called often enough that that should (hopefully) not be
+ 		 * a real problem -- added to that it only calls on the local
+ 		 * CPU, so if we enqueue remotely we'll miss an update, but
+ 		 * the next tick/schedule should update.
+ 		 *
+ 		 * It will not get called when we go idle, because the idle
+ 		 * thread is a different class (!fair), nor will the utilization
+ 		 * number include things like RT tasks.
+ 		 *
+ 		 * As is, the util number is not freq-invariant (we'd have to
+ 		 * implement arch_scale_freq_capacity() for that).
+ 		 *
+ 		 * See cpu_util().
+ 		 */
 -		cpufreq_update_util(rq_of(cfs_rq), 0);
++		cpufreq_update_util(rq, 0);
+ 	}
+ }
+ 
  #ifdef CONFIG_SMP
  /*
   * Approximate:

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2016-11-22  5:48 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2016-11-22  5:48 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Borislav Petkov, Len Brown,
	Wei Yongjun, Arnd Bergmann

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/idle/Kconfig
  drivers/idle/i7300_idle.c

between commits:

  f2f31bb3f50b ("idle / i7300: Add CONFIG_PCI dependency")
  ccd29e2ed6bc ("i7300_idle: avoid theoretical uninitialized data usage")
  881ef1847b2d ("i7300_idle: fix typo in parameter description")

from the pm tree and commit:

  b65ce83f2a60 ("i7300_idle: Remove this driver")

from the tip tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2016-06-09  4:34 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2016-06-09  4:34 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Jacob Pan, Dave Hansen

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/powercap/intel_rapl.c

between commit:

  9b1d0794b70d ("powercap / RAPL: add support for Skylake-X")

from the pm tree and commit:

  62d167330679 ("x86, powercap, rapl: Use Intel model macros intead of open-coding")
  0bb04b5f2c24 ("x86, powercap, rapl: Reorder CPU detection table")
  d40671e30cb4 ("x86, powercap, rapl: Add Skylake Server model number")

from the tip tree.

I fixed it up (I think that last tip tree commit does the same as the
pm tree one, so I used that) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2016-04-19  2:59 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2016-04-19  2:59 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Borislav Petkov, Joe Perches

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/cpufreq/longhaul.c

between commit:

  b49c22a6ca36 ("cpufreq: Convert printk(KERN_<LEVEL> to pr_<level>")

from the pm tree and commit:

  93984fbd4e33 ("x86/cpufeature: Replace cpu_has_apic with boot_cpu_has() usage")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/cpufreq/longhaul.c
index beae5cf5c62c,247bfa8eaddb..000000000000
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@@ -932,8 -945,9 +932,8 @@@ static int __init longhaul_init(void
  	}
  #endif
  #ifdef CONFIG_X86_IO_APIC
- 	if (cpu_has_apic) {
+ 	if (boot_cpu_has(X86_FEATURE_APIC)) {
 -		printk(KERN_ERR PFX "APIC detected. Longhaul is currently "
 -				"broken in this configuration.\n");
 +		pr_err("APIC detected. Longhaul is currently broken in this configuration.\n");
  		return -ENODEV;
  	}
  #endif

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2016-03-15  1:55 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2016-03-15  1:55 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Colin Ian King

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  tools/power/x86/turbostat/turbostat.c

between commit:

  58cc30a4e608 ("tools/power turbostat: fix compiler warnings")

from the pm tree and commit:

  1b69317d2dc8 ("tools/power turbostat: fix various build warnings")

from the tip tree.

I fixed it up (I arbitrarily used the pm tree version) and can carry
the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2016-03-11  1:57 Stephen Rothwell
@ 2016-03-11 13:51 ` Rafael J. Wysocki
  0 siblings, 0 replies; 38+ messages in thread
From: Rafael J. Wysocki @ 2016-03-11 13:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel

On Friday, March 11, 2016 12:57:46 PM Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   kernel/sched/sched.h
> 
> between commit:
> 
>   adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory")
> 
> from the pm tree and commit:
> 
>   e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good to me, thanks!

Rafael

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2016-03-11  1:57 Stephen Rothwell
  2016-03-11 13:51 ` Rafael J. Wysocki
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2016-03-11  1:57 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  kernel/sched/sched.h

between commit:

  adaf9fcd1369 ("cpufreq: Move scheduler-related code to the sched directory")

from the pm tree and commit:

  e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/sched/sched.h
index faf7e2758dd0,e6d4a3fa3660..000000000000
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@@ -1739,50 -1794,15 +1794,63 @@@ static inline u64 irq_time_read(int cpu
  #endif /* CONFIG_64BIT */
  #endif /* CONFIG_IRQ_TIME_ACCOUNTING */
  
 +#ifdef CONFIG_CPU_FREQ
 +DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
 +
 +/**
 + * cpufreq_update_util - Take a note about CPU utilization changes.
 + * @time: Current time.
 + * @util: Current utilization.
 + * @max: Utilization ceiling.
 + *
 + * This function is called by the scheduler on every invocation of
 + * update_load_avg() on the CPU whose utilization is being updated.
 + *
 + * It can only be called from RCU-sched read-side critical sections.
 + */
 +static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
 +{
 +       struct update_util_data *data;
 +
 +       data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
 +       if (data)
 +               data->func(data, time, util, max);
 +}
 +
 +/**
 + * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
 + * @time: Current time.
 + *
 + * The way cpufreq is currently arranged requires it to evaluate the CPU
 + * performance state (frequency/voltage) on a regular basis to prevent it from
 + * being stuck in a completely inadequate performance level for too long.
 + * That is not guaranteed to happen if the updates are only triggered from CFS,
 + * though, because they may not be coming in if RT or deadline tasks are active
 + * all the time (or there are RT and DL tasks only).
 + *
 + * As a workaround for that issue, this function is called by the RT and DL
 + * sched classes to trigger extra cpufreq updates to prevent it from stalling,
 + * but that really is a band-aid.  Going forward it should be replaced with
 + * solutions targeted more specifically at RT and DL tasks.
 + */
 +static inline void cpufreq_trigger_update(u64 time)
 +{
 +	cpufreq_update_util(time, ULONG_MAX, 0);
 +}
 +#else
 +static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) {}
 +static inline void cpufreq_trigger_update(u64 time) {}
 +#endif /* CONFIG_CPU_FREQ */
++
+ static inline void account_reset_rq(struct rq *rq)
+ {
+ #ifdef CONFIG_IRQ_TIME_ACCOUNTING
+ 	rq->prev_irq_time = 0;
+ #endif
+ #ifdef CONFIG_PARAVIRT
+ 	rq->prev_steal_time = 0;
+ #endif
+ #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
+ 	rq->prev_steal_time_rq = 0;
+ #endif
+ }

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2016-02-29  4:42 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2016-02-29  4:42 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Borislav Petkov, Srinivas Pandruvada

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/cpufreq/intel_pstate.c

between commit:

  7791e4aa59ad ("cpufreq: intel_pstate: Enable HWP by default")

from the pm tree and commit:

  bc696ca05f5a ("x86/cpufeature: Replace the old static_cpu_has() with safe variant")

from the tip tree.

I fixed it up (the former removed the code modified by the latter)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2015-10-06  3:07 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2015-10-06  3:07 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Marc Zyngier, Jonathan (Zhixiong) Zhang

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/arm64/kernel/acpi.c

between commit:

  f26527b1428f ("irqchip / GIC: Convert the GIC driver to ACPI probing")

from the pm tree and commit:

  89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/kernel/acpi.c
index d6463bba2360,137d537ddceb..000000000000
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@@ -205,3 -210,52 +210,27 @@@ void __init acpi_boot_table_init(void
  			disable_acpi();
  	}
  }
+ 
 -void __init acpi_gic_init(void)
 -{
 -	struct acpi_table_header *table;
 -	acpi_status status;
 -	acpi_size tbl_size;
 -	int err;
 -
 -	if (acpi_disabled)
 -		return;
 -
 -	status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, &table, &tbl_size);
 -	if (ACPI_FAILURE(status)) {
 -		const char *msg = acpi_format_exception(status);
 -
 -		pr_err("Failed to get MADT table, %s\n", msg);
 -		return;
 -	}
 -
 -	err = gic_v2_acpi_init(table);
 -	if (err)
 -		pr_err("Failed to initialize GIC IRQ controller");
 -
 -	early_acpi_os_unmap_memory((char *)table, tbl_size);
 -}
 -
+ #ifdef CONFIG_ACPI_APEI
+ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+ {
+ 	/*
+ 	 * According to "Table 8 Map: EFI memory types to AArch64 memory
+ 	 * types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
+ 	 * mapped to a corresponding MAIR attribute encoding.
+ 	 * The EFI memory attribute advises all possible capabilities
+ 	 * of a memory region. We use the most efficient capability.
+ 	 */
+ 
+ 	u64 attr;
+ 
+ 	attr = efi_mem_attributes(addr);
+ 	if (attr & EFI_MEMORY_WB)
+ 		return PAGE_KERNEL;
+ 	if (attr & EFI_MEMORY_WT)
+ 		return __pgprot(PROT_NORMAL_WT);
+ 	if (attr & EFI_MEMORY_WC)
+ 		return __pgprot(PROT_NORMAL_NC);
+ 	return __pgprot(PROT_DEVICE_nGnRnE);
+ }
+ #endif

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2015-03-31  7:10 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2015-03-31  7:10 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Viresh Kumar

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/arm/common/bL_switcher.c between commit bf03f36d239f ("arm:
bl_switcher: Kill tick suspend hackery") from the pm tree and commit
77e32c89a711 ("clockevents: Manage device's state separately for the
core") from the tip tree.

I fixed it up (the former removed all the code changed by the latter)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2014-12-15  2:30 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2014-12-15  2:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/apic/io_apic.c between commit 16394fd03114 ("x86 / PM:
Replace CONFIG_PM_RUNTIME in io_apic.c") from the pm tree and various
commits from the tip tree.

I fixed it up (the tip tree seems to have made extensive changes to
this file and there are no longer any references to CONFIG_PM_RUNTIME,
so I used the tip tree version) and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: linux-next: manual merge of the tip tree with the pm tree
  2014-11-25  5:46 Stephen Rothwell
@ 2014-11-25 21:16 ` Rafael J. Wysocki
  0 siblings, 0 replies; 38+ messages in thread
From: Rafael J. Wysocki @ 2014-11-25 21:16 UTC (permalink / raw)
  To: Stephen Rothwell, Hanjun Guo
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Jiang Liu, Yinghai Lu

On Tuesday, November 25, 2014 04:46:40 PM Stephen Rothwell wrote:
> 
> --Sig_/T.+7iMvUwEH92u+UTGF86Po
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
> 
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in
> drivers/acpi/processor_core.c between commit 9d48ea9f967b ("ACPI /
> processor: Convert apic_id to phys_id to make it arch agnostic") from
> the pm tree and commits 5922b6f497ed ("ACPI: Fix minor syntax issues in
> processor_core.c") and 717ed6192d16 ("ACPI: Add interfaces to parse
> IOAPIC ID for IOAPIC hotplug") from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Since the material in my acpi-processor branch is only a cleanup, I'm
dropping it from linux-next.  We'll rebase it and apply it later when
the IOAPIC hotplug stuff settles.

Rafael


> diff --cc drivers/acpi/processor_core.c
> index 0f6f73ed41f2,f124cbb491d9..000000000000
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@@ -67,19 -86,12 +86,12 @@@ static int map_lsapic_id(struct acpi_su
>   static int map_madt_entry(int type, u32 acpi_id)
>   {
>   	unsigned long madt_end, entry;
> - 	static struct acpi_table_madt *madt;
> - 	static int read_madt;
>  -	int apic_id =3D -1;
>  +	int phys_id =3D -1;	/* CPU hardware ID */
> + 	struct acpi_table_madt *madt;
>  =20
> - 	if (!read_madt) {
> - 		if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
> - 					(struct acpi_table_header **)&madt)))
> - 			madt =3D NULL;
> - 		read_madt++;
> - 	}
> -=20
> + 	madt =3D get_madt_table();
>   	if (!madt)
>  -		return apic_id;
>  +		return phys_id;
>  =20
>   	entry =3D (unsigned long)madt;
>   	madt_end =3D entry + madt->header.length;
> @@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha
>   	}
>  =20
>   	header =3D (struct acpi_subtable_header *)obj->buffer.pointer;
> - 	if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC) {
> + 	if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_APIC)
>  -		map_lapic_id(header, acpi_id, &apic_id);
>  +		map_lapic_id(header, acpi_id, &phys_id);
> - 	} else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC) {
> + 	else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_SAPIC)
>  -		map_lsapic_id(header, type, acpi_id, &apic_id);
>  +		map_lsapic_id(header, type, acpi_id, &phys_id);
> - 	} else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC) {
> + 	else if (header->type =3D=3D ACPI_MADT_TYPE_LOCAL_X2APIC)
>  -		map_x2apic_id(header, type, acpi_id, &apic_id);
>  +		map_x2apic_id(header, type, acpi_id, &phys_id);
> - 	}
>  =20
>   exit:
>   	kfree(buffer.pointer);
> @@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp
>  =20
>   int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
>   {
>  -	int apic_id;
>  +	int phys_id;
>  =20
>  -	apic_id =3D acpi_get_apicid(handle, type, acpi_id);
>  +	phys_id =3D acpi_get_phys_id(handle, type, acpi_id);
>  =20
>  -	return acpi_map_cpuid(apic_id, acpi_id);
>  +	return acpi_map_cpuid(phys_id, acpi_id);
>   }
>   EXPORT_SYMBOL_GPL(acpi_get_cpuid);
> +=20
> + #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> + static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
> + 			 u64 *phys_addr, int *ioapic_id)
> + {
> + 	struct acpi_madt_io_apic *ioapic =3D (struct acpi_madt_io_apic *)entry;
> +=20
> + 	if (ioapic->global_irq_base !=3D gsi_base)
> + 		return 0;
> +=20
> + 	*phys_addr =3D ioapic->address;
> + 	*ioapic_id =3D ioapic->id;
> + 	return 1;
> + }
> +=20
> + static int parse_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr)
> + {
> + 	struct acpi_subtable_header *hdr;
> + 	unsigned long madt_end, entry;
> + 	struct acpi_table_madt *madt;
> + 	int apic_id =3D -1;
> +=20
> + 	madt =3D get_madt_table();
> + 	if (!madt)
> + 		return apic_id;
> +=20
> + 	entry =3D (unsigned long)madt;
> + 	madt_end =3D entry + madt->header.length;
> +=20
> + 	/* Parse all entries looking for a match. */
> + 	entry +=3D sizeof(struct acpi_table_madt);
> + 	while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
> + 		hdr =3D (struct acpi_subtable_header *)entry;
> + 		if (hdr->type =3D=3D ACPI_MADT_TYPE_IO_APIC &&
> + 		    get_ioapic_id(hdr, gsi_base, phys_addr, &apic_id))
> + 			break;
> + 		else
> + 			entry +=3D hdr->length;
> + 	}
> +=20
> + 	return apic_id;
> + }
> +=20
> + static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base,
> + 				  u64 *phys_addr)
> + {
> + 	struct acpi_buffer buffer =3D { ACPI_ALLOCATE_BUFFER, NULL };
> + 	struct acpi_subtable_header *header;
> + 	union acpi_object *obj;
> + 	int apic_id =3D -1;
> +=20
> + 	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
> + 		goto exit;
> +=20
> + 	if (!buffer.length || !buffer.pointer)
> + 		goto exit;
> +=20
> + 	obj =3D buffer.pointer;
> + 	if (obj->type !=3D ACPI_TYPE_BUFFER ||
> + 	    obj->buffer.length < sizeof(struct acpi_subtable_header))
> + 		goto exit;
> +=20
> + 	header =3D (struct acpi_subtable_header *)obj->buffer.pointer;
> + 	if (header->type =3D=3D ACPI_MADT_TYPE_IO_APIC)
> + 		get_ioapic_id(header, gsi_base, phys_addr, &apic_id);
> +=20
> + exit:
> + 	kfree(buffer.pointer);
> + 	return apic_id;
> + }
> +=20
> + /**
> +  * acpi_get_ioapic_id - Get IOAPIC ID and physical address matching @gsi_=
> base
> +  * @handle:	ACPI object for IOAPIC device
> +  * @gsi_base:	GSI base to match with
> +  * @phys_addr:	Pointer to store physical address of matching IOAPIC record
> +  *
> +  * Walk resources returned by ACPI_MAT method, then ACPI MADT table, to s=
> earch
> +  * for an ACPI IOAPIC record matching @gsi_base.
> +  * Return IOAPIC id and store physical address in @phys_addr if found a m=
> atch,
> +  * otherwise return <0.
> +  */
> + int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr)
> + {
> + 	int apic_id;
> +=20
> + 	apic_id =3D parse_mat_ioapic_entry(handle, gsi_base, phys_addr);
> + 	if (apic_id =3D=3D -1)
> + 		apic_id =3D parse_madt_ioapic_entry(gsi_base, phys_addr);
> +=20
> + 	return apic_id;
> + }
> + #endif /* CONFIG_ACPI_HOTPLUG_IOAPIC */
> 
> --Sig_/T.+7iMvUwEH92u+UTGF86Po
> Content-Type: application/pgp-signature
> Content-Description: OpenPGP digital signature
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJUdBfGAAoJEMDTa8Ir7ZwVeAMP/jT/rc43RxXIRBIBOb9oWDuE
> NTEMECD6ziGKOS2fqz+BqdAEDLi+wdYn3ba52U8SHTXBFN63lQc5ISQ+EUpeR7Pb
> jp5i9BiiL2RPPNSjQNZ8x1EZSnnGkIo9DwfH3uq75SwTDT+a8kMH618QGb0oDasY
> duafSmDbvVSxPZevxWtCsdLjU52ssB64PKUiugCBJyhup4JQW8wWdZ30w7AkUbUQ
> sBFtR01BXtLZ/wNX971821APvs/c/rZHE6a6cZoasN98E4p38k0pGcLrcUGiqdIO
> ORckMzsQghFj1gAMxzyHRg1c09ORuE19AZlAHF4W2nKJ18tW66/QG8+HCk+Z3R8z
> zkfOm5QFuQbYLoMyhyZ2HTZrxK2hkBVo6GNCmCpYBL0QpK/N2QU02A9lcNfFkYqm
> LX+IERxyEd1z1oNust3svRr5NKU3BEbdfXblAYtUIORTws+YDkZrc7SyksdCSIOa
> az7mmTxDcR/uQ8K/7SVO/D3nlutZm8MkYb5gFCbBaI7O5rmRACDMgYGlh0vCZ2dL
> tes0YBlsTBPWcHxb+/y6IsFs6HEZrPKPAQUu4wPJmcRb8PuJ95gxwUODSmf2duxL
> HJOWkci/j/ViNmJ/paVuI5MpJyHUMBf6oo/ze1IkL/4PKK2b4+drvyCY9KwV7Mjn
> dLsMDuJV/i959NkJa4EE
> =+Uu8
> -----END PGP SIGNATURE-----
> 
> --Sig_/T.+7iMvUwEH92u+UTGF86Po--
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2014-11-25  5:46 Stephen Rothwell
  2014-11-25 21:16 ` Rafael J. Wysocki
  0 siblings, 1 reply; 38+ messages in thread
From: Stephen Rothwell @ 2014-11-25  5:46 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Hanjun Guo, Jiang Liu, Yinghai Lu

[-- Attachment #1: Type: text/plain, Size: 5475 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/processor_core.c between commit 9d48ea9f967b ("ACPI /
processor: Convert apic_id to phys_id to make it arch agnostic") from
the pm tree and commits 5922b6f497ed ("ACPI: Fix minor syntax issues in
processor_core.c") and 717ed6192d16 ("ACPI: Add interfaces to parse
IOAPIC ID for IOAPIC hotplug") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/acpi/processor_core.c
index 0f6f73ed41f2,f124cbb491d9..000000000000
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@@ -67,19 -86,12 +86,12 @@@ static int map_lsapic_id(struct acpi_su
  static int map_madt_entry(int type, u32 acpi_id)
  {
  	unsigned long madt_end, entry;
- 	static struct acpi_table_madt *madt;
- 	static int read_madt;
 -	int apic_id = -1;
 +	int phys_id = -1;	/* CPU hardware ID */
+ 	struct acpi_table_madt *madt;
  
- 	if (!read_madt) {
- 		if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
- 					(struct acpi_table_header **)&madt)))
- 			madt = NULL;
- 		read_madt++;
- 	}
- 
+ 	madt = get_madt_table();
  	if (!madt)
 -		return apic_id;
 +		return phys_id;
  
  	entry = (unsigned long)madt;
  	madt_end = entry + madt->header.length;
@@@ -125,13 -137,12 +137,12 @@@ static int map_mat_entry(acpi_handle ha
  	}
  
  	header = (struct acpi_subtable_header *)obj->buffer.pointer;
- 	if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
+ 	if (header->type == ACPI_MADT_TYPE_LOCAL_APIC)
 -		map_lapic_id(header, acpi_id, &apic_id);
 +		map_lapic_id(header, acpi_id, &phys_id);
- 	} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
+ 	else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC)
 -		map_lsapic_id(header, type, acpi_id, &apic_id);
 +		map_lsapic_id(header, type, acpi_id, &phys_id);
- 	} else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
+ 	else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC)
 -		map_x2apic_id(header, type, acpi_id, &apic_id);
 +		map_x2apic_id(header, type, acpi_id, &phys_id);
- 	}
  
  exit:
  	kfree(buffer.pointer);
@@@ -197,10 -208,103 +208,103 @@@ int acpi_map_cpuid(int phys_id, u32 acp
  
  int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
  {
 -	int apic_id;
 +	int phys_id;
  
 -	apic_id = acpi_get_apicid(handle, type, acpi_id);
 +	phys_id = acpi_get_phys_id(handle, type, acpi_id);
  
 -	return acpi_map_cpuid(apic_id, acpi_id);
 +	return acpi_map_cpuid(phys_id, acpi_id);
  }
  EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+ 
+ #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+ static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
+ 			 u64 *phys_addr, int *ioapic_id)
+ {
+ 	struct acpi_madt_io_apic *ioapic = (struct acpi_madt_io_apic *)entry;
+ 
+ 	if (ioapic->global_irq_base != gsi_base)
+ 		return 0;
+ 
+ 	*phys_addr = ioapic->address;
+ 	*ioapic_id = ioapic->id;
+ 	return 1;
+ }
+ 
+ static int parse_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr)
+ {
+ 	struct acpi_subtable_header *hdr;
+ 	unsigned long madt_end, entry;
+ 	struct acpi_table_madt *madt;
+ 	int apic_id = -1;
+ 
+ 	madt = get_madt_table();
+ 	if (!madt)
+ 		return apic_id;
+ 
+ 	entry = (unsigned long)madt;
+ 	madt_end = entry + madt->header.length;
+ 
+ 	/* Parse all entries looking for a match. */
+ 	entry += sizeof(struct acpi_table_madt);
+ 	while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+ 		hdr = (struct acpi_subtable_header *)entry;
+ 		if (hdr->type == ACPI_MADT_TYPE_IO_APIC &&
+ 		    get_ioapic_id(hdr, gsi_base, phys_addr, &apic_id))
+ 			break;
+ 		else
+ 			entry += hdr->length;
+ 	}
+ 
+ 	return apic_id;
+ }
+ 
+ static int parse_mat_ioapic_entry(acpi_handle handle, u32 gsi_base,
+ 				  u64 *phys_addr)
+ {
+ 	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ 	struct acpi_subtable_header *header;
+ 	union acpi_object *obj;
+ 	int apic_id = -1;
+ 
+ 	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
+ 		goto exit;
+ 
+ 	if (!buffer.length || !buffer.pointer)
+ 		goto exit;
+ 
+ 	obj = buffer.pointer;
+ 	if (obj->type != ACPI_TYPE_BUFFER ||
+ 	    obj->buffer.length < sizeof(struct acpi_subtable_header))
+ 		goto exit;
+ 
+ 	header = (struct acpi_subtable_header *)obj->buffer.pointer;
+ 	if (header->type == ACPI_MADT_TYPE_IO_APIC)
+ 		get_ioapic_id(header, gsi_base, phys_addr, &apic_id);
+ 
+ exit:
+ 	kfree(buffer.pointer);
+ 	return apic_id;
+ }
+ 
+ /**
+  * acpi_get_ioapic_id - Get IOAPIC ID and physical address matching @gsi_base
+  * @handle:	ACPI object for IOAPIC device
+  * @gsi_base:	GSI base to match with
+  * @phys_addr:	Pointer to store physical address of matching IOAPIC record
+  *
+  * Walk resources returned by ACPI_MAT method, then ACPI MADT table, to search
+  * for an ACPI IOAPIC record matching @gsi_base.
+  * Return IOAPIC id and store physical address in @phys_addr if found a match,
+  * otherwise return <0.
+  */
+ int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr)
+ {
+ 	int apic_id;
+ 
+ 	apic_id = parse_mat_ioapic_entry(handle, gsi_base, phys_addr);
+ 	if (apic_id == -1)
+ 		apic_id = parse_madt_ioapic_entry(gsi_base, phys_addr);
+ 
+ 	return apic_id;
+ }
+ #endif /* CONFIG_ACPI_HOTPLUG_IOAPIC */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2014-08-04  6:55 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2014-08-04  6:55 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Tomasz Nowicki, Graeme Gregory, Hanjun Guo

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/Kconfig between commit 8a1664be0b92 ("ACPI: add config for
BIOS table scan") from the pm tree and commit 44a69f619562 ("acpi, apei,
ghes: Make NMI error notification to be GHES architecture extension")
from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/Kconfig
index ac5a788d2432,4559c4e114d1..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -133,7 -132,8 +133,9 @@@ config X8
  	select GENERIC_CPU_AUTOPROBE
  	select HAVE_ARCH_AUDITSYSCALL
  	select ARCH_SUPPORTS_ATOMIC_RMW
 +	select ACPI_LEGACY_TABLES_LOOKUP if ACPI
+ 	select HAVE_ACPI_APEI if ACPI
+ 	select HAVE_ACPI_APEI_NMI if ACPI
  
  config INSTRUCTION_DECODER
  	def_bool y

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2014-05-09  4:49 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2014-05-09  4:49 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 4723 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
kernel/sched/idle.c between commit 52c324f8a87b ("cpuidle: Combine
cpuidle_enabled() with cpuidle_select()") from the pm tree and commit
37352273ad48 ("sched/idle: Reflow cpuidle_idle_call()") from the tip
tree.

I fixed it up (I hope - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched/idle.c
index a8f12247ce7c,34083c9ac976..000000000000
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@@ -101,77 -98,74 +98,69 @@@ static void cpuidle_idle_call(void
  	rcu_idle_enter();
  
  	/*
 -	 * Check if the cpuidle framework is ready, otherwise fallback
 -	 * to the default arch specific idle method
 +	 * Ask the cpuidle framework to choose a convenient idle state.
 +	 * Fall back to the default arch specific idle method on errors.
  	 */
 -	if (cpuidle_enabled(drv, dev)) {
 +	next_state = cpuidle_select(drv, dev);
 +
- 	ret = next_state;
- 	if (ret >= 0) {
++	if (next_state < 0) {
+ use_default:
  		/*
- 		 * The idle task must be scheduled, it is pointless to
- 		 * go to idle, just update no idle residency and get
- 		 * out of this function
+ 		 * We can't use the cpuidle framework, let's use the default
+ 		 * idle routine.
  		 */
- 		if (current_clr_polling_and_test()) {
- 			dev->last_residency = 0;
- 			entered_state = next_state;
+ 		if (current_clr_polling_and_test())
  			local_irq_enable();
- 		} else {
- 			broadcast = !!(drv->states[next_state].flags &
- 				       CPUIDLE_FLAG_TIMER_STOP);
- 
- 			if (broadcast)
- 				/*
- 				 * Tell the time framework to switch
- 				 * to a broadcast timer because our
- 				 * local timer will be shutdown. If a
- 				 * local timer is used from another
- 				 * cpu as a broadcast timer, this call
- 				 * may fail if it is not available
- 				 */
- 				ret = clockevents_notify(
- 					CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
- 					&dev->cpu);
- 
- 			if (ret >= 0) {
- 				trace_cpu_idle_rcuidle(next_state, dev->cpu);
- 
- 				/*
- 				 * Enter the idle state previously
- 				 * returned by the governor
- 				 * decision. This function will block
- 				 * until an interrupt occurs and will
- 				 * take care of re-enabling the local
- 				 * interrupts
- 				 */
- 				entered_state = cpuidle_enter(drv, dev,
- 							      next_state);
- 
- 				trace_cpu_idle_rcuidle(PWR_EVENT_EXIT,
- 						       dev->cpu);
- 
- 				if (broadcast)
- 					clockevents_notify(
- 						CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
- 						&dev->cpu);
- 
- 				/*
- 				 * Give the governor an opportunity to reflect on the
- 				 * outcome
- 				 */
- 				cpuidle_reflect(dev, entered_state);
- 			}
- 		}
+ 		else
+ 			arch_cpu_idle();
+ 
+ 		goto exit_idle;
+ 	}
+ 
+ 	/*
 -	 * Ask the governor to choose an idle state it thinks
 -	 * it is convenient to go to. There is *always* a
 -	 * convenient idle state
 -	 */
 -	next_state = cpuidle_select(drv, dev);
 -
 -	/*
+ 	 * The idle task must be scheduled, it is pointless to
+ 	 * go to idle, just update no idle residency and get
+ 	 * out of this function
+ 	 */
+ 	if (current_clr_polling_and_test()) {
+ 		dev->last_residency = 0;
+ 		entered_state = next_state;
+ 		local_irq_enable();
+ 		goto exit_idle;
  	}
  
+ 	broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
+ 
  	/*
- 	 * We can't use the cpuidle framework, let's use the default
- 	 * idle routine
+ 	 * Tell the time framework to switch to a broadcast timer
+ 	 * because our local timer will be shutdown. If a local timer
+ 	 * is used from another cpu as a broadcast timer, this call may
+ 	 * fail if it is not available
  	 */
- 	if (ret < 0)
- 		arch_cpu_idle();
+ 	if (broadcast &&
 -	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu))
++	    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu) < 0)
+ 		goto use_default;
  
+ 	trace_cpu_idle_rcuidle(next_state, dev->cpu);
+ 
+ 	/*
+ 	 * Enter the idle state previously returned by the governor decision.
+ 	 * This function will block until an interrupt occurs and will take
+ 	 * care of re-enabling the local interrupts
+ 	 */
+ 	entered_state = cpuidle_enter(drv, dev, next_state);
+ 
+ 	trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
+ 
+ 	if (broadcast)
+ 		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+ 
+ 	/*
+ 	 * Give the governor an opportunity to reflect on the outcome
+ 	 */
+ 	cpuidle_reflect(dev, entered_state);
+ 
+ exit_idle:
  	__current_set_polling();
  
  	/*

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2014-01-13  3:29 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2014-01-13  3:29 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Lv Zheng, Chen, Gong, Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/apei/einj.c between commit 8b48463f8942 ("ACPI: Clean up
inclusions of ACPI header files") from the pm tree and commit
d3ab3edc029b ("ACPI, APEI: Cleanup alignment-aware accesses") from the
tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/acpi/apei/einj.c
index ca0c6d7ec0d4,7dcc8a824aae..000000000000
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@@ -33,6 -33,8 +33,7 @@@
  #include <linux/nmi.h>
  #include <linux/delay.h>
  #include <linux/mm.h>
 -#include <acpi/acpi.h>
+ #include <asm/unaligned.h>
  
  #include "apei-internal.h"
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2014-01-07  4:20 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2014-01-07  4:20 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Bartlomiej Zolnierkiewicz

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/processor_idle.c between commit 6cb85b2b9df9 ("ACPI /
cpuidle: fix max idle state handling with hotplug CPU support") from the
pm tree and commit 16824255394f ("x86, acpi, idle: Restructure the mwait
idle routines") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/acpi/processor_idle.c
index 1fc455b8ce17,f90c56c8379e..000000000000
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@@ -783,18 -780,6 +778,13 @@@ static int acpi_idle_enter_simple(struc
  	if (unlikely(!pr))
  		return -EINVAL;
  
 +#ifdef CONFIG_HOTPLUG_CPU
 +	if ((cx->type != ACPI_STATE_C1) && (num_online_cpus() > 1) &&
 +	    !pr->flags.has_cst &&
 +	    !(acpi_gbl_FADT.flags & ACPI_FADT_C2_MP_SUPPORTED))
 +		return acpi_idle_enter_c1(dev, drv, CPUIDLE_DRIVER_STATE_START);
 +#endif
 +
- 	if (cx->entry_method == ACPI_CSTATE_FFH) {
- 		if (current_set_polling_and_test())
- 			return -EINVAL;
- 	}
- 
  	/*
  	 * Must be done before busmaster disable as we might need to
  	 * access HPET !

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2014-01-06  7:18 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2014-01-06  7:18 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Chen, Gong, Borislav Petkov, Jiang Liu

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/acpi/acpi_extlog.c between commit 7ede9f8a1805 ("ACPI / extlog:
replace open-coded _DSM code with helper functions") from the pm tree and
commit 42139eb356e3 ("ACPI, eMCA: Combine eMCA/EDAC event reporting
priority") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/acpi/acpi_extlog.c
index 94166680b3a3,5d33c5415405..000000000000
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@@ -9,8 -9,10 +9,9 @@@
  
  #include <linux/module.h>
  #include <linux/acpi.h>
 -#include <acpi/acpi_bus.h>
  #include <linux/cper.h>
  #include <linux/ratelimit.h>
+ #include <linux/edac.h>
  #include <asm/cpu.h>
  #include <asm/mce.h>
  
@@@ -40,7 -44,9 +41,9 @@@ struct extlog_l1_head 
  	u8  rev1[12];
  };
  
+ static int old_edac_report_status;
+ 
 -static u8 extlog_dsm_uuid[] = "663E35AF-CC10-41A4-88EA-5470AF055295";
 +static u8 extlog_dsm_uuid[] __initdata = "663E35AF-CC10-41A4-88EA-5470AF055295";
  
  /* L1 table related physical address */
  static u64 elog_base;
@@@ -147,16 -153,53 +150,16 @@@ static int extlog_print(struct notifier
  
  	rc = print_extlog_rcd(NULL, (struct acpi_generic_status *)elog_buf, cpu);
  
- 	return NOTIFY_DONE;
+ 	return NOTIFY_STOP;
  }
  
 -static int extlog_get_dsm(acpi_handle handle, int rev, int func, u64 *ret)
 +static bool __init extlog_get_l1addr(void)
  {
 -	struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL};
 -	struct acpi_object_list input;
 -	union acpi_object params[4], *obj;
  	u8 uuid[16];
 -	int i;
 +	acpi_handle handle;
 +	union acpi_object *obj;
  
  	acpi_str_to_uuid(extlog_dsm_uuid, uuid);
 -	input.count = 4;
 -	input.pointer = params;
 -	params[0].type = ACPI_TYPE_BUFFER;
 -	params[0].buffer.length = 16;
 -	params[0].buffer.pointer = uuid;
 -	params[1].type = ACPI_TYPE_INTEGER;
 -	params[1].integer.value = rev;
 -	params[2].type = ACPI_TYPE_INTEGER;
 -	params[2].integer.value = func;
 -	params[3].type = ACPI_TYPE_PACKAGE;
 -	params[3].package.count = 0;
 -	params[3].package.elements = NULL;
 -
 -	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_DSM", &input, &buf)))
 -		return -1;
 -
 -	*ret = 0;
 -	obj = (union acpi_object *)buf.pointer;
 -	if (obj->type == ACPI_TYPE_INTEGER) {
 -		*ret = obj->integer.value;
 -	} else if (obj->type == ACPI_TYPE_BUFFER) {
 -		if (obj->buffer.length <= 8) {
 -			for (i = 0; i < obj->buffer.length; i++)
 -				*ret |= (obj->buffer.pointer[i] << (i * 8));
 -		}
 -	}
 -	kfree(buf.pointer);
 -
 -	return 0;
 -}
 -
 -static bool extlog_get_l1addr(void)
 -{
 -	acpi_handle handle;
 -	u64 ret;
  
  	if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)))
  		return false;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2013-08-19  4:09 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2013-08-19  4:09 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Stratos Karafotis, Rafael J. Wysocki,
	Jason Wang

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/include/asm/processor.h between commit 61c63e5ed3b9 ("cpufreq:
Remove unused APERF/MPERF support") from the pm tree and commit
96e39ac0e9d1 ("x86: Introduce hypervisor_cpuid_base()") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/include/asm/processor.h
index 4f4a3d9,61a5533..0000000
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@@ -942,6 -942,50 +942,21 @@@ extern int set_tsc_mode(unsigned int va
  
  extern u16 amd_get_nb_id(int cpu);
  
 -struct aperfmperf {
 -	u64 aperf, mperf;
 -};
 -
 -static inline void get_aperfmperf(struct aperfmperf *am)
 -{
 -	WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_APERFMPERF));
 -
 -	rdmsrl(MSR_IA32_APERF, am->aperf);
 -	rdmsrl(MSR_IA32_MPERF, am->mperf);
 -}
 -
 -#define APERFMPERF_SHIFT 10
 -
 -static inline
 -unsigned long calc_aperfmperf_ratio(struct aperfmperf *old,
 -				    struct aperfmperf *new)
 -{
 -	u64 aperf = new->aperf - old->aperf;
 -	u64 mperf = new->mperf - old->mperf;
 -	unsigned long ratio = aperf;
 -
 -	mperf >>= APERFMPERF_SHIFT;
 -	if (mperf)
 -		ratio = div64_u64(aperf, mperf);
 -
 -	return ratio;
 -}
 -
+ static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
+ {
+ 	uint32_t base, eax, signature[3];
+ 
+ 	for (base = 0x40000000; base < 0x40010000; base += 0x100) {
+ 		cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
+ 
+ 		if (!memcmp(sig, signature, 12) &&
+ 		    (leaves == 0 || ((eax - base) >= leaves)))
+ 			return base;
+ 	}
+ 
+ 	return 0;
+ }
+ 
  extern unsigned long arch_align_stack(unsigned long sp);
  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* linux-next: manual merge of the tip tree with the pm tree
@ 2013-04-11  4:08 Stephen Rothwell
  0 siblings, 0 replies; 38+ messages in thread
From: Stephen Rothwell @ 2013-04-11  4:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Daniel Lezcano, Rafael J. Wysocki

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
include/linux/clockchips.h between commit 4dbad816febb ("timer: move enum
definition out of ifdef section") from the pm tree and commit
19919226c3f2 ("clockevents: Add missing tick_check_broadcast_expired()
for CLOCKEVENTS=n") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/clockchips.h
index f9fd937,464e229..0000000
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@@ -181,7 -192,8 +192,8 @@@ static inline void clockevents_notify(u
  static inline void clockevents_suspend(void) {}
  static inline void clockevents_resume(void) {}
  
 -#define clockevents_notify(reason, arg) do { } while (0)
 +static inline void clockevents_notify(unsigned long reason, void *arg) {}
+ static inline int tick_check_broadcast_expired(void) { return 0; }
  
  #endif
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2021-02-22  0:35 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-31  7:58 linux-next: manual merge of the tip tree with the pm tree Stephen Rothwell
2015-03-31 22:23 ` Rafael J. Wysocki
  -- strict thread matches above, loose matches on Subject: below --
2021-02-17  5:07 Stephen Rothwell
2021-02-17 10:15 ` Andy Shevchenko
2021-02-22  0:34 ` Stephen Rothwell
2018-10-08  2:44 Stephen Rothwell
2018-10-08 10:06 ` Rafael J. Wysocki
2018-10-08 10:34   ` Andy Shevchenko
2018-10-08  2:40 Stephen Rothwell
2018-10-08 10:05 ` Rafael J. Wysocki
2018-10-08 10:41   ` Andy Shevchenko
2018-03-23  2:20 Stephen Rothwell
2018-03-23  6:09 ` Ingo Molnar
2018-03-23 21:09   ` Rafael J. Wysocki
2018-03-24  8:15     ` Ingo Molnar
2017-11-06  2:10 Stephen Rothwell
2017-11-06 13:09 ` Rafael J. Wysocki
2017-08-11  4:06 Stephen Rothwell
2017-09-04  4:43 ` Stephen Rothwell
2016-11-22  5:48 Stephen Rothwell
2016-06-09  4:34 Stephen Rothwell
2016-04-19  2:59 Stephen Rothwell
2016-03-15  1:55 Stephen Rothwell
2016-03-11  1:57 Stephen Rothwell
2016-03-11 13:51 ` Rafael J. Wysocki
2016-02-29  4:42 Stephen Rothwell
2015-10-06  3:07 Stephen Rothwell
2015-03-31  7:10 Stephen Rothwell
2014-12-15  2:30 Stephen Rothwell
2014-11-25  5:46 Stephen Rothwell
2014-11-25 21:16 ` Rafael J. Wysocki
2014-08-04  6:55 Stephen Rothwell
2014-05-09  4:49 Stephen Rothwell
2014-01-13  3:29 Stephen Rothwell
2014-01-07  4:20 Stephen Rothwell
2014-01-06  7:18 Stephen Rothwell
2013-08-19  4:09 Stephen Rothwell
2013-04-11  4:08 Stephen Rothwell

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).