[PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Rob Herring (Arm)]

For the QUSB2 PHY binding, keep the three regulator supplies required
except for legacy IPQ6018 nodes that do not describe the board rails.

This relaxes the requirements for the IPQ5210 as well as if it is
compatible with IPQ6018, then it shouldn't have more required
properties either.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
v2:
 - Fix trailing whitespace
 - Add blurb to commit msg (for sashiko)
---
 .../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 001fd0ccc985..1245b174b0ab 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -165,12 +165,23 @@ required:
   - "#phy-cells"
   - clocks
   - clock-names
-  - vdd-supply
-  - vdda-pll-supply
-  - vdda-phy-dpdm-supply
   - resets
 
 allOf:
+  - if:
+      not:
+        properties:
+          compatible:
+            contains:
+              enum:
+                - qcom,ipq6018-qusb2-phy
+                - qcom,ipq8074-qusb2-phy
+    then:
+      required:
+        - vdd-supply
+        - vdda-pll-supply
+        - vdda-phy-dpdm-supply
+
   - if:
       not:
         properties:
-- 
2.53.0

Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Vinod Koul]

On 20-10-26, 21:24, Rob Herring (Arm) wrote:
> For the QUSB2 PHY binding, keep the three regulator supplies required
> except for legacy IPQ6018 nodes that do not describe the board rails.
> 
> This relaxes the requirements for the IPQ5210 as well as if it is
> compatible with IPQ6018, then it shouldn't have more required
> properties either.

Hey Rob,

This fails for phy/next I see vdd-supply has been moved around..

-- 
~Vinod

Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Rob Herring]

+Konrad

On Thu, Nov 12, 2026 at 04:27:30PM +0530, Vinod Koul wrote:
> On 20-10-26, 21:24, Rob Herring (Arm) wrote:
> > For the QUSB2 PHY binding, keep the three regulator supplies required
> > except for legacy IPQ6018 nodes that do not describe the board rails.
> > 
> > This relaxes the requirements for the IPQ5210 as well as if it is
> > compatible with IPQ6018, then it shouldn't have more required
> > properties either.
> 
> Hey Rob,
> 
> This fails for phy/next I see vdd-supply has been moved around..

The change in question[1] should not be applied until the .dts changes 
in the series are applied. It introduces a bunch of warnings. Can the
QCom folks stop doing that! Coordinate applying the series or take 
the binding and dts changes in 1 tree. Given the patch series is 2+ 
months old, I'd be surprised if the rest gets applied.

This patch OTOH fixes warnings.

Rob


[1] https://lore.kernel.org/all/qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com

Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Vinod Koul]

On 12-11-26, 06:53, Rob Herring wrote:
> +Konrad
> 
> On Thu, Nov 12, 2026 at 04:27:30PM +0530, Vinod Koul wrote:
> > On 20-10-26, 21:24, Rob Herring (Arm) wrote:
> > > For the QUSB2 PHY binding, keep the three regulator supplies required
> > > except for legacy IPQ6018 nodes that do not describe the board rails.
> > > 
> > > This relaxes the requirements for the IPQ5210 as well as if it is
> > > compatible with IPQ6018, then it shouldn't have more required
> > > properties either.
> > 
> > Hey Rob,
> > 
> > This fails for phy/next I see vdd-supply has been moved around..
> 
> The change in question[1] should not be applied until the .dts changes 
> in the series are applied. It introduces a bunch of warnings. Can the
> QCom folks stop doing that! Coordinate applying the series or take 
> the binding and dts changes in 1 tree. Given the patch series is 2+ 
> months old, I'd be surprised if the rest gets applied.

If Konrad/Bjorn want to take this all together thur QC tree they can
have my ack

Acked-by: Vinod Koul <vkoul@kernel.org>

-- 
~Vinod

Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Bjorn Andersson]

On Thu, Nov 12, 2026 at 06:53:46AM -0600, Rob Herring wrote:
> +Konrad
> 
> On Thu, Nov 12, 2026 at 04:27:30PM +0530, Vinod Koul wrote:
> > On 20-10-26, 21:24, Rob Herring (Arm) wrote:
> > > For the QUSB2 PHY binding, keep the three regulator supplies required
> > > except for legacy IPQ6018 nodes that do not describe the board rails.
> > > 
> > > This relaxes the requirements for the IPQ5210 as well as if it is
> > > compatible with IPQ6018, then it shouldn't have more required
> > > properties either.
> > 
> > Hey Rob,
> > 
> > This fails for phy/next I see vdd-supply has been moved around..
> 
> The change in question[1] should not be applied until the .dts changes 
> in the series are applied. It introduces a bunch of warnings.

I don't understand. The change you present here relates to ipq5210 and
ipq6018.

That change doesn't touch these two IPQs, so what are you suggesting?
Are we talking about the same warnings?

> Can the QCom folks stop doing that! Coordinate applying the series or
> take the binding and dts changes in 1 tree.

I assume you're referring to "QCom folks" in the sense "any maintainer
touching a binding change related to a qcom platform"?

Do you have some CI/guidance/tooling for Vinod (and other subsystem
maintainers) to perform system-wide DT-validation when considering
merging a binding change?


I unfortunately only spotted the one-way dependency when glancing at the
seris and thereby ignored the dts patches waiting for the binding to be
merged.

> Given the patch series is 2+ months old, I'd be surprised if the rest
> gets applied.

I've applied the two dts changes today, and they do resolve a number of
warnings - presumably the ones that you're talking about, but I don't
think the ones that this patch aim to fix?

> 
> This patch OTOH fixes warnings.
> 

What warnings? Can you please provide actionable context when you're
pointing out these issues.

Is it the three "'x-supply' is a required property" warnings from
ipq6018-cp01-c1.dtb? It seems unlikely that there's one chip that
doesn't depend on those supplies.

> Rob
> 
> 
> [1] https://lore.kernel.org/all/qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com

https://lore.kernel.org/all/20260903-topic-8996_61x5_qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com/

Regards,
Bjorn

Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Rob Herring]

On Thu, Nov 12, 2026 at 12:30 PM Bjorn Andersson <andersson@kernel.org> wrote:
>
> On Thu, Nov 12, 2026 at 06:53:46AM -0600, Rob Herring wrote:
> > +Konrad
> >
> > On Thu, Nov 12, 2026 at 04:27:30PM +0530, Vinod Koul wrote:
> > > On 20-10-26, 21:24, Rob Herring (Arm) wrote:
> > > > For the QUSB2 PHY binding, keep the three regulator supplies required
> > > > except for legacy IPQ6018 nodes that do not describe the board rails.
> > > >
> > > > This relaxes the requirements for the IPQ5210 as well as if it is
> > > > compatible with IPQ6018, then it shouldn't have more required
> > > > properties either.
> > >
> > > Hey Rob,
> > >
> > > This fails for phy/next I see vdd-supply has been moved around..
> >
> > The change in question[1] should not be applied until the .dts changes
> > in the series are applied. It introduces a bunch of warnings.
>
> I don't understand. The change you present here relates to ipq5210 and
> ipq6018.
>
> That change doesn't touch these two IPQs, so what are you suggesting?
> Are we talking about the same warnings?

This is what I get with phy-next because it has the binding change
from [1], but not the .dts changes in the series:

arch/arm64/boot/dts/qcom/apq8096-db820c.dtb: phy@7411000
(qcom,msm8996-qusb2-phy): "power-domains" is a required property
        from schema $id:
http://devicetree.org/schemas/phy/qcom,qusb2-phy.yaml
arch/arm64/boot/dts/qcom/apq8096-db820c.dtb: phy@7411000
(qcom,msm8996-qusb2-phy): "required-opps" is a required property
        from schema $id:
http://devicetree.org/schemas/phy/qcom,qusb2-phy.yaml

(and then duplicated for every 8996 board).

> > Can the QCom folks stop doing that! Coordinate applying the series or
> > take the binding and dts changes in 1 tree.
>
> I assume you're referring to "QCom folks" in the sense "any maintainer
> touching a binding change related to a qcom platform"?

No, primarily you and the submitter I guess. Submitters should be
aware of dependencies in their series and suggest how things are
merged. Otherwise, it falls on you to care that warnings are getting
introduced.

I would not care so much when there are transient warnings in next,
but I don't want to be the one chasing them down. But AFAICT, it's
always me. No one beats me to it and I'm not all that fast in
noticing. I just compare all the warnings by platform for Linus vs.
next with "gl-diff-dtb-warning -p arm64" from this repo[2], and look
for things moving in the right direction. Of course this is all after
applying which isn't ideal.

> Do you have some CI/guidance/tooling for Vinod (and other subsystem
> maintainers) to perform system-wide DT-validation when considering
> merging a binding change?

This one is an ABI break because it adds new required properties. I do
have some tooling that looks for ABI changes, but haven't committed it
because I haven't figured out the best way to deploy it. I think for
anything that is an ABI change, the binding and dts files need to go
in together.

I think it is time to reconsider the default of bindings go in with
the driver. That works okay for new bindings as long as the platform
maintainer doesn't take .dts changes before bindings land (also an
issue). However, for cases like this, we need the opposite order. We
need to figure something out because this is only going to be more of
an issue as we get to warning free (and we are close).

> I unfortunately only spotted the one-way dependency when glancing at the
> seris and thereby ignored the dts patches waiting for the binding to be
> merged.
>
> > Given the patch series is 2+ months old, I'd be surprised if the rest
> > gets applied.
>
> I've applied the two dts changes today, and they do resolve a number of
> warnings - presumably the ones that you're talking about, but I don't
> think the ones that this patch aim to fix?

Other than the warnings it introduces, the [1] series fixes this one warning;

      3 phy@7411000 (qcom,msm8996-qusb2-phy): "vdd-supply" is a
required property


> > This patch OTOH fixes warnings.
> >
>
> What warnings? Can you please provide actionable context when you're
> pointing out these issues.
>
> Is it the three "'x-supply' is a required property" warnings from
> ipq6018-cp01-c1.dtb? It seems unlikely that there's one chip that
> doesn't depend on those supplies.

Of your 20 unique warnings, it's these 10:

      1 qusb@59000 (qcom,ipq6018-qusb2-phy): "vdd-supply" is a required property
      1 qusb@59000 (qcom,ipq6018-qusb2-phy): "vdda-pll-supply" is a
required property
      1 qusb@59000 (qcom,ipq6018-qusb2-phy): "vdda-phy-dpdm-supply" is
a required property
      1 phy@79000 (qcom,ipq8074-qusb2-phy): "vdd-supply" is a required property
      1 phy@79000 (qcom,ipq8074-qusb2-phy): "vdda-pll-supply" is a
required property
      1 phy@79000 (qcom,ipq8074-qusb2-phy): "vdda-phy-dpdm-supply" is
a required property
      1 phy@59000 (qcom,ipq8074-qusb2-phy): "vdd-supply" is a required property
      1 phy@59000 (qcom,ipq8074-qusb2-phy): "vdda-pll-supply" is a
required property
      1 phy@59000 (qcom,ipq8074-qusb2-phy): "vdda-phy-dpdm-supply" is
a required property

Rob

> > [1] https://lore.kernel.org/all/qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com

[2] https://gitlab.com/robherring/ci-jobs

Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Krzysztof Kozlowski]

On 12/11/2026 20:22, Rob Herring wrote:
> On Thu, Nov 12, 2026 at 12:30 PM Bjorn Andersson <andersson@kernel.org> wrote:


(replying only to parts of the message)


> 
>>> Can the QCom folks stop doing that! Coordinate applying the series or
>>> take the binding and dts changes in 1 tree.
>>
>> I assume you're referring to "QCom folks" in the sense "any maintainer
>> touching a binding change related to a qcom platform"?
> 
> No, primarily you and the submitter I guess. Submitters should be
> aware of dependencies in their series and suggest how things are
> merged. Otherwise, it falls on you to care that warnings are getting
> introduced.

We all have been swamped with patches and Qualcomm have been probably
the busiest arm64 platform for months now.

for i in arch/arm64/boot/dts/* ; do echo "${i}:$(git log --no-merges
--oneline v7.0..v7.4-rc1 -- $i | wc -l)" ; done

qcom: 1016
freescale: 485
renesas: 215

Qualcomm SoC got one more maintainer, so there is catching up, but
probably not enough.

> 
> I would not care so much when there are transient warnings in next,
> but I don't want to be the one chasing them down. But AFAICT, it's
> always me. No one beats me to it and I'm not all that fast in
> noticing. I just compare all the warnings by platform for Linus vs.
> next with "gl-diff-dtb-warning -p arm64" from this repo[2], and look
> for things moving in the right direction. Of course this is all after
> applying which isn't ideal.

FWIW, I do test all Samsung ones and I look only at some of Qualcomm
boards, because there were just too many warnings to have a clean
dtbs_check for qcom. I do report them to Bjorn/Konrad [1], but that's
indeed only subset of entire qcom ecosystem. I know that a few other SoC
platforms keep track (TI at least).

[1] https://krzk.eu/#/builders/102


> 
>> Do you have some CI/guidance/tooling for Vinod (and other subsystem
>> maintainers) to perform system-wide DT-validation when considering
>> merging a binding change?
> 
> This one is an ABI break because it adds new required properties. I do
> have some tooling that looks for ABI changes, but haven't committed it
> because I haven't figured out the best way to deploy it. I think for
> anything that is an ABI change, the binding and dts files need to go
> in together.
> 
> I think it is time to reconsider the default of bindings go in with
> the driver. That works okay for new bindings as long as the platform
> maintainer doesn't take .dts changes before bindings land (also an
> issue). However, for cases like this, we need the opposite order. We
> need to figure something out because this is only going to be more of
> an issue as we get to warning free (and we are close).

We have been talking about this for some time and recent consensus was
that SoC maintainers can freely take such bindings when driver subsystem
maintainers lag behind. The case here is a bit opposite - driver
subsystem was before SoC.

So let's change the generic recommendation/policy? Whenever patchset
touches bindings and DTS, and the bindings do not need any driver
updates like they add only front-specific compatibles, the SoC should
take entire set?


Best regards,
Krzysztof

Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies

[Rob Herring]

On Thu, Nov 12, 2026 at 09:13:03PM +0100, Krzysztof Kozlowski wrote:
> On 12/11/2026 20:22, Rob Herring wrote:
> > On Thu, Nov 12, 2026 at 12:30 PM Bjorn Andersson <andersson@kernel.org> wrote:
> 
> 
> (replying only to parts of the message)
> 
> 
> > 
> >>> Can the QCom folks stop doing that! Coordinate applying the series or
> >>> take the binding and dts changes in 1 tree.
> >>
> >> I assume you're referring to "QCom folks" in the sense "any maintainer
> >> touching a binding change related to a qcom platform"?
> > 
> > No, primarily you and the submitter I guess. Submitters should be
> > aware of dependencies in their series and suggest how things are
> > merged. Otherwise, it falls on you to care that warnings are getting
> > introduced.
> 
> We all have been swamped with patches and Qualcomm have been probably
> the busiest arm64 platform for months now.
> 
> for i in arch/arm64/boot/dts/* ; do echo "${i}:$(git log --no-merges
> --oneline v7.0..v7.4-rc1 -- $i | wc -l)" ; done
> 
> qcom: 1016
> freescale: 485
> renesas: 215
> 
> Qualcomm SoC got one more maintainer, so there is catching up, but
> probably not enough.

Good thing QCom hired half of Linaro...

> > I would not care so much when there are transient warnings in next,
> > but I don't want to be the one chasing them down. But AFAICT, it's
> > always me. No one beats me to it and I'm not all that fast in
> > noticing. I just compare all the warnings by platform for Linus vs.
> > next with "gl-diff-dtb-warning -p arm64" from this repo[2], and look
> > for things moving in the right direction. Of course this is all after
> > applying which isn't ideal.
> 
> FWIW, I do test all Samsung ones and I look only at some of Qualcomm
> boards, because there were just too many warnings to have a clean
> dtbs_check for qcom. I do report them to Bjorn/Konrad [1], but that's
> indeed only subset of entire qcom ecosystem. I know that a few other SoC
> platforms keep track (TI at least).

The too many warnings excuse is about to run out.

Here's Linus's tree ATM for qcom (I'd list next, but warnings have gone 
up):

     12 syscon@9a10000 (syscon): compatible: ["syscon"] has less than 2 items

https://lore.kernel.org/all/20261112-dtbs-qcom-v1-0-1978370c7cad@kernel.org/

      5 usb@6af8800 (qcom,msm8996-dwc3): Additional properties are not allowed ('extcon' was unexpected)
      2 usb@76f8800 (qcom,msm8996-dwc3): Additional properties are not allowed ('extcon' was unexpected)

In the wrong spot or needs to be added to the binding?

      2 touchscreen@2c (syna,rmi4-i2c): Unevaluated properties are not allowed ('incell-supply' was unexpected)

https://lore.kernel.org/all/20260921232738.3135429-1-robh@kernel.org/

But seems to be a hack, so?

      2 panel@0 (jdi,fhd-r63452): "power-supply" is a required property

???

      3 phy@7411000 (qcom,msm8996-qusb2-phy): "vdd-supply" is a required property
      1 qusb@59000 (qcom,ipq6018-qusb2-phy): "vdd-supply" is a required property
      1 qusb@59000 (qcom,ipq6018-qusb2-phy): "vdda-pll-supply" is a required property
      1 qusb@59000 (qcom,ipq6018-qusb2-phy): "vdda-phy-dpdm-supply" is a required property
      1 phy@79000 (qcom,ipq8074-qusb2-phy): "vdd-supply" is a required property
      1 phy@79000 (qcom,ipq8074-qusb2-phy): "vdda-pll-supply" is a required property
      1 phy@79000 (qcom,ipq8074-qusb2-phy): "vdda-phy-dpdm-supply" is a required property
      1 phy@59000 (qcom,ipq8074-qusb2-phy): "vdd-supply" is a required property
      1 phy@59000 (qcom,ipq8074-qusb2-phy): "vdda-pll-supply" is a required property
      1 phy@59000 (qcom,ipq8074-qusb2-phy): "vdda-phy-dpdm-supply" is a required property

https://lore.kernel.org/all/20261112192345.3962577-1-robh@kernel.org/

      1 panel@0 (lg,sw49410-lh609qh1): Unevaluated properties are not allowed ('reg', 'vsn-supply', 'vsp-supply' were unexpected)
      1 panel@0 (lg,sw49410-lh609qh1): "power-supply" is a required property
      1 panel@0 (lg,sw49410-lh609qh1): compatible: ["lg,sw49410-lh609qh1","lg,sw49410"] has more than 1 item
      1 panel@0 (lg,sw49410-lh609qh1): compatible:0: "lg,sw49410-lh609qh1" is not one of "ampire,am-1280800n3tzqw-t00h", "ampire,am-1280800w8tzqw-t00h" or 178 other candidates

https://lore.kernel.org/all/20260614-judyln-panel-v3-2-07f4134441bd@postmarketos.org/

      1 panel@0 (flipkart,rimob-panel-nt35532-cs): compatible: ["flipkart,rimob-panel-nt35532-cs"] has less than 2 items

Fixed in next

   Undocumented compatibles:3
     'jdi,fhd-nt35596s'

https://lore.kernel.org/all/20260921232609.3130272-1-robh@kernel.org/

But probably belongs in this:

https://lore.kernel.org/all/20261011-nt36672a-panels-v3-3-9ea238627f8a@minlexx.ru/

     'lg,sw49410-lh609qh1', 'lg,sw49410'

See above

     'qcom,ipq6018-wcss-pil'

Fixed in next


So 3 unique warnings left without fixes in flight.

> 
> [1] https://krzk.eu/#/builders/102
> 
> 
> > 
> >> Do you have some CI/guidance/tooling for Vinod (and other subsystem
> >> maintainers) to perform system-wide DT-validation when considering
> >> merging a binding change?
> > 
> > This one is an ABI break because it adds new required properties. I do
> > have some tooling that looks for ABI changes, but haven't committed it
> 
> because I haven't figured out the best way to deploy it. I think for
> > anything that is an ABI change, the binding and dts files need to go
> > in together.
> > 
> > I think it is time to reconsider the default of bindings go in with
> > the driver. That works okay for new bindings as long as the platform
> > maintainer doesn't take .dts changes before bindings land (also an
> > issue). However, for cases like this, we need the opposite order. We
> > need to figure something out because this is only going to be more of
> > an issue as we get to warning free (and we are close).
> 
> We have been talking about this for some time and recent consensus was
> that SoC maintainers can freely take such bindings when driver subsystem
> maintainers lag behind. The case here is a bit opposite - driver
> subsystem was before SoC.
> 
> So let's change the generic recommendation/policy? Whenever patchset
> touches bindings and DTS, and the bindings do not need any driver
> updates like they add only front-specific compatibles, the SoC should
> take entire set?

Yes. Platforms that are warning free already do that.

I also think we (the DT maintainers) need to get stricter on handling of 
adding or removing required properties. For adding required, delay the 
binding change a cycle (or after dts is in next). For dropping required, 
delay the dts change a cycle (or after binding is in next). That's 
probably too much for any maintainer to check other than DT maintainers. 
Or maybe add this to sashiko prompts...

Rob