Message ID | 20220928-mdm9615-dt-schema-fixes-v4-8-dac2dfaac703@linaro.org (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | arm: qcom: mdm9615: first round of bindings and DT fixes | expand |
On Fri, 21 Oct 2022, Neil Armstrong wrote: > The PM8018 compatible is always used with PM8921 fallback, so PM8018 > compatible can be safely removed from device ID table > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Tags should appear chronologically. I've fixed this up and applied the patch, thanks. > --- > drivers/mfd/qcom-pm8xxx.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c > index 2f2734ba5273..601106580e2e 100644 > --- a/drivers/mfd/qcom-pm8xxx.c > +++ b/drivers/mfd/qcom-pm8xxx.c > @@ -497,7 +497,6 @@ static const struct pm_irq_data pm8821_data = { > }; > > static const struct of_device_id pm8xxx_id_table[] = { > - { .compatible = "qcom,pm8018", .data = &pm8xxx_data}, > { .compatible = "qcom,pm8058", .data = &pm8xxx_data}, > { .compatible = "qcom,pm8821", .data = &pm8821_data}, > { .compatible = "qcom,pm8921", .data = &pm8xxx_data}, >
Hi, On 31/10/2022 16:32, Lee Jones wrote: > On Fri, 21 Oct 2022, Neil Armstrong wrote: > >> The PM8018 compatible is always used with PM8921 fallback, so PM8018 >> compatible can be safely removed from device ID table >> >> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > > Tags should appear chronologically. Indeed, they were added by b4, I'll report this. Thanks, Neil > > I've fixed this up and applied the patch, thanks. > >> --- >> drivers/mfd/qcom-pm8xxx.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c >> index 2f2734ba5273..601106580e2e 100644 >> --- a/drivers/mfd/qcom-pm8xxx.c >> +++ b/drivers/mfd/qcom-pm8xxx.c >> @@ -497,7 +497,6 @@ static const struct pm_irq_data pm8821_data = { >> }; >> >> static const struct of_device_id pm8xxx_id_table[] = { >> - { .compatible = "qcom,pm8018", .data = &pm8xxx_data}, >> { .compatible = "qcom,pm8058", .data = &pm8xxx_data}, >> { .compatible = "qcom,pm8821", .data = &pm8821_data}, >> { .compatible = "qcom,pm8921", .data = &pm8xxx_data}, >> >
On 31/10/2022 11:32, Lee Jones wrote: > On Fri, 21 Oct 2022, Neil Armstrong wrote: > >> The PM8018 compatible is always used with PM8921 fallback, so PM8018 >> compatible can be safely removed from device ID table >> >> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > > Tags should appear chronologically. > I would assume that as well, but `b4 trailers` disagrees. It documents even this behavior (the chain of custody) here: https://b4.docs.kernel.org/en/latest/config.html So while I agree with you, I also prefer the tools to make the decision instead of humans (to follow the process, assuming the tool implements the process). Either the tool should be fixed or the tool's decision is correct. Best regards, Krzysztof
On Wed, 02 Nov 2022, Krzysztof Kozlowski wrote: > On 31/10/2022 11:32, Lee Jones wrote: > > On Fri, 21 Oct 2022, Neil Armstrong wrote: > > > >> The PM8018 compatible is always used with PM8921 fallback, so PM8018 > >> compatible can be safely removed from device ID table > >> > >> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > > > > Tags should appear chronologically. > > > > I would assume that as well, but `b4 trailers` disagrees. It documents > even this behavior (the chain of custody) here: > https://b4.docs.kernel.org/en/latest/config.html > > So while I agree with you, I also prefer the tools to make the decision > instead of humans (to follow the process, assuming the tool implements > the process). Either the tool should be fixed or the tool's decision is > correct. Take a look further down the thread, since this has already been heavily debated. Not sure if there has been a clear winner or any kind of agreement yet (if there ever will be), but until there is or I until I am convinced otherwise, I'm going to continue on with the chronological method. Also, as far as I'm aware, tools like `b4` and the-like haven't been mandated (yet?), so using its rules to dictate our actions probably isn't the correct approach.
diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c index 2f2734ba5273..601106580e2e 100644 --- a/drivers/mfd/qcom-pm8xxx.c +++ b/drivers/mfd/qcom-pm8xxx.c @@ -497,7 +497,6 @@ static const struct pm_irq_data pm8821_data = { }; static const struct of_device_id pm8xxx_id_table[] = { - { .compatible = "qcom,pm8018", .data = &pm8xxx_data}, { .compatible = "qcom,pm8058", .data = &pm8xxx_data}, { .compatible = "qcom,pm8821", .data = &pm8821_data}, { .compatible = "qcom,pm8921", .data = &pm8xxx_data},