quoted

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