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

[Rob Herring <robh@kernel.org>]

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