Hi all,
Today's linux-next merge of the arm64 tree got a conflict in:
arch/arm64/Kconfig
between commit:
68a63a412d18 ("arm64: Fix build with CC=clang, CONFIG_FTRACE=y and CONFIG_STACK_TRACER=y")
from Linus' tree and commit:
baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS")
from the arm64 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 arch/arm64/Kconfig
index c5ccca26a408,de052d935832..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -184,6 -186,10 +186,8 @@@ config ARM6
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
- select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
- if $(cc-option,-fpatchable-function-entry=2)
+ select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
+ if (DYNAMIC_FTRACE_WITH_ARGS && !CFI_CLANG)
select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
if DYNAMIC_FTRACE_WITH_ARGS
select HAVE_EFFICIENT_UNALIGNED_ACCESS
On Wed, Jan 25, 2023 at 08:36:47AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> arch/arm64/Kconfig
>
> between commit:
>
> 68a63a412d18 ("arm64: Fix build with CC=clang, CONFIG_FTRACE=y and CONFIG_STACK_TRACER=y")
>
> from Linus' tree and commit:
>
> baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS")
>
> from the arm64 tree.
[...]
> diff --cc arch/arm64/Kconfig
> index c5ccca26a408,de052d935832..000000000000
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@@ -184,6 -186,10 +186,8 @@@ config ARM6
> select HAVE_DEBUG_KMEMLEAK
> select HAVE_DMA_CONTIGUOUS
> select HAVE_DYNAMIC_FTRACE
> - select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
> - if $(cc-option,-fpatchable-function-entry=2)
> + select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
> + if (DYNAMIC_FTRACE_WITH_ARGS && !CFI_CLANG)
> select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
> if DYNAMIC_FTRACE_WITH_ARGS
> select HAVE_EFFICIENT_UNALIGNED_ACCESS
Thanks Stephen. It looks fine.
--
Catalin
On Mon, Nov 13, 2017 at 09:15:08AM +0000, Catalin Marinas wrote:
> Hi Stephen,
>
> On Mon, Nov 13, 2017 at 05:09:53PM +1100, Stephen Rothwell wrote:
> > On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell <[email protected]> wrote:
> > > Today's linux-next merge of the arm64 tree got a conflict in:
> > >
> > > drivers/acpi/arm64/iort.c
> > >
> > > between commit:
> > >
> > > 37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement")
> > >
> > > from Linus' tree and commit:
> > >
> > > 896dd2c32484 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")
> > >
> > > from the arm64 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.
> [...]
> > > diff --cc drivers/acpi/arm64/iort.c
> > > index de56394dd161,7dc964f4d8f1..000000000000
> > > --- a/drivers/acpi/arm64/iort.c
> > > +++ b/drivers/acpi/arm64/iort.c
> > > @@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
> > > struct acpi_table_iort *iort;
> > > struct fwnode_handle *fwnode;
> > > int i, ret;
> > > + bool acs_enabled = false;
> > > + const struct iort_dev_config *ops;
> > >
> > > /*
> > > * iort_table and iort both point to the start of IORT table, but
> > > @@@ -1235,12 -1346,8 +1378,11 @@@
> > > return;
> > > }
> > >
> > > + if (!acs_enabled)
> > > + acs_enabled = iort_enable_acs(iort_node);
> > > +
> > > - if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> > > - (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> > > -
> > > + ops = iort_get_dev_cfg(iort_node);
> > > + if (ops) {
> > > fwnode = acpi_alloc_fwnode_static();
> > > if (!fwnode)
> > > return;
> >
> > Just a reminder that this conflict still exists.
>
> Thanks for the reminder. Will (cc'ed) is handling this merging window
> and AFAIK the pull request will go with this conflict unsolved (to avoid
> a back merge from a newer Linus tree commit).
Indeed, that's the planned course of action, thanks for the heads-up.
Lorenzo
From 1583941789211937208@xxx Mon Nov 13 09:16:43 +0000 2017
X-GM-THRID: 1582808208574620566
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hi Stephen,
On Mon, Nov 13, 2017 at 05:09:53PM +1100, Stephen Rothwell wrote:
> On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell <[email protected]> wrote:
> > Today's linux-next merge of the arm64 tree got a conflict in:
> >
> > drivers/acpi/arm64/iort.c
> >
> > between commit:
> >
> > 37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement")
> >
> > from Linus' tree and commit:
> >
> > 896dd2c32484 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")
> >
> > from the arm64 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.
[...]
> > diff --cc drivers/acpi/arm64/iort.c
> > index de56394dd161,7dc964f4d8f1..000000000000
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
> > struct acpi_table_iort *iort;
> > struct fwnode_handle *fwnode;
> > int i, ret;
> > + bool acs_enabled = false;
> > + const struct iort_dev_config *ops;
> >
> > /*
> > * iort_table and iort both point to the start of IORT table, but
> > @@@ -1235,12 -1346,8 +1378,11 @@@
> > return;
> > }
> >
> > + if (!acs_enabled)
> > + acs_enabled = iort_enable_acs(iort_node);
> > +
> > - if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> > - (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> > -
> > + ops = iort_get_dev_cfg(iort_node);
> > + if (ops) {
> > fwnode = acpi_alloc_fwnode_static();
> > if (!fwnode)
> > return;
>
> Just a reminder that this conflict still exists.
Thanks for the reminder. Will (cc'ed) is handling this merging window
and AFAIK the pull request will go with this conflict unsolved (to avoid
a back merge from a newer Linus tree commit).
--
Catalin
From 1583930090601609436@xxx Mon Nov 13 06:10:46 +0000 2017
X-GM-THRID: 1582808208574620566
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hi all,
On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next merge of the arm64 tree got a conflict in:
>
> drivers/acpi/arm64/iort.c
>
> between commit:
>
> 37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement")
>
> from Linus' tree and commit:
>
> 896dd2c32484 ("ACPI/IORT: Make platform devices initialization code SMMU agnostic")
>
> from the arm64 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/acpi/arm64/iort.c
> index de56394dd161,7dc964f4d8f1..000000000000
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@@ -1215,7 -1326,7 +1357,8 @@@ static void __init iort_init_platform_d
> struct acpi_table_iort *iort;
> struct fwnode_handle *fwnode;
> int i, ret;
> + bool acs_enabled = false;
> + const struct iort_dev_config *ops;
>
> /*
> * iort_table and iort both point to the start of IORT table, but
> @@@ -1235,12 -1346,8 +1378,11 @@@
> return;
> }
>
> + if (!acs_enabled)
> + acs_enabled = iort_enable_acs(iort_node);
> +
> - if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
> - (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
> -
> + ops = iort_get_dev_cfg(iort_node);
> + if (ops) {
> fwnode = acpi_alloc_fwnode_static();
> if (!fwnode)
> return;
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
From 1582808208574620566@xxx Tue Oct 31 20:58:56 +0000 2017
X-GM-THRID: 1582808208574620566
X-Gmail-Labels: Inbox,Category Forums