* Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies
@ 2026-11-12 19:22 ` Rob Herring
0 siblings, 0 replies; 18+ messages in thread
From: Rob Herring @ 2026-11-12 19:22 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Vinod Koul, Konrad Dybcio, Neil Armstrong, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Krzysztof Kozlowski, linux-arm-msm, linux-phy, devicetree,
linux-kernel
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies
2026-11-12 19:22 ` Rob Herring
@ 2026-11-12 20:13 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 18+ messages in thread
From: Krzysztof Kozlowski @ 2026-11-12 20:13 UTC (permalink / raw)
To: Rob Herring, Bjorn Andersson
Cc: Vinod Koul, Konrad Dybcio, Neil Armstrong, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies
@ 2026-11-12 20:13 ` Krzysztof Kozlowski
0 siblings, 0 replies; 18+ messages in thread
From: Krzysztof Kozlowski @ 2026-11-12 20:13 UTC (permalink / raw)
To: Rob Herring, Bjorn Andersson
Cc: Vinod Koul, Konrad Dybcio, Neil Armstrong, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies
2026-11-12 20:13 ` Krzysztof Kozlowski
@ 2026-11-12 21:17 ` Rob Herring
-1 siblings, 0 replies; 18+ messages in thread
From: Rob Herring @ 2026-11-12 21:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Vinod Koul, Konrad Dybcio, Neil Armstrong,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley,
Wesley Cheng, linux-arm-msm, linux-phy, devicetree, linux-kernel
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies
@ 2026-11-12 21:17 ` Rob Herring
0 siblings, 0 replies; 18+ messages in thread
From: Rob Herring @ 2026-11-12 21:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Vinod Koul, Konrad Dybcio, Neil Armstrong,
Manivannan Sadhasivam, Krzysztof Kozlowski, Conor Dooley,
Wesley Cheng, linux-arm-msm, linux-phy, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies
2026-11-12 19:22 ` Rob Herring
@ 2026-11-12 23:41 ` Bjorn Andersson
-1 siblings, 0 replies; 18+ messages in thread
From: Bjorn Andersson @ 2026-11-12 23:41 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Konrad Dybcio, Neil Armstrong, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Krzysztof Kozlowski, linux-arm-msm, linux-phy, devicetree,
linux-kernel
On Thu, Nov 12, 2026 at 01:22:16PM -0600, Rob Herring wrote:
> 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).
>
Good, then we're aligned. These 18 warnings are resolved in my tree, so
they should drop again in the next linux-next.
> > > 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 currently do catch these things while applying dts changes, and I've
recently cooked a dashboard to track the overall state of mainline and
linux-next, but I don't have any solution to catch things prior to merge
- or a good solution for catching regressions coming from binding
changes prior to them being merged.
> 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.
I'll try to wire something up to catch these faster. At least until this
regression things has been fairly stable for a while now...
> Of course this is all after applying which isn't ideal.
>
Thanks to the --cache-dir and --json support it's a bit more convenient
to catch things during the merge, but the CPU-power needed for a
system-wide sanity check remains a concern.
I would prefer to catch more issues prior to touching the patches, but
so far my efforts there has run into issues as contributors keep sending
things with loose dependencies.
> > 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.
>
After a second look, that would have made more sense, since the driver
changes wasn't related to the binding change after all...
> 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).
>
There's also the ever growing number of small incremental changes to
bindings, where subsystem maintainers leave the binding changes to me.
But then there's also the many changes where the driver patches depend
on the binding changes. Not sure how to structure this and keep the
velocity up.
> > 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
>
I'd prefer to actually populate those, I'll take another pass to see if
I can find documentation/schematics to resolve them.
Regards,
Bjorn
> Rob
>
> > > [1] https://lore.kernel.org/all/qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com
>
> [2] https://gitlab.com/robherring/ci-jobs
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2] dt-bindings: phy: qcom: Relax required supplies
@ 2026-11-12 23:41 ` Bjorn Andersson
0 siblings, 0 replies; 18+ messages in thread
From: Bjorn Andersson @ 2026-11-12 23:41 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Konrad Dybcio, Neil Armstrong, Manivannan Sadhasivam,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Krzysztof Kozlowski, linux-arm-msm, linux-phy, devicetree,
linux-kernel
On Thu, Nov 12, 2026 at 01:22:16PM -0600, Rob Herring wrote:
> 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).
>
Good, then we're aligned. These 18 warnings are resolved in my tree, so
they should drop again in the next linux-next.
> > > 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 currently do catch these things while applying dts changes, and I've
recently cooked a dashboard to track the overall state of mainline and
linux-next, but I don't have any solution to catch things prior to merge
- or a good solution for catching regressions coming from binding
changes prior to them being merged.
> 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.
I'll try to wire something up to catch these faster. At least until this
regression things has been fairly stable for a while now...
> Of course this is all after applying which isn't ideal.
>
Thanks to the --cache-dir and --json support it's a bit more convenient
to catch things during the merge, but the CPU-power needed for a
system-wide sanity check remains a concern.
I would prefer to catch more issues prior to touching the patches, but
so far my efforts there has run into issues as contributors keep sending
things with loose dependencies.
> > 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.
>
After a second look, that would have made more sense, since the driver
changes wasn't related to the binding change after all...
> 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).
>
There's also the ever growing number of small incremental changes to
bindings, where subsystem maintainers leave the binding changes to me.
But then there's also the many changes where the driver patches depend
on the binding changes. Not sure how to structure this and keep the
velocity up.
> > 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
>
I'd prefer to actually populate those, I'll take another pass to see if
I can find documentation/schematics to resolve them.
Regards,
Bjorn
> Rob
>
> > > [1] https://lore.kernel.org/all/qusb2phy-v2-1-4c3f980a4560@oss.qualcomm.com
>
> [2] https://gitlab.com/robherring/ci-jobs
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 18+ messages in thread