Hi Nicolas, > What Jeremy did is to add a probe_dt method in the mdesc structure, and > then the core is calling them in sequence until one of them returns > success. > > now, the "compatible" property is explained here: > > http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property > > From my understanding, this could allow for a kernel that doesn't yet > support the specifics of a particular board to still be able to work > using basic common support. But for this to work, wouldn't it be > necessary for the core code to try to find the best match itself rather > than letting each machine's probe_dt decide on their own?
At present, the probe_dt function is a binary match/no-match indicator, so the core code just selects the first match it finds. This means that we'll need one mdesc per machine; I'm intending to keep it simple to start with. My intention in the longer-term is to allow probe_dt to indicate less-specific matches (eg, match on the SoC family), and change the core code to not break out of the loop on the first match, but continue to look for a better match. This way, we can have one mdesc to support a SoC family, but still allow that to be overridden if there's a more specific (eg, single machine) mdesc compiled in. The reason I do this in the machine-specific code (rather than the core code checking the compatible property) is to allow the probe_dt function to check arbitrary data in the device tree. Perhaps we have two variations of a machine - both with the same compatible property, but distinguishable in some other way, and we need a separate mdesc for whatever reason. Cheers, Jeremy _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
