Re: [PATCH 2/3] usb: ehci-ppc-of dts bindings.

Segher Boessenkool <[email protected]>
Newsgroups gmane.linux.usb.devel,gmane.linux.ports.ppc64.devel
Message-ID <[email protected]>
>> 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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.