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

[Yoder Stuart-B08248]

> -----Original Message-----
> From: David Gibson [mailto:david at gibson.dropbear.id.au] 
> Sent: Wednesday, May 02, 2007 7:17 PM
> To: Yoder Stuart-B08248
> Cc: Segher Boessenkool; linuxppc-dev at ozlabs.org; 
> 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)
> 
> On Wed, May 02, 2007 at 12:04:11PM -0700, Yoder Stuart-B08248 wrote:
> >  
> > 
> > > -----Original Message-----
> > > From: David Gibson [mailto:david at gibson.dropbear.id.au] 
> > > Sent: Tuesday, May 01, 2007 8:20 PM
> > > To: Segher Boessenkool
> > > Cc: Yoder Stuart-B08248; linuxppc-dev at ozlabs.org; 
> > > 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)
> > > 
> > > On Wed, May 02, 2007 at 02:34:45AM +0200, Segher 
> Boessenkool wrote:
> > > > >> "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.
> > > 
> > > I tend to agree. Device drivers should generally be 
> searching on the
> > > "compatible" property, not "device_type".  Defining new 
> device_type
> > > values isn't really of any use to the kernel, so we 
> should just avoid
> > > it.
> > 
> > Right-- drivers search on "compatible".
> > 
> > But, don't we want to keep standardized sets of properties for
> > certain classes/types of devices?  Defining a standardized,
> > required set of properties for a "network", "rom", or "i2c"
> > class of device is helpful.  Without a standardized 'template'
> > of properties, developers may make up whatever properties they
> > want and things will work fine as long as the device tree and
> > driver are in sync.  It works, but you wind up with a plethora
> > of properties each describing the same thing.
> 
> If there's an obvious new class, with common properties, then yes,
> sure.  But I don't think we need to feel impelled to think up new
> classes (and therefore a device_type value) for each new device.  
> 
> And even in the case of new classes, I think we might be best off
> waiting for a few devices to appear so we can tell what's really
> common information before we define the class's device_type and
> required properties.

I think this makes sense.  I have seen various new device_type 
properties popping up that seem very generic.  They simply have
the standard list of "reg",  "compatible", "interrupts",
"interrupt-parent".

I think one thing that would be very helpful would be a 
crisp list of what the standardized device_types are so
when people create new device trees they have a guideline.
I'll take a stab at adding a section to booting-without-of.txt
for this.

Stuart