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

[Segher Boessenkool]

>>> 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.

It shares the kernel interface.  You cannot go diverge
on fundamental things.

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

Where does it say that?  "name" is always required!  In
the newer flat tree format, it's even impossible to
create a node without "name".

> 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?

Not much, but still a bit, like you can find all
"serial" devices if you want to.  And of course,
many bindings require a specific "device_type",
so you should have one.

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

Most should yes.

>> 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".

No, Linux selects which driver to use based on "compatible".
That's a crucial difference.

>> 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.

Again, you should not create incompatibilities where
not needed.  Since "device_type" is primarily useful
for (talking to / using) the firmware, and hardly
useful at all for the flat device tree, the flat tree
"standard" shouldn't define new "device_type"s without
making it a real OF binding.

> 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.

Sure.  "network", "block", "serial", etc.

> Take a flash device for instance--

Yes, "flash" could be made into a nice generic binding
(except that no one has succeeded so far, there are just
way too many different kinds of flash/rom/nvram, and
many ways to hook them up).

> 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.

Unfortunately, there is no standard "device_type" for
flash yet.


Segher