From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacek Anaszewski Subject: Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform Date: Mon, 27 Apr 2015 09:24:10 +0200 Message-ID: <553DE41A.5070703@samsung.com> References: <20150422234509.626d9dc7@ja.home> <55388254.4000606@linux.vnet.ibm.com> <20150423161342.55e9ac8f@ja.home> <1430086038.16571.78.camel@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailout4.w1.samsung.com ([210.118.77.14]:25573 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932118AbbD0HYO (ORCPT ); Mon, 27 Apr 2015 03:24:14 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NNG002TCF8CA000@mailout4.w1.samsung.com> for linux-leds@vger.kernel.org; Mon, 27 Apr 2015 08:24:12 +0100 (BST) In-reply-to: <1430086038.16571.78.camel@kernel.crashing.org> Sender: linux-leds-owner@vger.kernel.org List-Id: linux-leds@vger.kernel.org To: Benjamin Herrenschmidt Cc: stewart@linux.vnet.ibm.com, cooloney@gmail.com, Vasant Hegde , rpurdie@rpsys.net, linuxppc-dev@lists.ozlabs.org, linux-leds@vger.kernel.org, khandual@linux.vnet.ibm.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