Change Details

If a CPU has a status property, and it is marked disabled, we should not create a CPU device for it. This is present in some RISC-V device trees which contain a "monitor core" with limited functionality (no MMU). We don't run the kernel on these, and in early CPU start-up code we skip them, and they have no impact on mp_ncpu. Why this is included in the device-tree at all is beyond me. It seems the new trend is to mark these as "disabled", so let's respect this in the ofw_cpu probe routine. This is generally harmless, but I noticed an impact when attempting to attach the cpufreq_dt driver. It counted more OFW CPU devices than logical CPUs (mp_ncpus), and therefore failed to attach for logical CPU 3 (RISC-V hart 4). With this change, all is well, and we don't get a bogus device. I've added a warning to make this case a little more obvious. It could be an assertion if preferred. No functional change when the property is not present at all.

If a CPU is marked disabled, we should not create a CPU device for it. This is present in some RISC-V device trees which contain a "monitor core" with limited functionality (no MMU). We don't run the kernel on these, and in early CPU start-up code we skip them, and they have no impact on mp_ncpu. Why this is included in the device-tree at all is beyond me. It seems the new trend is to mark these as "disabled", so let's respect this in the ofw_cpu probe routine. This is generally harmless, but I noticed an impact when attempting to attach the cpufreq_dt driver. It counted more OFW CPU devices than logical CPUs (mp_ncpus), and therefore failed to attach for logical CPU 3 (RISC-V hart 4). With this change, all is well, and we don't get a bogus device. No functional change when the property is not present at all.

If a CPU has a status property, and it is marked disabled, we should not create a CPU device for it. This is present in some RISC-V device trees which contain a "monitor core" with limited functionality (no MMU). We don't run the kernel on these, and in early CPU start-up code we skip them, and they have no impact on mp_ncpu. Why this is included in the device-tree at all is beyond me. It seems the new trend is to mark these as "disabled", so let's respect this in the ofw_cpu probe routine. This is generally harmless, but I noticed an impact when attempting to attach the cpufreq_dt driver. It counted more OFW CPU devices than logical CPUs (mp_ncpus), and therefore failed to attach for logical CPU 3 (RISC-V hart 4). With this change, all is well, and we don't get a bogus device. I've added a warning to make this case a little more obvious. It could be an assertion if preferred. No functional change when the property is not present at all.