From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Device Tree nodes ending with -supply Date: Mon, 20 May 2019 17:51:27 +0200 Message-ID: <20190520155127.cdc6dofoqckwsrrb@flea> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline 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: Rob Herring Cc: devicetree@vger.kernel.org, Chen-Yu Tsai , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org Hi Rob, I've noticed that you recently added support to validate the *-supply properties in the dt-schema tools. However, we have a family of PMIC that are exposing a bunch of power supplies (battery, AC, USB, etc) to know what is currently powering the board. All these various supplies are exposed as children nodes of the PMIC itself, and they are named *-power-supply. For an example, you can look at: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/axp209.dtsi#n56 Now, those are obviously not properties, and yet the current dt-schema schemas are trying to validate them. I'm not really sure how to fix that. Changing the node names seems like an obvious solution, but they seem to be what they should be. Can we reduce the scope of the validation to only match properties (ie arrays?) and not the nodes (objects?) Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com 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.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_NEOMUTT 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 271D5C04AAC for ; Mon, 20 May 2019 15:51:53 +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 F0E7121479 for ; Mon, 20 May 2019 15:51:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nDK8n+rI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0E7121479 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com 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:MIME-Version: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:In-Reply-To:References: List-Owner; bh=8nih3Be183l1syn5iyuC2pVaX3BpqyGOIW0fK1zGTdg=; b=nDK8n+rI5CzmaI /yXGOvgLWvIK03YbKqr+bMdfkqvx9wlHEehBiPr160AxM2wCUnCHon7MoFdlzIg3V0++r3j6BuUgx Tu6uTINaGjZqu4tdAlRXUeVo3kgBqTRbn2cC4AGZ/+DZqAjRTuH9zFGQESUzkwe4unzTuX2nr/CD9 99qrZ0X3oKpsHeubswVbXhaX3gobSK1LNyOJhgEubYX+ZHG+vKPPOqSuZvYwG5/4vEOEs2Ico3i8W ZCLDW0SWdM+4/PQhz43TStaJye8vSwt/zmA+JsD3dmIz8wfE1cLn5JBQDxRZRAB3EobqRCzF7pDMl P9uYUUnlAGRuAW/ivEng==; 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 1hSkZl-0001si-IC; Mon, 20 May 2019 15:51:45 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hSkZi-0001sO-Ga for linux-arm-kernel@lists.infradead.org; Mon, 20 May 2019 15:51:44 +0000 X-Originating-IP: 90.89.68.76 Received: from localhost (lfbn-1-10718-76.w90-89.abo.wanadoo.fr [90.89.68.76]) (Authenticated sender: maxime.ripard@bootlin.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 6EBF0E0015; Mon, 20 May 2019 15:51:28 +0000 (UTC) Date: Mon, 20 May 2019 17:51:27 +0200 From: Maxime Ripard To: Rob Herring Subject: Device Tree nodes ending with -supply Message-ID: <20190520155127.cdc6dofoqckwsrrb@flea> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190520_085142_701951_56D737F0 X-CRM114-Status: UNSURE ( 8.23 ) X-CRM114-Notice: Please train this message. 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: devicetree@vger.kernel.org, Chen-Yu Tsai , 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+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Rob, I've noticed that you recently added support to validate the *-supply properties in the dt-schema tools. However, we have a family of PMIC that are exposing a bunch of power supplies (battery, AC, USB, etc) to know what is currently powering the board. All these various supplies are exposed as children nodes of the PMIC itself, and they are named *-power-supply. For an example, you can look at: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/axp209.dtsi#n56 Now, those are obviously not properties, and yet the current dt-schema schemas are trying to validate them. I'm not really sure how to fix that. Changing the node names seems like an obvious solution, but they seem to be what they should be. Can we reduce the scope of the validation to only match properties (ie arrays?) and not the nodes (objects?) Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel