RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Segher Boessenkool [mailto:segher at kernel.crashing.org] 
> Sent: Tuesday, May 01, 2007 7:35 PM
> To: Yoder Stuart-B08248
> Cc: Dave Jiang; linuxppc-dev at ozlabs.org; 
> david at gibson.dropbear.id.au; bluesmoke-devel at lists.sourceforge.net
> Subject: Re: RFC: new device types in the device tree (RE: 
> [PATCH] powerpc: Add EDAC platform devices for 85xx)
> 
> >> "name" = "memory-controller"
> >> "compatible" = "fsl,85xx-memory-controller"
> >> (or a more specific 85xx model if the controller
> >> isn't identical across those chips)
> >> No "device_type" at all, since there is no binding
> >> for this kind of device.
> >
> > Is "no device_type" really the approach that should be
> > taken?
> 
> Yes.
> 
> > booting-without-of.txt currently reads:
> >
> >    Every node which actually represents an actual device
> >    (that is, a node which isn't only a virtual "container"
> >    for more nodes, like "/cpus" is) is also required to
> >    have a "device_type" property indicating the type of
> >    node
> 
> That is wrong, IMNSHO.
> 
> > The 1275 spec is 'Open Firmware centric' in that it says
> > you don't need a device_type if the node is not used
> > by Open Firmware.
> 
> It is "Open firmware centric" in every way; it is
> the Open firmware definition after all.
> 
> "device_type" specifies what firmware interfaces a
> node implements.  "name" and "compatible" are for
> the client (i.e., OS, bootloader, etc.) to use for
> matching drivers to device nodes.

The flat device tree standard (i.e. booting-without-of.txt)
certainly inherited stuff from IEEE-1275, but can diverge
if need be.

The document currently defines the device_type property
to specify the class of device.  And it's required for
nodes describing a device.

name is always optional (as defined by b-w-of.txt)

There are no interfaces or methods with the device trees
defined in DTS files.  Given that, does the the device_type
property have any value at all?

There are a slew of device_types defined in the DTS files
and in booting-without-of.txt.  Should all these be
removed?


> It typically makes no sense to create a new "device_type"
> value for anything else than very generic classes of
> device, where you can drive the device without knowing
> anything else than what is defined in the binding for
> that "device_type".

What types devices get a device_type and which don't?  Linux
drives the devices based on "compatible".

> > What should the approach be for new device types that
> > keep popping up?   If the device type is generally useful
> > I think it makes sense to create a binding and add it to
> > booting-without-of.txt-- essentially documenting the
> > required properties, their values, and what they mean.
> 
> And the associated methods and anything else that is
> needed.  It would be a big mistake to create incompatibilities
> with "real OF" where those can be avoided just as easily.

But there are no methods.

Even if the kernel does not use 'device_type', the property
still seems to have some value in that it specifies a
required set of properties and their values for various
classes of devices.

Take a flash device for instance--

        flash at ff000000 {
                device_type = "rom";
                compatible = "direct-mapped";
                probe-type = "CFI";
                reg = <ff000000 01000000>;
                bank-width = <4>;
                partitions = <00000000 00f80000
                              00f80000 00080001>;
                partition-names = "fs\0firmware";
        };

I suppose we can delete the device_type property and the
kernel will still be happy, but it's nice to have a standard
set of properties that everyone uses when describing a given
class of device.  The device_type is just a convenient
identifer to refer to this device class and set of properties.

Stuart