Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <8d22cd2c-a0d1-757d-0723-cd96f582f408@linaro.org>
Date:   Mon, 9 Jan 2023 10:14:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH] dt-bindings: mmc: fsl-imx-esdhc: allow more compatible
 combinations
Content-Language: en-US
To:     Andreas Kemnade <andreas@kemnade.info>
Cc:     ulf.hansson@linaro.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
        s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
        linux-imx@nxp.com, linux-mmc@vger.kernel.org,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org
References: <20230105213856.1828360-1-andreas@kemnade.info>
 <d7c407dc-0a6c-97d5-a06f-b432a923d74d@linaro.org>
 <20230106203358.14878660@aktux>
 <967cc7b7-f0bb-de37-52b9-7bfab05eadd7@linaro.org>
 <20230107144336.2ecff4f9@aktux>
 <123d1a56-8134-dc75-8b2a-b3836e727d4a@linaro.org>
 <20230107150740.0ba34aa1@aktux>
 <0ab84fb8-6173-54e0-abad-a0e0e4ba82e7@linaro.org>
 <20230107160105.66df4136@aktux>
 <e1b1450b-9421-3732-2d74-50c47b5afb0e@linaro.org>
 <20230107165457.30f4dddf@aktux>
 <70474070-404b-2fbe-2575-4810f6fbda91@linaro.org>
 <20230108182049.679de9f9@aktux>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <20230108182049.679de9f9@aktux>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 08/01/2023 18:20, Andreas Kemnade wrote:
>>>>
>>>> No, half compatible is the A in such case.
>>>>  
>>> I think that there is some misunderstanding in here. I try once again.
>>>
>>> Define compatible with "X" here:
>>> To me it means:
>>>
>>> device fully works with flags defined in:
>>>
>>> static const struct esdhc_soc_data usdhc_X_data = { ... };
>>>
>>> with usdhc_X_data referenced in
>>>         { .compatible = "X", .data = &usdhc_X_data, },
>>>
>>>
>>> So if there is only "A" matching with above definition of compatibility
>>>   compatible = "A" would sound sane to me.
>>>
>>> And scrutinizing the flags more and not just wanting to achieve error-free
>>> dtbs_check, I think is this in most cases where there is only "A". 
>>>
>>> If there is "A" and "B" which match that compatibility definition, you
>>> say that only compatible = "A", "B" is allowed, but not compatible = "A".
>>> In that case I would have no problem with that.
>>>
>>> But if there is only "A" but no "B" matching the above definition, I would expect
>>> that only compatible = "A" is allowed but *not* compatible = "A", "B".  
>>
>> Sorry, I don't follow. I also do not understand what "matching" means in
>> these terms (binding driver? of_match?) and also I do not know what is
>> the "above definition".
>>
>> Devicetree spec defines the compatibility - so this is the definition.
>> There will be differences when applying it to different cases.
>>
> Ok, lets stop talking about A and B, lets be more specific.
> Hmm, I try to insert the missing bits here:
> 
> I am not convinced anymore that my patch is correct
> - for dtb compatible formality
> - for pure technical reasons
> 
> I am not convinced that your proposal is correct either.
> - for pure technical reasons (for same resan as you state)
> 
> Especially this part I consider faulty:
> +      - items:
> +          - const: fsl,imx6sx-usdhc
> +          - const: fsl,imx6sl-usdhc
> 
> Keyword: ESDHC_FLAG_STATE_LOST_IN_LPMODE (detailed that in
> an earlier mail).

I am not discussing here real compatibility for your hardware, as I
don't know whether 6SX is or is not compatible with 6SL. I am saying
that it either is or is not. Cannot be both at the same time.

Now for the question about 6SX+6SL. Rob responded here detailing when
compatibility of SX and SL is valid. If your hardware fits this case,
then remove the alone SX from enum and add SX+SL list like in this patch.

If your hardware does not fit, so there is no single 6SX client which
can use 6SL compatible and work somehow (e.g. half-speed, reduced
capabilities but still work correctly), then please bring back the DTS
patches. I am not sure if other people who commented on DTS, are
following our discussion here...

Best regards,
Krzysztof