Can we get device tree node property value type

Question

I have a device tree source with the following

/dts-v1/;
{
    node {
        child {
            property1 = "string"; // string
            property2 = <1>; // u32
            property3 = <1 2>; //u32 array
        };
    };
};

I am looping through the child like

for_each_property_of_node(child, prop)
{
    //save the property data like
   
 of_property_read_u64(child,prop->name,...);
    of_property_read_u32(...)
}

Is there a way to check the type of values (u32 u64 string or array types) in the property before saving them

Answer 1

Is there a way to check the type of values (u32 u64 string or array types) in the property before saving them

No, there is no attribute in the DTB indicating the data type of the property. Only the property name, property value (as a one-dimensional byte array), and byte length of the property value are retained in the device tree blob.

Refer to the description of FDT_PROP in Section 5.4.1. Lexical structure of the Devicetree Specification

---

I guess I am stuck statically checking the data type for each node property using the property name and implementing it in the code

Your remark does not make sense.
One more time: there is no "data type" to "check". A byte array (of sufficient length) can be treated as any data type you choose.
For instance, a call of of_property_read_u64() or of_property_read_u32() will (AFAICT) return some sort of property value whenever the property's byte array has adequate length.

The Device Tree and the node properties contained within are for the benefit of the device drivers in the kernel. Each kernel driver specifies the properties it will accept and use. A bindings document (in Documentation/devicetree/bindings/) is typically used to document those properties related to a driver.

The driver should define the purpose and data format of the properties that can be specified in the DT. If the writer of the DT mode does not conform to these requirements, then the DT is in error.

The operating principle in effect here is KIS[S], "keep it simple".
There's no burden on the driver to try and interpret what the data type the DT property might be. The DT is expected to provide suitable values for each property. When a of_property_read_xxx() returns an error (or the value is out of range), the driver can report that error and either (a) fail to install, or (b) assume some default value.