From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 409ADC433E0 for ; Thu, 21 Jan 2021 22:30:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 03B1023A5E for ; Thu, 21 Jan 2021 22:30:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726101AbhAUWaW (ORCPT ); Thu, 21 Jan 2021 17:30:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725764AbhAUWaO (ORCPT ); Thu, 21 Jan 2021 17:30:14 -0500 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B07F9C06174A; Thu, 21 Jan 2021 14:29:33 -0800 (PST) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 78ECF50E; Thu, 21 Jan 2021 23:29:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1611268169; bh=bSpsB6iz35fpcRamCYl6FESXLSgAPyQnt/ONPb0XVR0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pzSbXgjIq0gMeq5GoIgz737IVoY3jMy839L7SJo+VjITuzzFWGvHFXyi989Nj5y8+ uPx4iYyo6wP/vjx3b8CJp83GEb47dqEFDHYxBy+lOAxmSMMGDapf9ALgnwsKMRLYm5 vpLAm2py/mSCZoCQYTh/D71qwqNxY+dFLyw2XDaE= Date: Fri, 22 Jan 2021 00:29:11 +0200 From: Laurent Pinchart To: Michal Simek Cc: linux-kernel@vger.kernel.org, monstr@monstr.eu, git@xilinx.com, Kalyani Akula , Krzysztof Kozlowski , Manish Narani , Rajan Vaja , Rob Herring , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 06/12] arm64: dts: zynqmp: Add label for zynqmp_ipi Message-ID: References: <272e23e0123f02c559bfa4ada9de73eb197aced8.1606917949.git.michal.simek@xilinx.com> <99008851-6c12-3acc-6530-25af08429ff5@xilinx.com> <4010c2d4-bee1-827b-1079-1f1bbf1f10d1@xilinx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4010c2d4-bee1-827b-1079-1f1bbf1f10d1@xilinx.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michal, I've just realized I forgot to reply to this e-mail, sorry. On Tue, Dec 08, 2020 at 08:26:41AM +0100, Michal Simek wrote: > On 07. 12. 20 23:16, Laurent Pinchart wrote: > > On Mon, Dec 07, 2020 at 10:39:25AM +0100, Michal Simek wrote: > >> On 06. 12. 20 23:46, Laurent Pinchart wrote: > >>> On Wed, Dec 02, 2020 at 03:06:05PM +0100, Michal Simek wrote: > >>>> Add label which is used by bootloader for adding bootloader specific flag. > >>>> > >>>> Signed-off-by: Michal Simek > >>>> --- > >>>> > >>>> U-Boot needs to add u-boot,dm-pre-reloc; property > >>> > >>> I'm not entirely sure what best practice rules are in this area, but > >>> shouldn't U-Boot locate the node by name instead of label ? > >> > >> Labels are not listed in dt binding and there are two approaches how to > >> reference nodes. Via full path with node name or via labels. > >> I do normally use labels which are much simple. > > > > Note that labels require the DTB to be compiled with the -@ option, > > otherwise they're not present in the binary. > > U-Boot is using different concept. You can see that there are a lot of > -u-boot.dtsi files in dts folders. These are automatically included to > DTS before DTC is called. It means you don't need to build overlay to > get merged. > > >> And also if you take a look how dtb looks like (convert back to dts) you > >> can see that for example aliases are using full path (just &label) but > >> clocks/gic which is the part of <> is handled via phandles as numbers. > >> > >> And labels names can vary and shouldn't be the part of binding doc as > >> far as I know. But I can be wrong of course. > > > > The DT bindings should document the interface with the operating system, > > and if applicable, the boot loader. If the boot loader requires a > > particular label, then it becomes part of the ABI, and I think it should > > be documented in the bindings. > > We have been discussing with Rob some month ago but didn't have a time > to do step further. Just keep it short Rob was ok to keep bootloader > binding inside Linux repo. I think that makes sense, DT bindings are meant to be OS-agnostic, so boot loader requirements should be documented there. > There is no hardcoding for a particular name. There is just a need to > have any label. U-Boot needs to have one property(e.g. > u-boot,dm-pre-reloc;) just to do early allocation. > The name is just reference and none is really looking for it. It is just > a way how to include it in much easier way. Just to make sure I understand this issue correctly, does this mean that you need to reference the node in a *-u-boot.dtsi file, and want a label to do so ? The label name needs to be the same in the base file (taken from the Linux source tree) and the *-u-boot.dtsi file (in the U-Boot source tree) in that case. Isn't it the role of DT bindings to document such requirements ? -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F7CAC433E0 for ; Thu, 21 Jan 2021 22:31:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3C4AD239EF for ; Thu, 21 Jan 2021 22:31:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C4AD239EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=kRqOTQ1JO3H0CS96lidZzXxvybeSjZ4QKa3gUh5gWI8=; b=1/Mf+hmeMhVZ/D7brNo1zvjls 2QwcocTRYhnpdOTAitMtab4uZ3BBoPbpiNLcjQR0Uu4PTDUmDSmdTsfnK89l2zDTbDdGEBP1NVvms vgLKpFFX/DYi536h0CYuqKIBiFfvIgNA0BsPV2xoBW86n1k9Ebdb56mBHhzKgNhNnOaSFircMh5hZ wf26433FQmR1xyvBFnRE1XZgYMZsjs6eGun1qAQ8uhom/+gcNIeghOcamYnRyJDs6/dCslu2mS7bs o/LxCCiAJnWBwII2twOMOiuDLvEqEOmcH/4KxObAhNl7WAwwupiMI6WcHkJKSqyGmr6WSFK8SgjHK LlGl6vGog==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2iSO-0007On-FN; Thu, 21 Jan 2021 22:29:36 +0000 Received: from perceval.ideasonboard.com ([213.167.242.64]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2iSL-0007OI-PZ for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 22:29:34 +0000 Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 78ECF50E; Thu, 21 Jan 2021 23:29:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1611268169; bh=bSpsB6iz35fpcRamCYl6FESXLSgAPyQnt/ONPb0XVR0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pzSbXgjIq0gMeq5GoIgz737IVoY3jMy839L7SJo+VjITuzzFWGvHFXyi989Nj5y8+ uPx4iYyo6wP/vjx3b8CJp83GEb47dqEFDHYxBy+lOAxmSMMGDapf9ALgnwsKMRLYm5 vpLAm2py/mSCZoCQYTh/D71qwqNxY+dFLyw2XDaE= Date: Fri, 22 Jan 2021 00:29:11 +0200 From: Laurent Pinchart To: Michal Simek Subject: Re: [PATCH 06/12] arm64: dts: zynqmp: Add label for zynqmp_ipi Message-ID: References: <272e23e0123f02c559bfa4ada9de73eb197aced8.1606917949.git.michal.simek@xilinx.com> <99008851-6c12-3acc-6530-25af08429ff5@xilinx.com> <4010c2d4-bee1-827b-1079-1f1bbf1f10d1@xilinx.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4010c2d4-bee1-827b-1079-1f1bbf1f10d1@xilinx.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_172934_094269_80D5A9B8 X-CRM114-Status: GOOD ( 29.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, monstr@monstr.eu, Rajan Vaja , linux-kernel@vger.kernel.org, Krzysztof Kozlowski , Rob Herring , Manish Narani , git@xilinx.com, Kalyani Akula , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Michal, I've just realized I forgot to reply to this e-mail, sorry. On Tue, Dec 08, 2020 at 08:26:41AM +0100, Michal Simek wrote: > On 07. 12. 20 23:16, Laurent Pinchart wrote: > > On Mon, Dec 07, 2020 at 10:39:25AM +0100, Michal Simek wrote: > >> On 06. 12. 20 23:46, Laurent Pinchart wrote: > >>> On Wed, Dec 02, 2020 at 03:06:05PM +0100, Michal Simek wrote: > >>>> Add label which is used by bootloader for adding bootloader specific flag. > >>>> > >>>> Signed-off-by: Michal Simek > >>>> --- > >>>> > >>>> U-Boot needs to add u-boot,dm-pre-reloc; property > >>> > >>> I'm not entirely sure what best practice rules are in this area, but > >>> shouldn't U-Boot locate the node by name instead of label ? > >> > >> Labels are not listed in dt binding and there are two approaches how to > >> reference nodes. Via full path with node name or via labels. > >> I do normally use labels which are much simple. > > > > Note that labels require the DTB to be compiled with the -@ option, > > otherwise they're not present in the binary. > > U-Boot is using different concept. You can see that there are a lot of > -u-boot.dtsi files in dts folders. These are automatically included to > DTS before DTC is called. It means you don't need to build overlay to > get merged. > > >> And also if you take a look how dtb looks like (convert back to dts) you > >> can see that for example aliases are using full path (just &label) but > >> clocks/gic which is the part of <> is handled via phandles as numbers. > >> > >> And labels names can vary and shouldn't be the part of binding doc as > >> far as I know. But I can be wrong of course. > > > > The DT bindings should document the interface with the operating system, > > and if applicable, the boot loader. If the boot loader requires a > > particular label, then it becomes part of the ABI, and I think it should > > be documented in the bindings. > > We have been discussing with Rob some month ago but didn't have a time > to do step further. Just keep it short Rob was ok to keep bootloader > binding inside Linux repo. I think that makes sense, DT bindings are meant to be OS-agnostic, so boot loader requirements should be documented there. > There is no hardcoding for a particular name. There is just a need to > have any label. U-Boot needs to have one property(e.g. > u-boot,dm-pre-reloc;) just to do early allocation. > The name is just reference and none is really looking for it. It is just > a way how to include it in much easier way. Just to make sure I understand this issue correctly, does this mean that you need to reference the node in a *-u-boot.dtsi file, and want a label to do so ? The label name needs to be the same in the base file (taken from the Linux source tree) and the *-u-boot.dtsi file (in the U-Boot source tree) in that case. Isn't it the role of DT bindings to document such requirements ? -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel