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 15:55:38 +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 3:23 PM, Krzysztof Kozlowski wrote:
> On 13/03/2024 02:30, Tengfei Fan wrote:
>>
>>
>> On 3/12/2024 6:55 PM, Krzysztof Kozlowski wrote:
>>> On 12/03/2024 08:47, Tengfei Fan wrote:
>>>>
>>>>
>>>> On 3/12/2024 3:41 PM, Krzysztof Kozlowski wrote:
>>>>> On 12/03/2024 03:58, Tengfei Fan wrote:
>>>>>> Use compatible name "qcom,sm4450-tlmm" instead of "qcom,sm4450-pinctrl"
>>>>>> to match the compatible name in sm4450 pinctrl driver.
>>>>>>
>>>>>> Fixes: 7bf8b78f86db ("dt-bindings: pinctrl: qcom: Add SM4450 pinctrl")
>>>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>>>>> Signed-off-by: Tengfei Fan <quic_tengfan@...cinc.com>
>>>>>> ---
>>>>>>     Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> 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:

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.

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.

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

Do you think it is necessary to send another version patch series for 
remove this applied patch[PATCH v3 1/2] from patch series?

> 
> Best regards,
> Krzysztof
> 

-- 
Thx and BRs,
Tengfei Fan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ