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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no 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 4CA49C48BC2 for ; Wed, 23 Jun 2021 06:12:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C6BB61350 for ; Wed, 23 Jun 2021 06:12:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229665AbhFWGOU (ORCPT ); Wed, 23 Jun 2021 02:14:20 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:45028 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229660AbhFWGOT (ORCPT ); Wed, 23 Jun 2021 02:14:19 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: rcn) with ESMTPSA id 75EF81F42F80 Message-ID: <52caf3779aa5b764bf193264cd5c5b8a542dea0a.camel@collabora.com> Subject: Re: [RESEND PATCH v4 3/3] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml From: Ricardo =?ISO-8859-1?Q?Ca=F1uelo?= To: Laurent Pinchart , Geert Uytterhoeven Cc: David Airlie , Daniel Vetter , Michal Simek , alexandre.torgue@foss.st.com, Collabora Kernel ML , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , Rob Herring , Wei Xu , Maxime Coquelin , Marek Vasut , Linux-Renesas Date: Wed, 23 Jun 2021 08:11:51 +0200 In-Reply-To: References: <20210615131333.2272473-1-ricardo.canuelo@collabora.com> <20210615131333.2272473-4-ricardo.canuelo@collabora.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi, > On Fri, Jun 18, 2021 at 09:55:38AM +0200, Geert Uytterhoeven wrote: > > This causes lots of failures like: > > > > arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dt.yaml: hdmi@39: > > 'avdd-supply' is a required property > > > > Should all supplies be required? > > Looking at the driver, missing supplies are automatically replaced by > > dummy regulators by the regulator framework. > > Generally speaking, I like DT bindings to be descriptive of the > hardware, and thus require power supplies that are needed for the device > to function, even if they are fixed supplies. > > This being said, I think there's also room to group some power supplies > together in the bindings, when they are not meant by the device to be > controlled separately. In this specific case, we also need to take into > account that the adv7511 and adv7533 have different supplies. Thanks for the review, guys. Yes, there were some dtbs check warnings to be expected, the consensus in a previous version of the patch was that that shouldn't be a blocker for a binding conversion and that the *.dts definitions should eventually be fixed to comply with the binding, which is, IMO, a more reasonable process to keep the binding conversion effort progressing. Cheers, Ricardo 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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no 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 BA532C4743C for ; Wed, 23 Jun 2021 06:13:37 +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 7B5AE611AD for ; Wed, 23 Jun 2021 06:13:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B5AE611AD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=U97eFHszAOicMqXxGKqyiXDncQ2+BzMO15gIQgF8kMQ=; b=QpeQhoLPGUG7f5 lJ5rPVp4z18a0St3Z5IV9a1Qu23RcJvaZH7aVz97CrGdPUI7xpZIVxMQP80sufF733GVuq3Gw6pXu 8I+TkIdTsthx1FH+D3il4D+EdkoSJJFlDmFRb3UIBW1betUBNYOPcqJyOGRlNqB1V8HlFJYtPLMRh 5TNQR+RQ0xK2WvjND9eP/qESW++by/O/17EmNkGwoyZU458eZaJ2DMnK0O9cb9Ym2evyFdoEuO2pN AaH3it89YCMfjE8SKVBxpatmx7TGtPkbmWLW3weiHmKpWuK/ZPllPNPzwv5etL/D7BBcpzLj56RBY xPUwLxcj07Ir9PTlo6pg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvw7N-009WQ4-SW; Wed, 23 Jun 2021 06:12:10 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvw7J-009WO0-O3 for linux-arm-kernel@lists.infradead.org; Wed, 23 Jun 2021 06:12:07 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: rcn) with ESMTPSA id 75EF81F42F80 Message-ID: <52caf3779aa5b764bf193264cd5c5b8a542dea0a.camel@collabora.com> Subject: Re: [RESEND PATCH v4 3/3] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml From: Ricardo =?ISO-8859-1?Q?Ca=F1uelo?= To: Laurent Pinchart , Geert Uytterhoeven Cc: David Airlie , Daniel Vetter , Michal Simek , alexandre.torgue@foss.st.com, Collabora Kernel ML , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , Rob Herring , Wei Xu , Maxime Coquelin , Marek Vasut , Linux-Renesas Date: Wed, 23 Jun 2021 08:11:51 +0200 In-Reply-To: References: <20210615131333.2272473-1-ricardo.canuelo@collabora.com> <20210615131333.2272473-4-ricardo.canuelo@collabora.com> User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210622_231205_970164_2E42A8F2 X-CRM114-Status: GOOD ( 17.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, > On Fri, Jun 18, 2021 at 09:55:38AM +0200, Geert Uytterhoeven wrote: > > This causes lots of failures like: > > > > arm/boot/dts/r8a7743-iwg20d-q7-dbcm-ca.dt.yaml: hdmi@39: > > 'avdd-supply' is a required property > > > > Should all supplies be required? > > Looking at the driver, missing supplies are automatically replaced by > > dummy regulators by the regulator framework. > > Generally speaking, I like DT bindings to be descriptive of the > hardware, and thus require power supplies that are needed for the device > to function, even if they are fixed supplies. > > This being said, I think there's also room to group some power supplies > together in the bindings, when they are not meant by the device to be > controlled separately. In this specific case, we also need to take into > account that the adv7511 and adv7533 have different supplies. Thanks for the review, guys. Yes, there were some dtbs check warnings to be expected, the consensus in a previous version of the patch was that that shouldn't be a blocker for a binding conversion and that the *.dts definitions should eventually be fixed to comply with the binding, which is, IMO, a more reasonable process to keep the binding conversion effort progressing. Cheers, Ricardo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel