linux-kernel - Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Mar 2015 10:57:56 -0500
From:	Kumar Gala <galak@...eaurora.org>
To:	Bjorn Andersson <bjorn@...o.se>
Cc:	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Kevin Hilman <khilman@...nel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arm@...nel.org" <arm@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Heiko Stübner <heiko@...ech.de>
Subject: Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id


On Mar 11, 2015, at 10:33 AM, Bjorn Andersson <bjorn@...o.se> wrote:

> On Tue, Mar 10, 2015 at 12:57 PM, Kumar Gala <galak@...eaurora.org> wrote:
>> 
>> On Mar 10, 2015, at 2:52 PM, Arnd Bergmann <arnd@...db.de> wrote:
>> 
>>> On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
>>>>>>>>>>>>> The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
>>>>>>>>>>>>>> on Qualcomm MSM platforms to determine which device tree should be
>>>>>>>>>>>>>> utilized and passed to the kernel.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Cc: <devicetree@...r.kernel.org>
>>>>>>>>>>>>>> Signed-off-by: Kumar Gala <galak@...eaurora.org>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Is this the special magic that allows qcom bootloaders to take a kernel
>>>>>>>>>>>>> plus multiple DTBs and figure out which DTB to pass?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Kevin
>>>>>>>>>>>> 
>>>>>>>>>>>> yes
>>>>>>>>>>> 
>>>>>>>>>>> That's a bummer.
>>>>>>>>>>> 
>>>>>>>>>>> Luckily, the solution for upstream is still quite simple: Provide only
>>>>>>>>>>> one devicetree, and it'll be used, right?
>>>>>>>>>> 
>>>>>>>>>> We can provide only one, we still need the IDs in the DT.
>>>>>>>>> 
>>>>>>>>> How are the DTS provided? Concatenated with the kernel, or in a
>>>>>>>>> wrapped data format? Or in a separate partition from the kernel?
>>>>>>>> 
>>>>>>>> Its a wrapped data format that is than concatenated with the kernel if I remember correctly.
>>>>>>> 
>>>>>>> Then you should be able to create a tool that can write this concatenated
>>>>>>> format and insert these properties from a table that matches the boot
>>>>>>> loader, right?
>>>>>>> 
>>>>>>>    Arnd
>>>>>> 
>>>>>> Are you suggesting the tool insert the properties in the DT?  I’m not sure I understand what the point of doing that would be.
>>>>> 
>>>>> To insert platform-local properties that mean nothing outside of the
>>>>> firmware packaging of the device trees, which is the case here?
>>>>> 
>>>>> I think the idea of having the installer script inserting them is
>>>>> quite reasonable in this case.
>>>>> 
>>>>> 
>>>>> -Olof
>>>> 
>>>> These values are static, so not sure what the point of having the installer script do that?
>>>> 
>>> 
>>> It combines two hacks to work around a nonstandard boot loader.
>>> Once the bootloader is fixed, you can stop using that script.
>>> 
>>>      Arnd
>> 
>> I feel as if I’m missing something here.  If we just have the properties in the .dts files I don’t need to change anything ever, no script, no worries about working with old or new boot loaders, etc.
>> 
> 
> But are these values actually used by the boot loader?
> 
> As far as I could see in 8974 the dtbTool provided by Qualcomm
> extracts the values from the list of dtbs and use them to create the
> table-of-content in the QCDT blob. The boot loader then looks in this
> TOC to pick the right dtb to use.

Are you asking do we utilize the values out of the DT directly?  If so, no.  You are correct that the tool pulls them out.  This is all about where we keep the information that associates a given DTB with its MSM-ID/BOARD-ID values.  While we can move that info into a tool, it just means updating the tool constantly to map an compatible string to those values.  The other means is keeping the values with the DTB as properties as this binding suggests.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/