Re: [PATCH v2 3/3] mmc: sdhci-msm: drop redundant of_device_id entries

[Krzysztof Kozlowski]

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