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@xxxxxxxxxx> 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
