Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp79146pxb; Tue, 5 Oct 2021 23:53:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXv7oF1ytFqAN+adMtyxMKCkD0b6qqL602Ut5q7t2Ukzpej3ruEUjx/KkhdQ1PCy2lRGCp X-Received: by 2002:a17:902:7804:b0:13e:d4c6:e701 with SMTP id p4-20020a170902780400b0013ed4c6e701mr9375157pll.66.1633503194892; Tue, 05 Oct 2021 23:53:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633503194; cv=none; d=google.com; s=arc-20160816; b=Ae/QPWUvJRU3dmoAmIJGnNRS7BfH89tLQdrL3VWLbY76+x1GuOaDJgTlVJV7m0VOwM QCLmL+T1E7vSsXMOQLpLFEzVxiYA17k71JiT9tcqkoo7c/WQxMN67CClDRGIecpemWGF JJsi+vAxqPrcGiakVXgIfFo8acqxePqrhnCZwX3TEsS4LJrJ3vVrb+9+m4PaPSh7j/oU 0epiAf+VTklS7SXsfAp+UX4lUF4R6vDibXP0EUG9r765yVWL+5F0tWmzAGacTpVFoD9Z TntEVA14wYPUOWbQBqt+b9ybb0wE0NJDjzKg9OxOWrD/eYoNid72dMI0Drqhp0EEXOsP kg3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=rO925toKGJpSuU4pLXeMxuqM2/M7LYZ/XbcUM5PgYCA=; b=giq6E16Qih3QFUh4hdAqlrgib/LOG5o8BvsWWSTRKq3oXx7buxpRVRiIGMXd8DZwD0 SyOTd5NoL+P1s/t8CGCbz7V4cXuP4Ua5ke84rJU2QuG9mggoS7QDqN06kKEJkxBUou+V yGlVeXhJ5N4/a5U4i5EDmmxSyD8LTnySWdVm83B9+niwM8BEsW16SCU9egKAc0J8L0fU B6Au2Bj+R+QGEJWDnM0EipV6ygh+I6uGytY3C3+1Mynabf76yI/7wYunkBoDm67WI7WN 17cano6jVSETzeTLxACtPWf4E1tZaXSgLdHd81ag17qrQEy4MwbeEQGBcEKl/rX7weaV vxzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=5NjtWws5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d10si11665121pln.261.2021.10.05.23.53.01; Tue, 05 Oct 2021 23:53:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=5NjtWws5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237213AbhJFGxY (ORCPT + 99 others); Wed, 6 Oct 2021 02:53:24 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:48238 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229956AbhJFGxX (ORCPT ); Wed, 6 Oct 2021 02:53:23 -0400 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1961ksGV015791; Wed, 6 Oct 2021 08:51:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=rO925toKGJpSuU4pLXeMxuqM2/M7LYZ/XbcUM5PgYCA=; b=5NjtWws5VCmwoC2Bp39pmuU0vGYVTPiuuIiyTS6mmxvU6/2DFmyHspwAq0aoAQVtCZAr nZlTEHJ7yRPVldLaU2Z3Ac4zuDb6nPoMuCEFeZOEJjsQaQgXtZkxgqUThTiN9YiDD8cx cHrRP+tJUz8+Vf0OUH7smvteCpkegWVZ9+qwHT+vCjqJR7Y+tulY/rVLjkoCAfLQjrms TKkMZd1kQtIhnv3xtQIThE5MxT660cebxtS28rnFzh+/qscThp7l3m402qyEV8erHPLp wzA3uFWcB4+SAkaOD9M26p4Fxfs2Oe+Da3qb8F6smJKxYki1B6X1+FH5lHM/k4QDEc+F Ng== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 3bh2eh9e5g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Oct 2021 08:51:15 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2CD1A100034; Wed, 6 Oct 2021 08:51:14 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag2node2.st.com [10.75.127.5]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 2289F214D39; Wed, 6 Oct 2021 08:51:14 +0200 (CEST) Received: from lmecxl0995.lme.st.com (10.75.127.50) by SFHDAG2NODE2.st.com (10.75.127.5) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 6 Oct 2021 08:51:12 +0200 Subject: Re: [PATCH v2 2/3] dt-bindings: phy: phy-stm32-usbphyc: add optional phy tuning properties To: Rob Herring CC: , Rob Herring , , , Kishon Vijay Abraham I , Vinod Koul , Alexandre Torgue , , Maxime Coquelin , References: <20211005152453.89330-1-amelie.delaunay@foss.st.com> <20211005152453.89330-3-amelie.delaunay@foss.st.com> <1633473959.465401.106809.nullmailer@robh.at.kernel.org> From: Amelie DELAUNAY Message-ID: <491ab475-e7dc-eb71-85aa-6d82543b74db@foss.st.com> Date: Wed, 6 Oct 2021 08:51:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <1633473959.465401.106809.nullmailer@robh.at.kernel.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.50] X-ClientProxiedBy: SFHDAG1NODE2.st.com (10.75.127.2) To SFHDAG2NODE2.st.com (10.75.127.5) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-05_06,2021-10-04_01,2020-04-07_01 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On 10/6/21 12:45 AM, Rob Herring wrote: > On Tue, 05 Oct 2021 17:24:52 +0200, Amelie Delaunay wrote: >> This patch adds the description of new optional phy tuning properties >> for usbphyc phy sub nodes. >> >> Signed-off-by: Amelie Delaunay >> --- >> Changes in v2: >> - st,phy-tuning property removed >> - tuning properties are now put directly in each child node >> - tuning properties are no more free form text and their name reworked >> --- >> .../bindings/phy/phy-stm32-usbphyc.yaml | 126 ++++++++++++++++++ >> 1 file changed, 126 insertions(+) >> > > Running 'make dtbs_check' with the schema in this patch gives the > following warnings. Consider if they are expected or the schema is > incorrect. These may not be new warnings. > > Note that it is not yet a requirement to have 0 warnings for dtbs_check. > This will change in the future. > > Full log is available here: https://patchwork.ozlabs.org/patch/1536730 > > > usbphyc@5a006000: usb-phy@0: 'phy-supply' is a required property > arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dt.yaml > arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dt.yaml > arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dt.yaml > arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dt.yaml > arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml > arch/arm/boot/dts/stm32mp157c-odyssey.dt.yaml > > usbphyc@5a006000: usb-phy@1: 'phy-supply' is a required property > arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dt.yaml > arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dt.yaml > arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dt.yaml > arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dt.yaml > arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml > arch/arm/boot/dts/stm32mp157c-odyssey.dt.yaml > These warnings are due to the fact that usbphyc parent node is disabled in parent device tree (stm32mp151.dtsi) but not the "usb-phy" child nodes. These warnings are not introduced by this current patch "optional phy tuning properties" but anyway. The device trees mentioned don't enable usbphyc, so they don't have to set phy-supply in usbphyc child nodes. $ git diff arch/arm/boot/dts/stm32mp151.dtsi diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi index bd289bf5d269..abef8b6be40a 100644 --- a/arch/arm/boot/dts/stm32mp151.dtsi +++ b/arch/arm/boot/dts/stm32mp151.dtsi @@ -1507,11 +1507,13 @@ usbphyc: usbphyc@5a006000 { usbphyc_port0: usb-phy@0 { #phy-cells = <0>; reg = <0>; + status = "disabled"; }; usbphyc_port1: usb-phy@1 { #phy-cells = <1>; reg = <1>; + status = "disabled"; }; }; Disable child nodes while parent node is already disabled fixes the warning. But it means to add status = "okay"; in child nodes everywhere usbphyc is enabled. Is it normal dtbs_check checks in child nodes when parent node is disabled? Regards, Amelie