From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH] dt-bindings: Add schemas for simple-framebuffer Date: Wed, 27 Mar 2019 08:20:18 -0500 Message-ID: References: <20190325135414.9728-1-maxime.ripard@bootlin.com> <20190326213526.w3t7fga7uzkkliq7@flea> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190326213526.w3t7fga7uzkkliq7@flea> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Maxime Ripard Cc: Mark Rutland , devicetree@vger.kernel.org, Maxime Jourdan , Bartlomiej Zolnierkiewicz , Hans de Goede , Chen-Yu Tsai , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" List-Id: devicetree@vger.kernel.org On Tue, Mar 26, 2019 at 4:35 PM Maxime Ripard wrote: > > Hi, > > On Mon, Mar 25, 2019 at 11:27:36AM -0500, Rob Herring wrote: > > On Mon, Mar 25, 2019 at 8:54 AM Maxime Ripard wrote: > > > > > > The simple framebuffer is a binding that allows the bootloader to setup a > > > framebuffer, describe it in the Device Tree for the OS to pick it up and > > > use it as is. > > > > > > Replace the current binding by a schema to allow the validation tools to > > > check those nodes. > > > > > > Cc: Bartlomiej Zolnierkiewicz > > > Cc: Chen-Yu Tsai > > > Cc: Hans de Goede > > > Cc: Maxime Jourdan > > > Signed-off-by: Maxime Ripard > > > > > > --- > > > > > > Rob, > > > > > > Even though the node itself is properly described, I still end up with some > > > validation warnings when the chosen node is validated (basically > > > complaining that ranges, and the framebuffer nodes shouldn't be here, since > > > we haven't described them in the chosen schemas). > > > > Having 'ranges' is a bit strange because 'chosen' doesn't have an > > address. We can add #address-cells, #size-cells and framebuffer child > > node to the base chosen schema. > > Maybe that's just cargo cult, but both the amlogic and the sunxi DT > have ranges in chosen. Shouldn't we need it so that the address is > decoded properly? I don't think so. If you have #{size,address}-cells then that should be enough. Lack of ranges should just mean that any translation stops at that level. But it is possible that the kernel code requires translation to go all the way to the root for memory addresses. I haven't checked. Rob 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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham 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 A399FC43381 for ; Wed, 27 Mar 2019 13:20:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 610CE2146F for ; Wed, 27 Mar 2019 13:20:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lv69QHaC"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ySgoTXck" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 610CE2146F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/Arq9eP689qVH8BThoxAXSoElbJcPcOtCMf0q3PF674=; b=lv69QHaCYM90Ov wtpJT1cS4wKJvci4MJCSgsiprGFcPFBEmxOWkVWxdnPMsINsbVi77KnClWb9noWEFDw7jWjZzXcq/ 2pmoLh8Ta7szF5WG/vAM3xA+wZex4DqgTJWh4fqfaAdC8EY2ViqK+P0U+Qe5UbcIdpt0eNY1EWihx nPloWrIvCJ09xFcRDL/3LVYLX1sP5km8j4yk1PXzH1xddTNfsJ75mDTV3OdG6Ki6AkP82ESWMxqU9 gvT78XoYCcRX+2fDqtaE6Eh8nDs4MevnETVTisUZiaobXweyvyTTprhkShPgxFGmeTnOXUYFQjAN2 zSGp4SB1EUS7J6uJpO/Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h98Ty-0003H6-27; Wed, 27 Mar 2019 13:20:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h98Tn-0003Bt-Nv for linux-arm-kernel@lists.infradead.org; Wed, 27 Mar 2019 13:20:39 +0000 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF7CA21738 for ; Wed, 27 Mar 2019 13:20:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553692830; bh=39AJOQxjDhfc8mZpQVz/SqMj6NcUgb8kXalzxAsItvo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ySgoTXckXZYLtmmE2h+J1oxD5RKuKAxYuStx/NyIo/ELWphcnohWsxgxjWVsLIddf Nk0mqPIFc36+tJ/MWRtAgybZbzTQCn25ptUGgxQJl5Xg5Ls2RIlaRNK+/FTmQDgpiZ Jar+JvGiksQQkAYwz3vVOjvn1Q13B4eO9CmLUjF8= Received: by mail-qk1-f172.google.com with SMTP id c1so9836523qkk.4 for ; Wed, 27 Mar 2019 06:20:30 -0700 (PDT) X-Gm-Message-State: APjAAAUDUfZqPlgvVWLBuCDa4t0rw9lCj4VUQ1Deq471g98auZo9fCvz BYXez4cHEABGAsHSgtU72630t6vE1+icao8sUA== X-Google-Smtp-Source: APXvYqzGzjv1kbXt5aTS70l5fWLa0DxvOEptyETurVqMaNFqze8EG2Yc8GKrIMurfLEKbqdsz8cPRVQUu8SnDXTFISo= X-Received: by 2002:ae9:e417:: with SMTP id q23mr26699428qkc.29.1553692830045; Wed, 27 Mar 2019 06:20:30 -0700 (PDT) MIME-Version: 1.0 References: <20190325135414.9728-1-maxime.ripard@bootlin.com> <20190326213526.w3t7fga7uzkkliq7@flea> In-Reply-To: <20190326213526.w3t7fga7uzkkliq7@flea> From: Rob Herring Date: Wed, 27 Mar 2019 08:20:18 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] dt-bindings: Add schemas for simple-framebuffer To: Maxime Ripard X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190327_062031_959259_58BBBCC7 X-CRM114-Status: GOOD ( 23.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Maxime Jourdan , Bartlomiej Zolnierkiewicz , Hans de Goede , Chen-Yu Tsai , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Mar 26, 2019 at 4:35 PM Maxime Ripard wrote: > > Hi, > > On Mon, Mar 25, 2019 at 11:27:36AM -0500, Rob Herring wrote: > > On Mon, Mar 25, 2019 at 8:54 AM Maxime Ripard wrote: > > > > > > The simple framebuffer is a binding that allows the bootloader to setup a > > > framebuffer, describe it in the Device Tree for the OS to pick it up and > > > use it as is. > > > > > > Replace the current binding by a schema to allow the validation tools to > > > check those nodes. > > > > > > Cc: Bartlomiej Zolnierkiewicz > > > Cc: Chen-Yu Tsai > > > Cc: Hans de Goede > > > Cc: Maxime Jourdan > > > Signed-off-by: Maxime Ripard > > > > > > --- > > > > > > Rob, > > > > > > Even though the node itself is properly described, I still end up with some > > > validation warnings when the chosen node is validated (basically > > > complaining that ranges, and the framebuffer nodes shouldn't be here, since > > > we haven't described them in the chosen schemas). > > > > Having 'ranges' is a bit strange because 'chosen' doesn't have an > > address. We can add #address-cells, #size-cells and framebuffer child > > node to the base chosen schema. > > Maybe that's just cargo cult, but both the amlogic and the sunxi DT > have ranges in chosen. Shouldn't we need it so that the address is > decoded properly? I don't think so. If you have #{size,address}-cells then that should be enough. Lack of ranges should just mean that any translation stops at that level. But it is possible that the kernel code requires translation to go all the way to the root for memory addresses. I haven't checked. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel