Update compatible name, consolidate or remove functions to match with
SM4450 driver.
Signed-off-by: Tengfei Fan <[email protected]>
---
v2 -> v3:
- update patche commit message for [PATCH v3 2/2]
- consolidate or remove some functions for match with SM4450 pinctrl
driver
v1 -> v2:
- update patches commit message
- Remove excess Spaces
previous discussion here:
[1] v2: https://lore.kernel.org/linux-arm-msm/[email protected]/
[2] v1: https://lore.kernel.org/linux-arm-msm/[email protected]/
Tengfei Fan (2):
dt-bindings: pinctrl: qcom: update compatible name for match with
driver
dt-bindings: pinctrl: qcom: update functions to match with driver
.../bindings/pinctrl/qcom,sm4450-tlmm.yaml | 54 +++++++------------
1 file changed, 19 insertions(+), 35 deletions(-)
base-commit: 8ffc8b1bbd505e27e2c8439d326b6059c906c9dd
--
2.17.1
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 <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Tengfei Fan <[email protected]>
---
Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
index bb08ca5a1509..bb675c8ec220 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
@@ -17,7 +17,7 @@ allOf:
properties:
compatible:
- const: qcom,sm4450-pinctrl
+ const: qcom,sm4450-tlmm
reg:
maxItems: 1
--
2.17.1
Some functions were consolidated in the SM4450 pinctrl driver, but they
had not been updated in the binding file before the previous SM4450
pinctrl patch series was merged.
Update functions in this binding file to match with SM4450 pinctrl
driver. Some functions need to be consolidated and some functions need
to be removed.
The following functions are removed:
- atest_char0, atest_char1, atest_char2, atest_char3
- atest_usb00, atest_usb01, atest_usb02, atest_usb03
- audio_ref
- cci_async
- cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4
- cmu_rng0, cmu_rng1, cmu_rng2, cmu_rng3
- coex_uart1
- cri_trng0, cri_trng1
- dbg_out
- ddr_pxi0, ddr_pxi1
- dp0_hot
- gcc_gp1, gcc_gp2, gcc_gp3
- ibi_i3c
- jitter_bist
- mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3
- mi2s0_data0, mi2s0_data1, mi2s0_sck, mi2s0_ws, mi2s2_data0,
mi2s2_data1, mi2s2_sck, mi2s2_ws, mi2s_mclk0, mi2s_mclk1
- nav_gpio0, nav_gpio1, nav_gpio2
- phase_flag0, phase_flag1, phase_flag10, phase_flag11, phase_flag12,
phase_flag13, phase_flag14, phase_flag15, phase_flag16,
phase_flag17, phase_flag18, phase_flag19, phase_flag2, phase_flag20,
phase_flag21, phase_flag22, phase_flag23, phase_flag24,
phase_flag25, phase_flag26, phase_flag27, phase_flag28,
phase_flag29, phase_flag3, phase_flag30, phase_flag31, phase_flag4,
phase_flag5, phase_flag6, phase_flag7, phase_flag8, phase_flag9
- pll_bist, pll_clk
- prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3
- qdss_gpio0, qdss_gpio1, qdss_gpio10, qdss_gpio11, qdss_gpio12,
qdss_gpio13, qdss_gpio14, qdss_gpio15, qdss_gpio2, qdss_gpio3,
qdss_gpio4, qdss_gpio5, qdss_gpio6, qdss_gpio7, qdss_gpio8,
qdss_gpio9
- qlink0_wmss
- qup0_se5, qup0_se6, qup0_se7, qup1_se5, qup1_se6
- sd_write
- tb_trig
- tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3
- tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3
- tsense_pwm1, tsense_pwm2
- uim0_clk, uim0_data, uim0_present, uim0_reset, uim1_clk, uim1_data,
uim1_present, uim1_reset
- usb0_hs, usb0_phy
- vsense_trigger
The following functions are added:
- atest_char
- atest_usb0
- audio_ref_clk
- cci
- cci_async_in0
- cmu_rng
- coex_uart1_rx, coex_uart1_tx
- dbg_out_clk
- ddr_pxi0_test, ddr_pxi1_test
- gcc_gp1_clk, gcc_gp2_clk, gcc_gp3_clk
- ibi_i3c_qup0, ibi_i3c_qup1
- jitter_bist_ref
- mdp_vsync
- nav
- phase_flag
- pll_bist_sync, pll_clk_aux
- prng_rosc
- qlink0_wmss_reset
- sd_write_protect
- tb_trig_sdc1, tb_trig_sdc2
- tgu_ch0_trigout, tgu_ch1_trigout, tgu_ch2_trigout, tgu_ch3_trigout
- tmess_prng
- tsense_pwm1_out, tsense_pwm2_out
- uim0, uim1
- usb0_hs_ac, usb0_phy_ps
- vsense_trigger_mirnat
- wlan1_adc_dtest0, wlan1_adc_dtest1
Fixes: 7bf8b78f86db ("dt-bindings: pinctrl: qcom: Add SM4450 pinctrl")
Signed-off-by: Tengfei Fan <[email protected]>
---
.../bindings/pinctrl/qcom,sm4450-tlmm.yaml | 52 +++++++------------
1 file changed, 18 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
index bb675c8ec220..1b941b276b3f 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
@@ -72,40 +72,24 @@ $defs:
description:
Specify the alternative function to be configured for the specified
pins.
- enum: [ gpio, atest_char, atest_char0, atest_char1, atest_char2,
- atest_char3, atest_usb0, atest_usb00, atest_usb01, atest_usb02,
- atest_usb03, audio_ref, cam_mclk, cci_async, cci_i2c,
- cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
- cmu_rng0, cmu_rng1, cmu_rng2, cmu_rng3, coex_uart1, cri_trng,
- cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
- dp0_hot, gcc_gp1, gcc_gp2, gcc_gp3, host2wlan_sol, ibi_i3c,
- jitter_bist, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2,
- mdp_vsync3, mi2s0_data0, mi2s0_data1, mi2s0_sck, mi2s0_ws,
- mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, mi2s_mclk0,
- mi2s_mclk1, nav_gpio0, nav_gpio1, nav_gpio2, pcie0_clk,
- phase_flag0, phase_flag1, phase_flag10, phase_flag11,
- phase_flag12, phase_flag13, phase_flag14, phase_flag15,
- phase_flag16, phase_flag17, phase_flag18, phase_flag19,
- phase_flag2, phase_flag20, phase_flag21, phase_flag22,
- phase_flag23, phase_flag24, phase_flag25, phase_flag26,
- phase_flag27, phase_flag28, phase_flag29, phase_flag3,
- phase_flag30, phase_flag31, phase_flag4, phase_flag5,
- phase_flag6, phase_flag7, phase_flag8, phase_flag9,
- pll_bist, pll_clk, prng_rosc0, prng_rosc1, prng_rosc2,
- prng_rosc3, qdss_cti, qdss_gpio, qdss_gpio0, qdss_gpio1,
- qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13, qdss_gpio14,
- qdss_gpio15, qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5,
- qdss_gpio6, qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink0_enable,
- qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request,
- qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss,
- qup0_se0, qup0_se1, qup0_se2, qup0_se3, qup0_se4, qup0_se5,
- qup0_se6, qup0_se7, qup1_se0, qup1_se1, qup1_se2, qup1_se3,
- qup1_se4, qup1_se5, qup1_se6, sd_write, tb_trig, tgu_ch0,
- tgu_ch1, tgu_ch2, tgu_ch3, tmess_prng0, tmess_prng1,
- tmess_prng2, tmess_prng3, tsense_pwm1, tsense_pwm2, uim0_clk,
- uim0_data, uim0_present, uim0_reset, uim1_clk, uim1_data,
- uim1_present, uim1_reset, usb0_hs, usb0_phy, vfr_0, vfr_1,
- vsense_trigger ]
+ enum: [ gpio, atest_char, atest_usb0, audio_ref_clk, cam_mclk,
+ cci_async_in0, cci_i2c, cci, cmu_rng, coex_uart1_rx,
+ coex_uart1_tx, cri_trng, dbg_out_clk, ddr_bist,
+ ddr_pxi0_test, ddr_pxi1_test, gcc_gp1_clk, gcc_gp2_clk,
+ gcc_gp3_clk, host2wlan_sol, ibi_i3c_qup0, ibi_i3c_qup1,
+ jitter_bist_ref, mdp_vsync0_out, mdp_vsync1_out,
+ mdp_vsync2_out, mdp_vsync3_out, mdp_vsync, nav,
+ pcie0_clk_req, phase_flag, pll_bist_sync, pll_clk_aux,
+ prng_rosc, qdss_cti_trig0, qdss_cti_trig1, qdss_gpio,
+ qlink0_enable, qlink0_request, qlink0_wmss_reset,
+ qup0_se0, qup0_se1, qup0_se2, qup0_se3, qup0_se4,
+ qup1_se0, qup1_se1, qup1_se2, qup1_se2_l2, qup1_se3,
+ qup1_se4, sd_write_protect, tb_trig_sdc1, tb_trig_sdc2,
+ tgu_ch0_trigout, tgu_ch1_trigout, tgu_ch2_trigout,
+ tgu_ch3_trigout, tmess_prng, tsense_pwm1_out,
+ tsense_pwm2_out, uim0, uim1, usb0_hs_ac, usb0_phy_ps,
+ vfr_0_mira, vfr_0_mirb, vfr_1, vsense_trigger_mirnat,
+ wlan1_adc_dtest0, wlan1_adc_dtest1 ]
required:
- pins
--
2.17.1
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 <[email protected]>
> Reviewed-by: Krzysztof Kozlowski <[email protected]>
> Signed-off-by: Tengfei Fan <[email protected]>
> ---
> Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Wasn't this applied?
Best regards,
Krzysztof
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 <[email protected]>
>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>> Signed-off-by: Tengfei Fan <[email protected]>
>> ---
>> 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.
Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.example.dtb:
/example-0/pinctrl@f100000: failed to match any schema with
compatible: ['qcom,sm4450-tlmm']
>
> Best regards,
> Krzysztof
>
--
Thx and BRs,
Tengfei Fan
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 <[email protected]>
>>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>>> Signed-off-by: Tengfei Fan <[email protected]>
>>> ---
>>> 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.
Best regards,
Krzysztof
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 <[email protected]>
>>>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>> ---
>>>> 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:
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].
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]
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.
Thank Krzysztof again for your patient and kind review this patch series!
>
> Best regards,
> Krzysztof
>
--
Thx and BRs,
Tengfei Fan
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 <[email protected]>
>>>>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>>> ---
>>>>> 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.
> 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.
Best regards,
Krzysztof
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 <[email protected]>
>>>>>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>>>>>> Signed-off-by: Tengfei Fan <[email protected]>
>>>>>> ---
>>>>>> 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@f100000: failed to match any schema with
compatible: ['qcom,sm4450-tlmm']
This failed is introduced by
https://lore.kernel.org/linux-arm-msm/[email protected]/.
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
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@f100000: failed to match any schema with
> compatible: ['qcom,sm4450-tlmm']
>
> This failed is introduced by
> https://lore.kernel.org/linux-arm-msm/[email protected]/.
> 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.
>
>>
>>> 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?
>
> 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
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@f100000: failed to match any schema with
>> compatible: ['qcom,sm4450-tlmm']
>>
>> This failed is introduced by
>> https://lore.kernel.org/linux-arm-msm/[email protected]/.
>> 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
On 12/03/2024 03:58, Tengfei Fan wrote:
> Some functions were consolidated in the SM4450 pinctrl driver, but they
> had not been updated in the binding file before the previous SM4450
> pinctrl patch series was merged.
> Update functions in this binding file to match with SM4450 pinctrl
> driver. Some functions need to be consolidated and some functions need
> to be removed.
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On Tue, Mar 12, 2024 at 3:59 AM Tengfei Fan <[email protected]> wrote:
> Some functions were consolidated in the SM4450 pinctrl driver, but they
> had not been updated in the binding file before the previous SM4450
> pinctrl patch series was merged.
(...)
> Fixes: 7bf8b78f86db ("dt-bindings: pinctrl: qcom: Add SM4450 pinctrl")
> Signed-off-by: Tengfei Fan <[email protected]>
Patch applied.
Yours,
Linus Walleij