On Mon, Aug 06, 2018 at 09:42:59PM -0600, Rob Herring wrote: > 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[@.*]". Hmm. I mean, I think that'll work in practice. In principle, I'm not sure there's any particular reason system RAM (or something that can work as system RAM) couldn't appear behind a bus bridge. That would break that approach. In a sense the obvious solution would be to suggest a compatible = "system-ram" or something for memory nodes. I think we might need to grandfather in the existing cases though. > 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. Yeah, I don't love using device_type there, but there wasn't really a better option. "pci@" in the name is sometimes used for pci devices as well as pci bridges, and the only other option is a huge laundry list of compatibles for every host bridge model we can think of. We could consider adding a "pci-host-bridge" compatible value that we encourage people to put after the more specific values. Again, we'd probably need some grandfathering, though. > Perhaps just looking for #address-cells==3 as that is pretty > much only PCI buses. I really dislike that idea, since it stops us using a 3-word encoding for something else if we need it in future. > 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. I agree, we definitely shouldn't be creating new device_tree values. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
