Hi all,
Today's linux-next merge of the risc-v tree got a conflict in:
arch/arm64/kernel/topology.c
between commit:
98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")
from the arm64 tree and commit:
60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")
from the risc-v 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/kernel/topology.c
index 6106c49f84bc,6b95c91e7d67..000000000000
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@@ -296,72 -59,21 +59,32 @@@ topology_populated
update_siblings_masks(cpuid);
}
- static void clear_cpu_topology(int cpu)
- {
- struct cpu_topology *cpu_topo = &cpu_topology[cpu];
-
- cpumask_clear(&cpu_topo->llc_sibling);
- cpumask_set_cpu(cpu, &cpu_topo->llc_sibling);
-
- cpumask_clear(&cpu_topo->core_sibling);
- cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
- cpumask_clear(&cpu_topo->thread_sibling);
- cpumask_set_cpu(cpu, &cpu_topo->thread_sibling);
- }
-
- static void __init reset_cpu_topology(void)
- {
- unsigned int cpu;
-
- for_each_possible_cpu(cpu) {
- struct cpu_topology *cpu_topo = &cpu_topology[cpu];
-
- cpu_topo->thread_id = -1;
- cpu_topo->core_id = 0;
- cpu_topo->package_id = -1;
- cpu_topo->llc_id = -1;
-
- clear_cpu_topology(cpu);
- }
- }
-
- void remove_cpu_topology(unsigned int cpu)
- {
- int sibling;
-
- for_each_cpu(sibling, topology_core_cpumask(cpu))
- cpumask_clear_cpu(cpu, topology_core_cpumask(sibling));
- for_each_cpu(sibling, topology_sibling_cpumask(cpu))
- cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling));
- for_each_cpu(sibling, topology_llc_cpumask(cpu))
- cpumask_clear_cpu(cpu, topology_llc_cpumask(sibling));
-
- clear_cpu_topology(cpu);
- }
-
#ifdef CONFIG_ACPI
+static bool __init acpi_cpu_is_threaded(int cpu)
+{
+ int is_threaded = acpi_pptt_cpu_is_thread(cpu);
+
+ /*
+ * if the PPTT doesn't have thread information, assume a homogeneous
+ * machine and return the current CPU's thread state.
+ */
+ if (is_threaded < 0)
+ is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
+
+ return !!is_threaded;
+}
+
/*
* Propagate the topology information of the processor_topology_node tree to the
* cpu_topology array.
*/
- static int __init parse_acpi_topology(void)
+ int __init parse_acpi_topology(void)
{
- bool is_threaded;
int cpu, topology_id;
+ if (acpi_disabled)
+ return 0;
+
- is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
-
for_each_possible_cpu(cpu) {
int i, cache_id;
On Tue, Aug 13, 2019 at 09:34:47AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the risc-v tree got a conflict in:
>
> arch/arm64/kernel/topology.c
>
> between commit:
>
> 98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")
>
> from the arm64 tree and commit:
>
> 60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")
>
> from the risc-v 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.
Thanks, Stephen.
Paul, Palmer -- If it's not too late, then it would probably be best to
stick this commit (60c1b220d8bc) and any dependencies on their own stable
branch so that we can both pull it into our respective trees and I can
resolve this conflict in the arm64 tree, which I'll send early during the
merge window.
Looking at your tree, I guess I could just pull in
common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
that, you could fork a new branch from 60c1b220d8bc and I could just pull
that part instead.
Please let me know.
Will
On Tue, Aug 13, 2019 at 06:42:11PM +1000, Stephen Rothwell wrote:
> On Tue, 13 Aug 2019 09:24:23 +0100 Will Deacon <[email protected]> wrote:
> >
> > Paul, Palmer -- If it's not too late, then it would probably be best to
> > stick this commit (60c1b220d8bc) and any dependencies on their own stable
> > branch so that we can both pull it into our respective trees and I can
> > resolve this conflict in the arm64 tree, which I'll send early during the
> > merge window.
> >
> > Looking at your tree, I guess I could just pull in
> > common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> > that, you could fork a new branch from 60c1b220d8bc and I could just pull
> > that part instead.
>
> It may not be worth it, the conflict is not that bad. Unless you
> forsee more conflicts arising.
Hopefully not, but it looks like it should be dead easy to resolve in this
case since the riscv tree doesn't contain anything else and the arm64 stuff
is already on its own branch.
I'll leave it up to Paul/Palmer to see what they prefer.
Will
Hi Will,
On Tue, 13 Aug 2019 09:24:23 +0100 Will Deacon <[email protected]> wrote:
>
> Paul, Palmer -- If it's not too late, then it would probably be best to
> stick this commit (60c1b220d8bc) and any dependencies on their own stable
> branch so that we can both pull it into our respective trees and I can
> resolve this conflict in the arm64 tree, which I'll send early during the
> merge window.
>
> Looking at your tree, I guess I could just pull in
> common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> that, you could fork a new branch from 60c1b220d8bc and I could just pull
> that part instead.
It may not be worth it, the conflict is not that bad. Unless you
forsee more conflicts arising.
--
Cheers,
Stephen Rothwell
Hi folks,
On Tue, 13 Aug 2019, Will Deacon wrote:
> On Tue, Aug 13, 2019 at 09:34:47AM +1000, Stephen Rothwell wrote:
> > Today's linux-next merge of the risc-v tree got a conflict in:
> >
> > arch/arm64/kernel/topology.c
> >
> > between commit:
> >
> > 98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")
> >
> > from the arm64 tree and commit:
> >
> > 60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")
> >
> > from the risc-v 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.
>
> Thanks, Stephen.
>
> Paul, Palmer -- If it's not too late, then it would probably be best to
> stick this commit (60c1b220d8bc) and any dependencies on their own stable
> branch so that we can both pull it into our respective trees and I can
> resolve this conflict in the arm64 tree, which I'll send early during the
> merge window.
>
> Looking at your tree, I guess I could just pull in
> common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> that, you could fork a new branch from 60c1b220d8bc and I could just pull
> that part instead.
How about if we treat common/for-v5.4-rc1/cpu-topology as a stable branch?
I wasn't planning to rebase it. Then both of us can just merge it into
our for-next branches for the merge window? (It looks like I will need to
rebuild the riscv for-next branch on top of v5.3-rc5, for unrelated
reasons.)
Sound reasonable?
- Paul
On Tue, Aug 13, 2019 at 10:24:30PM +0000, Paul Walmsley wrote:
> On Tue, 13 Aug 2019, Will Deacon wrote:
> > On Tue, Aug 13, 2019 at 09:34:47AM +1000, Stephen Rothwell wrote:
> > > Today's linux-next merge of the risc-v tree got a conflict in:
> > >
> > > arch/arm64/kernel/topology.c
> > >
> > > between commit:
> > >
> > > 98dc19902a0b ("arm64: topology: Use PPTT to determine if PE is a thread")
> > >
> > > from the arm64 tree and commit:
> > >
> > > 60c1b220d8bc ("cpu-topology: Move cpu topology code to common code.")
> > >
> > > from the risc-v 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.
> >
> > Thanks, Stephen.
> >
> > Paul, Palmer -- If it's not too late, then it would probably be best to
> > stick this commit (60c1b220d8bc) and any dependencies on their own stable
> > branch so that we can both pull it into our respective trees and I can
> > resolve this conflict in the arm64 tree, which I'll send early during the
> > merge window.
> >
> > Looking at your tree, I guess I could just pull in
> > common/for-v5.4-rc1/cpu-topology if you promise never to rebase it. Failing
> > that, you could fork a new branch from 60c1b220d8bc and I could just pull
> > that part instead.
>
> How about if we treat common/for-v5.4-rc1/cpu-topology as a stable branch?
> I wasn't planning to rebase it. Then both of us can just merge it into
> our for-next branches for the merge window? (It looks like I will need to
> rebuild the riscv for-next branch on top of v5.3-rc5, for unrelated
> reasons.)
>
> Sound reasonable?
Cheers, Paul. Sounds good to me.
Will