[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebafbfd1-cd5a-2ef8-a0ee-685c67235816@linaro.org>
Date: Wed, 11 Jan 2023 09:16:15 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Marijn Suijten <marijn.suijten@...ainline.org>,
Andy Gross <agross@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: arm: qcom: add board-id/msm-id for MSM8956,
SDM636 and SM4250
On 11/01/2023 05:30, Bjorn Andersson wrote:
> On Wed, Dec 14, 2022 at 05:45:49PM +0100, Krzysztof Kozlowski wrote:
>> On 14/12/2022 16:29, Marijn Suijten wrote:
>>> On 2022-12-14 16:06:05, Krzysztof Kozlowski wrote:
>>>> Allow qcom,board-id and qcom,msm-id leagcy properties on these older
>>>> platforms: MSM8956, SDM636 and SM4250. Also mention more OnePlus
>>>> devices using modified qcom,board-id field.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>>
>>> Reviewed-by: Marijn Suijten <marijn.suijten@...ainline.org>
>>>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> index d45e2129fce3..cfb7f5caf606 100644
>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> @@ -925,15 +925,18 @@ allOf:
>>>> - qcom,apq8026
>>>> - qcom,apq8094
>>>> - qcom,apq8096
>>>> + - qcom,msm8956
>>>
>>> I am certain this (and msm8976) were added in [1] but it somehow got
>>> lost when that was merged as 05c0c38dc752 ("dt-bindings: arm: qcom:
>>> Document msm8956 and msm8976 SoC and devices")?
>>>
>>> Should we also add qcom,msm8976 or only when a user for that board is
>>> added?
>>
>> Bjorn,
>> You need to fix your scripts. It's not the first time when applied patch
>> is changed and its pieces are gone.
>>
>
> I don't have any script that automagically solves merge conflicts, so if
> you prefer to avoid the occasional mistake I can start reject your
> patches as soon as they don't apply 100% cleanly.
I vote for this (unless for really trivial cases). The submitter should
know better how to resolve the conflict (through rebase) than you.
Best regards,
Krzysztof
Powered by blists - more mailing lists