LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Amelie DELAUNAY <amelie.delaunay@foss.st.com>
To: Rob Herring <robh@kernel.org>
Cc: <linux-stm32@st-md-mailman.stormreply.com>,
	Rob Herring <robh+dt@kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-phy@lists.infradead.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Vinod Koul <vkoul@kernel.org>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	<linux-kernel@vger.kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] dt-bindings: phy: phy-stm32-usbphyc: add optional phy tuning properties
Date: Wed, 6 Oct 2021 08:51:11 +0200	[thread overview]
Message-ID: <491ab475-e7dc-eb71-85aa-6d82543b74db@foss.st.com> (raw)
In-Reply-To: <1633473959.465401.106809.nullmailer@robh.at.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 <amelie.delaunay@foss.st.com>
>> ---
>> 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

  reply	other threads:[~2021-10-06  6:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 15:24 [PATCH v2 0/3] phy: stm32: add phy tuning support Amelie Delaunay
2021-10-05 15:24 ` [PATCH v2 1/3] phy: stm32: restore utmi switch on resume Amelie Delaunay
2021-10-05 15:24 ` [PATCH v2 2/3] dt-bindings: phy: phy-stm32-usbphyc: add optional phy tuning properties Amelie Delaunay
2021-10-05 22:45   ` Rob Herring
2021-10-06  6:51     ` Amelie DELAUNAY [this message]
2021-10-06 12:38       ` Rob Herring
2021-10-06 12:58         ` Amelie DELAUNAY
2021-10-14 18:16           ` Rob Herring
2021-10-15  9:10             ` Amelie DELAUNAY
2021-10-14 17:26   ` Rob Herring
2021-10-05 15:24 ` [PATCH v2 3/3] phy: stm32: add phy tuning support Amelie Delaunay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=491ab475-e7dc-eb71-85aa-6d82543b74db@foss.st.com \
    --to=amelie.delaunay@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    --subject='Re: [PATCH v2 2/3] dt-bindings: phy: phy-stm32-usbphyc: add optional phy tuning properties' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).