Hi Benjamin,
Thanks for your explanation.
On 04/27/2015 12:07 AM, Benjamin Herrenschmidt wrote:
On Thu, 2015-04-23 at 16:13 +0200, Jacek Anaszewski wrote:
How the firmware is related to kernel? These bindings are for kernel,
not for the firmware.
There should be no relation. DT bindings should be kernel agnostic and
represent the HW layout, not be designed based on what a given kernel
driver wants, but I'm digressing...
DT bindings are compiled to *.dtb file which is concatenated with
zImage.
No. First, a "binding" isn't compiled to a dtb, a binding is a piece
documentation. A flat device tree *might* be compiled from a dts to a
dtb but that isn't necessarily the case.
For example, any machine with an actual implementation of Open Firmware
will essentially flatten OF internal tree into a dtb at boot time, and
that tree is itself generated by forth code.
In our case, the device tree is procedurally generated by two layers of
firmware, there is no dts "compilation" happening. HostBoot generates a
shell and OPAL extends it before flattening it and passing it to the
kernel.
The "concatenated with zImage" point you make is also a very ARM centric
one. ARM provides the *optional* ability to concatenate a dtb with a
zImage, but that's specific to ARM zImage wrapper. For example, powerpc
can do something similar (but not identical) using the "wrapper" script
we have in arch/powerpc/boot where we embed the dtb. However, this too
is optional, we have a longer history of having firwmares generating
device-trees.
Note: We invented the whole FDT business :-)
During system boot device drivers are matched with DT bindings
through 'compatible' property. A driver should have single matching DT
node, i.e. no other driver can probe with the same DT node.
This implies that the node should contain only the properties required
for configuring the related device.
I don't see how you goes from A to implying B here. Yes, a device
generally will have a single representing node but that doesn't mean
that the node only contains what the driver needs. The DT node can
contain all sort of auxilliary informations that the driver may or may
not be interested in that was deemed potentially relevant or useful by
the platform designer.
I was not aware that some other entity than the driver could be
interested in the information provided by DT node. I will no longer
object, provided that we will get an ack from DT maintainer.
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-leds" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
