From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752923AbbCKVsm (ORCPT ); Wed, 11 Mar 2015 17:48:42 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:58538 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751572AbbCKVsk (ORCPT ); Wed, 11 Mar 2015 17:48:40 -0400 From: Arnd Bergmann To: Kumar Gala Cc: Bjorn Andersson , Olof Johansson , Kevin Hilman , linux-arm-msm , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "arm@kernel.org" , "devicetree@vger.kernel.org" , Heiko =?ISO-8859-1?Q?St=FCbner?= Subject: Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id Date: Wed, 11 Mar 2015 22:48:13 +0100 Message-ID: <7229476.C4So9noUlf@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <79FFFE06-191C-404D-8923-48C9C28C61F7@codeaurora.org> References: <1425503602-24916-1-git-send-email-galak@codeaurora.org> <2155628.BceQuZbXC8@wuerfel> <79FFFE06-191C-404D-8923-48C9C28C61F7@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:iGB/+3UWypvZq3PsmYwBcjUywT0yrqvkIQwIZP8s3JLWuaOP114 m0CEeRBbEeaJTxQiXQ4yK+Wz8b/wE7wcUN3YvGDurTFLIq7/AfRvZXXRLDF6enZfwTl/SKq fPMJIkp5eQEQwfzQ9OJ5RXnz8Efk0/MUWnqZcmXJAOJO6a6o0bPQlEj+fmutsGnQUqt5eyR /gRmQZmMS7VGfge01Imdw== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 11 March 2015 15:35:22 Kumar Gala wrote: > On Mar 11, 2015, at 3:20 PM, Arnd Bergmann wrote: > > > On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote: > >> > >> 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. > >> > > > > I guess if I understand this right, we just need to fix that dtbTool > > then to look at the top-level compatible property and/or machine > > name instead? > > > > Arnd > > Correct, and it means updating the tool for every board/dts that gets created in the future. > > Thus, the feeling was that having the ids kept with the dtb made maintenance far easier. > Part of my objection was to having nonstandard properties that are not even used anywhere in the kernel. If you could just encode them in the root compatible property as a string, that would be a lot nicer. Arnd