| Message ID | 20220712150219.20539-4-krzysztof.kozlowski@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | dt-bindings: mmc: / ARM: qcom: add MSM8998 and cleanup driver of_device_id | expand |
Hi, On Tue, Jul 12, 2022 at 8:02 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > This reverts three commits: > 1. Revert "mmc: sdhci-msm: Add compatible string check for sdx65" > This reverts commit 953706844f0f2fd4dc6984cc010fe6cf51c041f2. > > 2. Revert "mmc: sdhci-msm: Add compatible string check for sm8150" > This reverts commit 5acd6adb65802cc6f9986be3750179a820580d37. > > 3. Revert "mmc: sdhci-msm: Add SoC specific compatibles" > This reverts commit 466614a9765c6fb67e1464d0a3f1261db903834b. > > The oldest commit 466614a9765c ("mmc: sdhci-msm: Add SoC specific > compatibles") did not specify what benefits such multiple compatibles > bring, therefore assume there is none. On the other hand such approach > brings a lot of churn to driver maintenance by expecting commit for > every new compatible, even though it is already covered by the fallback. > > There is really no sense in duplicating of_device_id for each > variant, which is already covered by generic compatible fallback > qcom,sdhci-msm-v4 or qcom,sdhci-msm-v5. > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Personally, I would have taken the extra step and added a comment in the code to prevent someone from doing this again. Maybe like this: /* * In the device tree, all boards are required to have _two_ compatible * strings listed: a SoC-specific one followed by a more generic one. * Normally we can just rely on the generic string, but we always * include both so that if we ever find a bug on a specific SoC that * we need to workaround (like in sdm845/sc7180) that we can quickly * work around it without any changes to the dts. */ In any case: Reviewed-by: Douglas Anderson <dianders@chromium.org>
Hi, On Wed, Jul 13, 2022 at 9:07 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 13/07/2022 17:57, Doug Anderson wrote: > > Hi, > > > > On Tue, Jul 12, 2022 at 8:02 AM Krzysztof Kozlowski > > <krzysztof.kozlowski@linaro.org> wrote: > >> > >> This reverts three commits: > >> 1. Revert "mmc: sdhci-msm: Add compatible string check for sdx65" > >> This reverts commit 953706844f0f2fd4dc6984cc010fe6cf51c041f2. > >> > >> 2. Revert "mmc: sdhci-msm: Add compatible string check for sm8150" > >> This reverts commit 5acd6adb65802cc6f9986be3750179a820580d37. > >> > >> 3. Revert "mmc: sdhci-msm: Add SoC specific compatibles" > >> This reverts commit 466614a9765c6fb67e1464d0a3f1261db903834b. > >> > >> The oldest commit 466614a9765c ("mmc: sdhci-msm: Add SoC specific > >> compatibles") did not specify what benefits such multiple compatibles > >> bring, therefore assume there is none. On the other hand such approach > >> brings a lot of churn to driver maintenance by expecting commit for > >> every new compatible, even though it is already covered by the fallback. > >> > >> There is really no sense in duplicating of_device_id for each > >> variant, which is already covered by generic compatible fallback > >> qcom,sdhci-msm-v4 or qcom,sdhci-msm-v5. > >> > >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > Personally, I would have taken the extra step and added a comment in > > the code to prevent someone from doing this again. Maybe like this: > > > > /* > > * In the device tree, all boards are required to have _two_ compatible > > * strings listed: a SoC-specific one followed by a more generic one. > > * Normally we can just rely on the generic string, but we always > > * include both so that if we ever find a bug on a specific SoC that > > * we need to workaround (like in sdm845/sc7180) that we can quickly > > * work around it without any changes to the dts. > > */ > > This actually does not instruct the developer not to add new variants to > the driver, so how about something like: > > /* Do not add new variants to the driver which are compatible with > generic ones, unless they need customization. */ > ? Sure, that would be fine. > The problem is that this applies to several such drivers on several > platforms (Qualcomm, NXP - these for sure use such pattern), so we would > be documenting something obvious, IMO. The problem is that the people adding to this file are probably not device tree experts and may not know, so a short comment might be worthwhile. If you don't think it's a good idea, though, I won't push. -Doug
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index e395411fb6fd..ff9f5b63c337 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -2435,33 +2435,8 @@ static const struct sdhci_msm_variant_info sdm845_sdhci_var = { }; static const struct of_device_id sdhci_msm_dt_match[] = { - /* Following two entries are deprecated (kept only for backward compatibility) */ {.compatible = "qcom,sdhci-msm-v4", .data = &sdhci_msm_mci_var}, {.compatible = "qcom,sdhci-msm-v5", .data = &sdhci_msm_v5_var}, - /* Add entries for sdcc versions less than 5.0 here */ - {.compatible = "qcom,apq8084-sdhci", .data = &sdhci_msm_mci_var}, - {.compatible = "qcom,msm8226-sdhci", .data = &sdhci_msm_mci_var}, - {.compatible = "qcom,msm8916-sdhci", .data = &sdhci_msm_mci_var}, - {.compatible = "qcom,msm8953-sdhci", .data = &sdhci_msm_mci_var}, - {.compatible = "qcom,msm8974-sdhci", .data = &sdhci_msm_mci_var}, - {.compatible = "qcom,msm8992-sdhci", .data = &sdhci_msm_mci_var}, - {.compatible = "qcom,msm8994-sdhci", .data = &sdhci_msm_mci_var}, - {.compatible = "qcom,msm8996-sdhci", .data = &sdhci_msm_mci_var}, - /* - * Add entries for sdcc version 5.0 here. For SDCC version 5.0.0, - * MCI registers are removed from SDCC interface and some registers - * are moved to HC. - */ - {.compatible = "qcom,qcs404-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sdx55-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sdx65-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sdm630-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sm6125-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sm6350-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sm8150-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sm8250-sdhci", .data = &sdhci_msm_v5_var}, - {.compatible = "qcom,sc7280-sdhci", .data = &sdhci_msm_v5_var}, - /* Add entries where soc specific handling is required, here */ {.compatible = "qcom,sdm845-sdhci", .data = &sdm845_sdhci_var}, {.compatible = "qcom,sc7180-sdhci", .data = &sdm845_sdhci_var}, {},
This reverts three commits: 1. Revert "mmc: sdhci-msm: Add compatible string check for sdx65" This reverts commit 953706844f0f2fd4dc6984cc010fe6cf51c041f2. 2. Revert "mmc: sdhci-msm: Add compatible string check for sm8150" This reverts commit 5acd6adb65802cc6f9986be3750179a820580d37. 3. Revert "mmc: sdhci-msm: Add SoC specific compatibles" This reverts commit 466614a9765c6fb67e1464d0a3f1261db903834b. The oldest commit 466614a9765c ("mmc: sdhci-msm: Add SoC specific compatibles") did not specify what benefits such multiple compatibles bring, therefore assume there is none. On the other hand such approach brings a lot of churn to driver maintenance by expecting commit for every new compatible, even though it is already covered by the fallback. There is really no sense in duplicating of_device_id for each variant, which is already covered by generic compatible fallback qcom,sdhci-msm-v4 or qcom,sdhci-msm-v5. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- Cc: Konrad Dybcio <konrad.dybcio@somainline.org> Cc: Bhupesh Sharma <bhupesh.sharma@linaro.org> Cc: Doug Anderson <dianders@chromium.org> --- drivers/mmc/host/sdhci-msm.c | 25 ------------------------- 1 file changed, 25 deletions(-)