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

[Jacek Anaszewski <j.anaszewski@samsung.com>]

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