Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5efdd020-3665-810c-f62d-ed3771757ada@linaro.org>
Date:   Tue, 17 May 2022 19:08:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Subject: Re: [PATCH 00/13] dt-bindings/arm64: dts: qcom: minor cleanups with
 DT schema
Content-Language: en-US
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Andy Gross <agross@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Manu Gautam <mgautam@codeaurora.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        USB list <linux-usb@vger.kernel.org>, arm-soc <soc@kernel.org>
References: <20220504131923.214367-1-krzysztof.kozlowski@linaro.org>
 <CAMuHMdVc3kShpp8wieX1SSA8-37m8PbxpqKRs5+gxz8Dm6QwsA@mail.gmail.com>
 <3bdb65cd-cdad-6e10-c921-5ec3a9b4c9dd@linaro.org>
 <YoNxoUwjJIxyAi3l@kroah.com>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <YoNxoUwjJIxyAi3l@kroah.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 17/05/2022 11:57, Greg Kroah-Hartman wrote:
> On Tue, May 17, 2022 at 11:27:39AM +0200, Krzysztof Kozlowski wrote:
>> On 17/05/2022 11:19, Geert Uytterhoeven wrote:
>>> On Wed, May 4, 2022 at 5:13 PM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>> The patches are independent, so they can be picked up as is (or everything
>>>> through Qualcomm SoC tree).
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>> Krzysztof Kozlowski (13):
>>>>   dt-bindings: soc: qcom: aoss: document qcom,sm8450-aoss-qmp
>>>>   dt-bindings: soc: qcom: qcom,smd-rpm: add power-controller
>>>>   dt-bindings: usb: qcom,dwc3: add IPQ8074, MSM8994, QCS404 and SM6125
>>>>   dt-bindings: usb: qcom,dwc3: fix clock matching
>>>>   arm64: dts: qcom: add missing AOSS QMP compatible fallback
>>>>   arm64: dts: qcom: correct DWC3 node names and unit addresses
>>>>   arm64: dts: qcom: ipq8074: add dedicated qcom,ipq8074-dwc3 compatible
>>>>   arm64: dts: qcom: msm8994: add dedicated qcom,msm8994-dwc3 compatible
>>>>   arm64: dts: qcom: sm6125: add dedicated qcom,sm6125-dwc3 compatible
>>>>   arm64: dts: qcom: qcs404: add dedicated qcom,qcs404-dwc3 compatible
>>>>   arm64: dts: qcom: msm8996: add clock-names to DWC3 USB node
>>>>   arm64: dts: qcom: align DWC3 USB clocks with DT schema
>>>>   arm64: dts: qcom: align DWC3 USB interrupts with DT schema
>>>
>>> Looks like all but the first two were applied to usb-next by Greg,
>>> causing conflicts with the soc/for-next tree.
>>
>> Also this one was not applied:
>> arm64: dts: qcom: add missing AOSS QMP compatible fallback
>>
>> However I did not get any conflict message...
>>
>> The DTS patches should not go via Greg's tree. They are sent together so
>> there will be no warnings from Rob's bot. This is a common practice for
>> dt-binding fixes.
>>
>> Bjorn,
>> Any preference from you? Shall I send missing three patches to you?
>>
>> What about conflicts with Greg's tree?
> 
> If I need to revert anything from my tree, please let me know.  Trying
> to figure out who should, and should not, take patches like this is
> driving me crazy...

Sorry for the confusion Greg. I marked preferred merging strategy in the
cover letter. I am trying to sort it out with Bjorn. The conflict will
hit later Linus and it is auto-solvable with decent mergetool, but for a
human's eye it is a confusing diff.

Some more background:
Patches marked with "dts" prefix should always go via respective arm-soc
maintainer, not only to reduce conflicts, but also to keep hardware
description (Devicetree sources, DTS) separate from implementation.
Otherwise some folks like to combine ABI-breaking changes in drivers
together with DTS patches, so from the kernel perspective it looks like
there is no ABI breakage. But there is, just not directly visible.
Therefore arm-soc folks always insist on having DTS changes in separate
branches, so this split driver-DTS is clear.

Best regards,
Krzysztof