Hyperion Entertainment Message Boards

Skateman wrote:Alpha6 running fine on my AmigaOne X5000. No issues yet!

Keep up the good work

acefnq wrote:4.20rc6 up and running fine.

ace

On 31 October 2018 at 1:46PM, Michael Ellerman wrote:
> Hi Rob,
>
> This change is breaking some powerpc machines, ...
>
> Rob Herring <[email protected]> writes:
>> Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
>> has the side effect of defaulting to iterating using "cpu" node names in
>> preference to the deprecated (for FDT) device_type == "cpu".
>>
>> Cc: Frank Rowand <[email protected]>
>> Cc: [email protected]
>> Signed-off-by: Rob Herring <[email protected]>
>> ---
>> Please ack and I will take via the DT tree. This is dependent on the
>> first 2 patches.
>>
>> drivers/of/base.c | 2 +-
>> drivers/of/of_numa.c | 15 ++-------------
>> 2 files changed, 3 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 6389aeb2f48c..8285c07cab44 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -389,7 +389,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>> {
>> struct device_node *cpun;
>>
>> - for_each_node_by_type(cpun, "cpu") {
>> + for_each_of_cpu_node(cpun) {
>> if (arch_find_n_match_cpu_physical_id(cpun, cpu, thread))
>> return cpun;
>> }
> Previously we just looked for any node with a type of "cpu", but now
> we're using for_each_of_cpu_node(), which does:
>
> for (; next; next = next->sibling) {
> if (!(of_node_name_eq(next, "cpu") ||
> (next->type && !of_node_cmp(next->type, "cpu"))))
> continue;
>
> if (!__of_device_is_available(next))
> continue;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> if (of_node_get(next))
> break;
> }
>
>
> ie. the available check is new.
>
> On this machine the 2nd CPU is not marked as available:
>
> root@p5020ds:/proc/device-tree/cpus/PowerPC,e5500@1# lsprop status
> status "disabled"
>
> This has the effect of preventing the SMP code from finding the 2nd CPU
> in order to bring it up (in smp_85xx_start_cpu()). And so only the boot
> CPU is onlined.
>
> The device tree is built from a dts:
>
> arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
>
> But we don't set the status in there, so presumably u-boot is changing
> the status during boot? (not a u-boot expert).
>
>
> We could work around this in the platform code presumably, but I'm
> worried this might break other things as well. You didn't mention the
> addition of the available check in the change log so I wonder if it was
> deliberate or just seemed like a good idea?
>
> cheers

Skateman wrote:Alpha7 up and running on the X5000!

acefnq wrote:4.20-rc7 up and running well. Thank you.

In most cases, nodes with 'status = "disabled";' are treated as if the
node is not present though it is a common bug to forget to check that. However, cpu nodes are different in that "disabled" simply means offline and the OS can bring the CPU core online. Commit f1f207e43b8a ("of: Add cpu node iterator for_each_of_cpu_node()") followed the common behavior of ignoring disabled cpu nodes. This breaks some powerpc systems (at least NXP P50XX/e5500). Fix this by dropping the status check.

Fixes: 651d44f9679c ("of: use for_each_of_cpu_node iterator")
Fixes: f1f207e43b8a ("of: Add cpu node iterator for_each_of_cpu_node()")
Reported-by: Michael Ellerman <[email protected]>
Cc: Christian Zigotzky <[email protected]>
Cc: Frank Rowand <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
---
drivers/of/base.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index cc62da278663..e47c5ce6cd58 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -776,8 +776,6 @@ struct device_node *of_get_next_cpu_node(struct device_node *prev)
       if (!(of_node_name_eq(next, "cpu") ||
             (next->type && !of_node_cmp(next->type, "cpu"))))
           continue;
-        if (!__of_device_is_available(next))
-            continue;
       if (of_node_get(next))
           break;
   }
-- 
2.19.1

• X5000/QEMU e5500: of_v3 patch for solving the SMP problems (Thanks to Rob Herring)
• Phoronix articles, reviews and news stories covering Linux 4.20
• Linux Git log

acefnq wrote:4.20_RC8 up and running fine. many thanks for your ongoing work as usual. Anyone notice Midori just got updated to v6. I think it would need compiled, not sure it would even work on 16.04?. I wouldn't have a clue what needs done but it may be worth someone looking at.

ace

Skateman wrote:Alpha8 is ready for action! Running fine on the AmigaOne X5000