linux-kernel - Re: [PATCH 00/13] dt-bindings/arm64: dts: qcom: minor cleanups with DT schema

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 17 May 2022 19:08:22 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Manu Gautam <mgautam@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>, arm-soc <soc@...nel.org>
Subject: Re: [PATCH 00/13] dt-bindings/arm64: dts: qcom: minor cleanups with
 DT schema

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@...aro.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