From: Jacek Anaszewski <j.anaszewski@samsung•com>
To: Benjamin Herrenschmidt <benh@kernel•crashing.org>
Cc: stewart@linux•vnet.ibm.com, cooloney@gmail•com,
Vasant Hegde <hegdevasant@linux•vnet.ibm.com>,
rpurdie@rpsys•net, linuxppc-dev@lists•ozlabs.org,
linux-leds@vger•kernel.org, khandual@linux•vnet.ibm.com
Subject: Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
Date: Mon, 27 Apr 2015 09:24:10 +0200 [thread overview]
Message-ID: <553DE41A.5070703@samsung.com> (raw)
In-Reply-To: <1430086038.16571.78.camel@kernel.crashing.org>
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
next prev parent reply other threads:[~2015-04-27 7:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 21:45 [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform Jacek Anaszewski
2015-04-23 5:25 ` Vasant Hegde
2015-04-23 14:13 ` Jacek Anaszewski
2015-04-24 4:18 ` Stewart Smith
2015-04-24 10:16 ` Jacek Anaszewski
2015-04-28 6:59 ` Stewart Smith
2015-04-28 9:10 ` Jacek Anaszewski
2015-04-24 5:30 ` Vasant Hegde
2015-04-24 10:15 ` Jacek Anaszewski
2015-04-26 22:08 ` Benjamin Herrenschmidt
2015-04-27 11:15 ` Jacek Anaszewski
2015-04-26 22:07 ` Benjamin Herrenschmidt
2015-04-27 7:24 ` Jacek Anaszewski [this message]
2015-04-27 9:53 ` Benjamin Herrenschmidt
2015-04-27 11:15 ` Jacek Anaszewski
2015-04-27 13:47 ` Vasant Hegde
2015-04-28 11:06 ` Vasant Hegde
-- strict thread matches above, loose matches on Subject: below --
2015-03-20 11:02 [PATCH v2 0/2] LED interface " Vasant Hegde
2015-03-20 11:04 ` [PATCH v2 2/2] leds/powernv: Add driver " Vasant Hegde
2015-03-25 5:21 ` Benjamin Herrenschmidt
2015-04-14 5:40 ` Vasant Hegde
2015-04-14 15:20 ` Jacek Anaszewski
2015-04-15 6:26 ` Vasant Hegde
[not found] ` <552E2480.9060102@samsung.com>
2015-04-15 10:15 ` Vasant Hegde
[not found] ` <552E63D2.4070209@samsung.com>
2015-04-16 6:52 ` Vasant Hegde
2015-04-16 8:51 ` Jacek Anaszewski
2015-04-16 10:26 ` Vasant Hegde
2015-04-16 11:34 ` Jacek Anaszewski
2015-04-20 7:29 ` Jacek Anaszewski
2015-04-20 11:45 ` Jacek Anaszewski
2015-04-20 12:34 ` Vasant Hegde
2015-04-20 15:20 ` Jacek Anaszewski
2015-04-20 15:53 ` Vasant Hegde
2015-04-15 18:50 ` Stewart Smith
2015-04-16 5:07 ` Vasant Hegde
2015-04-21 23:03 ` Stewart Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=553DE41A.5070703@samsung.com \
--to=j.anaszewski@samsung$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=cooloney@gmail$(echo .)com \
--cc=hegdevasant@linux$(echo .)vnet.ibm.com \
--cc=khandual@linux$(echo .)vnet.ibm.com \
--cc=linux-leds@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=rpurdie@rpsys$(echo .)net \
--cc=stewart@linux$(echo .)vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox