On 13/07/2022 17:57, Doug Anderson wrote: > Hi, > > On Tue, Jul 12, 2022 at 8:02 AM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> 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@xxxxxxxxxx> > > 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. */ ? 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. > > In any case: > > Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx> Best regards, Krzysztof