Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.

Cheers,
Ben.