On 22/11/2023 09:57, Michal Simek wrote: > Hi Geert, > > On 11/22/23 09:53, Geert Uytterhoeven wrote: >> Hi Michal, >> >> On Wed, Nov 22, 2023 at 9:50 AM Michal Simek <michal.simek@xxxxxxx> wrote: >>> On 11/22/23 09:29, Dragan Simic wrote: >>>> On 2023-11-22 09:21, Krzysztof Kozlowski wrote: >>>>> On 22/11/2023 09:09, Chen-Yu Tsai wrote: >>>>>> On Wed, Nov 22, 2023 at 4:05 PM Krzysztof Kozlowski >>>>>> <krzysztof.kozlowski@xxxxxxxxxx> wrote: >>>>>>> >>>>>>> On 21/11/2023 14:50, Rafał Miłecki wrote: >>>>>>>>> +Order of Properties in Device Node >>>>>>>>> +---------------------------------- >>>>>>>>> + >>>>>>>>> +Following order of properties in device nodes is preferred: >>>>>>>>> + >>>>>>>>> +1. compatible >>>>>>>>> +2. reg >>>>>>>>> +3. ranges >>>>>>>>> +4. Standard/common properties (defined by common bindings, e.g. without >>>>>>>>> + vendor-prefixes) >>>>>>>>> +5. Vendor-specific properties >>>>>>>>> +6. status (if applicable) >>>>>>>>> +7. Child nodes, where each node is preceded with a blank line >>>>>>>>> + >>>>>>>>> +The "status" property is by default "okay", thus it can be omitted. >>>>>>>> >>>>>>>> I think it would really help to include position of #address-cells and >>>>>>>> #size-cells here. In some files I saw them above "compatible" that seems >>>>>>>> unintuitive. Some prefer putting them at end which I think makes sense >>>>>>>> as they affect children nodes. >>>>>>>> >>>>>>>> Whatever you choose it'd be just nice to have things consistent. >>>>>>> >>>>>>> This is a standard/common property, thus it goes to (4) above. >>>>>> >>>>>> It's probably a mix, but AFAIK a lot of the device trees in tree have >>>>>> #*-cells after "status". In some cases they are added in the board >>>>>> .dts files, not the chip/module .dtsi files. >>>>> >>>>> Existing DTS is not a good example :) >>>>> >>>>>> >>>>>> +1 that it makes sense at the end as they affect child nodes. >>>>> >>>>> I still insist that status must be the last, because: >>>>> 1. Many SoC nodes have address/size cells but do not have any children >>>>> (I2C, SPI), so we put useless information at the end. >>>>> 2. Status should be the final information to say whether the node is >>>>> ready or is not. I read the node, check properties and then look at the end: >>>>> a. Lack of status means it is ready. >>>>> b. status=disabled means device still needs board resources/customization >>>> >>>> I agree with the "status" belonging to the very end, because it's both logical >>>> and much more readable. Also, "status" is expected to be modified in the >>>> dependent DT files, which makes it kind of volatile and even more deserving to >>>> be placed last. >>> >>> I am just curious if having status property at the end won't affect >>> execution/boot up time. Not sure how it is done in Linux but in U-Boot at least >>> (we want to have DTs in sync between Linux and U-Boot) of_find_property is >>> pretty much big loop over all properties. And status property defined at the end >>> means going over all of them to find it out to if device is present. >>> Not sure if Linux works in the same way but at least of_get_property is done in >>> the same way. >> >> As the default is "okay", you have to loop over all properties anyway. > > No doubt if you don't define status property that you need to loop over all of > them. We normally describe the whole SOC with pretty much all IPs status = > disabled and then in board file we are changing it to okay based on what it is > actually wired out. > It means on our systems all nodes have status properties. If you have it at > first you don't need to go over all. We never sacrificed code readability in favor of code execution speed, so neither should we do it here. If the speed is a problem, project can still add a flag to dtc to re-shuffle properties in FDT depending on its needs. Best regards, Krzysztof
