>> Nothing in a flat device tree should ever define a device_type, except >> perhaps for compatibility with legacy kernel code. > > This is not necessarily true. As Segher says, device_type originally > indicated the OF programming model for a device. However, we've > extended the notion for the flat device tree to allow device_type to > cover "device classes" which could have certain common properties and > semantics.
Such device classes are already handled by the "generic names" recommended practice. Reusing device_type for a different purpose is dangerous: before you know it, you'll end up with a conflict, as was nicely demonstrated today with device_type "rtc". > However, in this case, a meaningful class binding must > already be defined: it might make sense for usb to have a defined > device_type, but it's not been defined so far, so for now you must > omit device_type (if a device_type is defined in future, it's easier > to add legacy hooks that will include devices which are missing the > relevant device_type marker than to work around devices which *do* > have the marker, but pre-date and don't follow the defined class > binding). Nothing in the kernel should assume it can find all devices of a certain "class" any other way than by exhaustively matching on possible "compatible" values. I'm not sure why you would want to, anyway: you need "compatible" to select which driver to use, already. Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev