> Matt, the various properties you list do not mean what you think they > mean. > > name - should be named according to the generic names convention. > It's pretty much arbitrary, meant for human readability of the device > tree. Drivers should not depend on it (some do, historically, but new > drivers and trees should not).
It is not arbitrary, there is a single well-defined name for every common "class" of device. It _is_ machine-readable (but shouldn't be used for driver matching, indeed -- it says nothing about the programming model). > device_type - indicates the open firmware method interface for the > device. Not "method interface", just "interface". > Therefore, meaningless in flattened trees. Even in flat trees, a "device_type" of for example "block" indicates the node will have the required properties for that device type, for example "block-size". Such properties are perfectly useful. OTOH, it isn't very useful to search for device with a specific device type from within the kernel, since it currently has no firmware interaction to speak of (flat trees don't interact, and the kernel kills "real" OF dead as soon as possible). > No new driver should use this. Not without very good rationalisation, anyway. > compatible - *this* is the one for driver selection. It describes the > hardware level interface(s) of the device. > > model - usually just for debugging / diagnosis / human-readable > purposes, describes exact model / revision of the hardware. It can be > used to enable driver quirks / workarounds for when various devices > are supposed to be compatible (as encoded in 'compatible') but > aren't, due to hardware bugs. However, you should never aim to use it > this way in design. Yeah. Any non-workaround value a driver would derive from "model" is usually better described using a separate property. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
