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

[Krzysztof Kozlowski <krzk@kernel.org>]

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