On Mon, Aug 6, 2018 at 6:49 PM David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Aug 06, 2018 at 12:31:57PM -0600, Rob Herring wrote: > > On Mon, Aug 6, 2018 at 11:50 AM Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > > > > > > > > > While the "device_type" property is still used and supported, it is > > > deprecated so it should be removed from examples in the documentation. > > > There is no value in encouraging developers to keep using that > > > property, so just quietly disappear it from examples, but leave its > > > explanation in the spec. > > > > > > Signed-off-by: Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> > > > > > > --- > > > > > > according to the spec, that property is still marginally acceptable > > > for memory and cpu nodes, but it really has no place being used for > > > any other types of nodes. > > > > It's not just acceptable, but it is still required. It is also > > required for PCI bridges. > > So, cpu nodes could probably be identified by location under /cpus, > but there's not really a good way of identifying memory nodes other > than device_type. PCI bridges shouldn't need it, since they should > already have "compatible" properties describing the particular bridge > model. For memory nodes, I think we can look for "/memory[@.*]". For PCI, device_type is how we match PCI bridges for checks in dtc now. We could switch that to node name too now that we've cleaned those up, but then we wouldn't catch any new ones with mis-named nodes. Perhaps just looking for #address-cells==3 as that is pretty much only PCI buses. But I'd rather first worry about all the cases that are not cpu, memory or pci nor actual OF systems. For example, it looks like Risc-V added their own 'pmu' for a device_type. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
