Re: [PATCH v1 1/2] ASoC: dt-bindings: qcom,sm8250: Add QCS8300 sound card

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 9/10/25 11:43 AM, 'Krzysztof Kozlowski' via kernel wrote:
> On 10/09/2025 10:05, Mohammad Rafi Shaik wrote:
>>
>>
>> On 9/10/2025 1:09 PM, Krzysztof Kozlowski wrote:
>>> On 10/09/2025 09:26, Krzysztof Kozlowski wrote:
>>>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
>>>>> index 8ac91625dce5..eebf80c1d79a 100644
>>>>> --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
>>>>> +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
>>>>> @@ -35,6 +35,7 @@ properties:
>>>>>             - qcom,qcm6490-idp-sndcard
>>>>>             - qcom,qcs6490-rb3gen2-sndcard
>>>>>             - qcom,qcs8275-sndcard
>>>>
>>>> So what is the point of this compatible? There is no user of it and I
>>>> think you added QCS8275 for this case exactly...
>>>>
>>>> Shall I start reverting commits from Qualcomm because you post patches
>>>> "just in case" and turns out they are completely not needed? No single
>>>> user of such code?
>>>
>>>
>>> @Mark,
>>>
>>> In case it wasn't obvious, please do not merge the patch till we get
>>> some clarification. For sure it is wrong one way or another: either
>>> incomplete or just duplicated.
>>>
>>
>> The device tree currently uses qcs8275 as the sound compatible, and
>> the corresponding Device tree changes have already been applied and merged.
>>
>> Reverting this now would break the ABI.
> 
> If reverting would break ABI then:
> 
>>
>> A new device tree patch with qcs8300 is currently under review:
>>
>> https://lore.kernel.org/linux-arm-msm/20250910044512.1369640-1-mohammad.rafi.shaik@oss.qualcomm.com/
> 
> This is ABI break thus NAK.
> 
>>
>> Once the machine driver and device tree patch with qcs8300 are accepted 
>> and merged,
>>
>> I will promptly submit a cleanup patch to remove of discontinued 
>> compatibles from the machine driver.
> 
> So this is the same hardware? Then no, we do not rename compatibles.

The QCS8275 compatible snuck in before we concluded the pathway of
renaming the SoC to reflect its actual name..

In this case, I think we'll just have to eat the cost and go with the
existing compatible, because it's simply cosmetic.

That said.. I'm a little confused why we're accepting SoC-compatibles
as well as board-compatibles for soundcards (e.g. rb2, rb3gen2,
6940idp) in parallel.. is it with an intention that the SoC one is
present in reference designs and therefore will be common?

Konrad