cpu node requirements don't match schema

[galak]

cpu node requirements don't match schema

[galak]

Also, is device_type="cpu" required, there are various .dts files in the linux kernel that don't seem to specify it?

[ulfalizer]

Would be nice to get clarification on this part of the spec. too:

The device_type property was used in IEEE 1275 to describe the
device’s FCode programming model. Because DTSpec does not
have FCode, new use of the property is deprecated, and it should
be included only on cpu and memory nodes for compatibility with
IEEE 1275–derived devicetrees.

The way I'm reading it, device_type is allowed on memory and cpu nodes as a concession to IEEE 1275-derived devicetrees, as it might be a pain to get rid of device_type in e.g. Linux, but isn't required on those nodes.

Is that the way it was meant? The wording is a bit ambiguous at the moment.

This is from some arguments in https://github.com/zephyrproject-rtos/, which isn't Linux-based. I want to just have compatible = "foo" on CPU and memory nodes, as device_type doesn't add anything for us.

[robherring]

The specification was never updated from what ePAPR said to contain what Arm implemented for cpu nodes. This needs to be done.

The schema matches the common parts between Arm and Risc-V minimally. Probably some of the other FDT arches, but not PowerPC.

[galak]

The specification was never updated from what ePAPR said to contain what Arm implemented for cpu nodes. This needs to be done.

The schema matches the common parts between Arm and Risc-V minimally. Probably some of the other FDT arches, but not PowerPC.

And to be pedantic, the schema says that device_type, reg and compatible are required.

[robherring]

The specification was never updated from what ePAPR said to contain what Arm implemented for cpu nodes. This needs to be done.
The schema matches the common parts between Arm and Risc-V minimally. Probably some of the other FDT arches, but not PowerPC.

And to be pedantic, the schema says that device_type, reg and compatible are required.

You mean the Arm cpu schema (kernel:Documentation/devicetree/bindings/arm/cpus.yaml)?

That's correct. While we'd like to drop device_type, we can't. The kernel until recently still used device_type to find/iterate on cpu nodes. That changed recently to use /cpus and cpu node names instead (except for Power which uses the CPU model still for node names). We could also do the same for memory nodes, but haven't. So as long as there's a client program depending on device_type and until whatever backwards compatibility window expires (5 years, 10 years, never?), device_type will remain required. Though I guess that could be relaxed on new platforms.

[ulfalizer]

You mean the Arm cpu schema (kernel:Documentation/devicetree/bindings/arm/cpus.yaml)?

That's correct. While we'd like to drop device_type, we can't. The kernel until recently still used device_type to find/iterate on cpu nodes. That changed recently to use /cpus and cpu node names instead (except for Power which uses the CPU model still for node names). We could also do the same for memory nodes, but haven't. So as long as there's a client program depending on device_type and until whatever backwards compatibility window expires (5 years, 10 years, never?), device_type will remain required. Though I guess that could be relaxed on new platforms.

Is this only for ARM, from a spec. standpoint?

I.e., does the spec. itself require that device_type appears on all cpu nodes, regardless of platform?

More pragmatically, I'd like to drop it in our case regardless, because we don't use/need it (compatible is enough). Would help settle the spec. part at least though.

[robherring]

Is this only for ARM, from a spec. standpoint?

No. If anything the spec reflects PowerPC (and not necessarily IBM PowerPC). There was some work removing/moving PPC specific parts from ePAPR, but it's obviously not complete.

I.e., does the spec. itself require that device_type appears on all cpu nodes, regardless of platform?

Probably the spec can be optional, but then it is up to the arch. Whether the arch is optional and it's up to individual platforms is the question.

More pragmatically, I'd like to drop it in our case regardless, because we don't use/need it (compatible is enough). Would help settle the spec. part at least though.

As long as we have something required by one client and optional on others, it pretty much has to be required. I'm hesitant to say making that per platform is okay.

[ulfalizer]

Thanks for the clarifications!

I.e., does the spec. itself require that device_type appears on all cpu nodes, regardless of platform?

Probably the spec can be optional, but then it is up to the arch. Whether the arch is optional and it's up to individual platforms is the question.

More pragmatically, I'd like to drop it in our case regardless, because we don't use/need it (compatible is enough). Would help settle the spec. part at least though.

As long as we have something required by one client and optional on others, it pretty much has to be required. I'm hesitant to say making that per platform is okay.

My fault. I meant "platform" in a broader sense, like completely different architectures. I agree that it'd be a mess if different .dts files within the same arch could have different requirements for example.

Leaving it up to a per-arch decision makes sense to me.

[robherring]

Closing. Send spec changes if you want something changed.