linux-kernel - Re: [PATCH v3 1/2] dt-bindings: pinctrl: qcom: update compatible name for match with driver

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 13 Mar 2024 18:31:20 +0800
From: Tengfei Fan <quic_tengfan@...cinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        <andersson@...nel.org>, <konrad.dybcio@...aro.org>,
        <linus.walleij@...aro.org>, <robh@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <dmitry.baryshkov@...aro.org>
CC: <linux-arm-msm@...r.kernel.org>, <linux-gpio@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <kernel@...cinc.com>
Subject: Re: [PATCH v3 1/2] dt-bindings: pinctrl: qcom: update compatible name
 for match with driver



On 3/13/2024 5:11 PM, Krzysztof Kozlowski wrote:
> On 13/03/2024 08:55, Tengfei Fan wrote:
>>>>>>> Wasn't this applied?
>>>>>>
>>>>>> My test code base on tag: next-20240308, this patch is still not applied.
>>>>>>
>>>>>> In fact, the following dt binding check warning only can be got before
>>>>>> this patch is applied.
>>>>>>
>>>>>
>>>>> Please read all emails in the previous thread. You ignored two emails in
>>>>> the past and apparently one more recent.
>>>>
>>>> I don't know if you mean I ignored the email which related with "Patch
>>>> applied" tag from Linus Walleij. If so, the following is the reasion why
>>>> I still include this patch:
>>>
>>> Yep, that's the one. Please do not send patches which were already
>>> applied. It causes unnecessary effort on reviewer and maintainer side.
>>>
>>>>
>>>> I synced the latest upstream code on 03/12/2024, the latest tag is
>>>> next-20240308, this tag still doesn't include this patch[PATCH v3 1/2].
>>>
>>> Happens, considering Linus applied it after 8th of March, I think.
>>>
>>>>
>>>> Dt binding check still get warning if I only send [PATCH v3 2/2] patch
>>>> to upstream base on next-20240308. so I include this patch[PATCH v3 1/2]
>>>
>>> If you send patch 1+2, dt_binding_check will have exactly the same
>>> result. I don't know about what sort of dt binding check you talk, but
>>> for all cases: you changed nothing by sending these two patches in that
>>> regard. Only noise on the lists.
>>
>> The dt binding check failed which Rob Herring remind me in previous
>> patch series as the following:
> 
> This does not make any sense. Whether Rob runs his test on previous or
> future next, changes nothing in regard of this patchset being sent with
> duplicated patch or not. The result will be exactly the same for Rob.
> 
>>
>> Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.example.dtb:
>> /example-0/pinctrl@...0000: failed to match any schema with
>> compatible: ['qcom,sm4450-tlmm']
>>
>> This failed is introduced by
>> https://lore.kernel.org/linux-arm-msm/20231206020840.33228-2-quic_tengfan@quicinc.com/.
>> Something got broken aroud -m flags for dtschema, so indeed no reports
>> this unmatched compatibles warning when this patch was revriwed. We also
>> have some discusstion in patch email.
> 
> Again, not related at all whether you send patch *which was applied* or not.
> 
>>
>> The patch[PATCH v3 1/2] is made for fix this previous patch dt binding
>> check failed. So dt binding check failed will disappear after this
>> patch[PATCH v3 1/2] is applied.
> 
> And who is supposed to run that dt binding check and on what base? Your
> patch changes absolutely nothing in that regard, just creates confusion.
> 
> And the fact that you keep arguing over this simple case, reminds me
> other clueless discussions I had with some Qualcomm folks. None of the
> arguments you brought here justify sending patch which was applied.

Sending duplicated patch isn't a correct approach, I will avoid making 
similar mistakes in the future.

> 
>>
>>>
>>>> in patch series even if this patch have "Patch applied" tag.
>>>>
>>>> Looking forward to getting your advice if submitting patch series this
>>>> way is problematic.
>>>
>>> Do not send patches which are known to be applied.
>>
>> Yes, I will be careful not to resend the patch which have already been
>> applied in the future work.
> 
> Then why do you keep arguing that sending this duplicated patch was
> correct approach?
There may be some confusion here. Sending this duplicated patch isn't a 
correct approach, I will not send duplicated patch again in the future 
upstream work.

> 
>>
>> Do you think it is necessary to send another version patch series for
>> remove this applied patch[PATCH v3 1/2] from patch series?
> 
> No. It is merge window, please read process documents in Documentation
> directory. Then please read Qualcomm upstreaming guide.
> 
> Best regards,
> Krzysztof
> 

-- 
Thx and BRs,
Tengfei Fan