Date:   Mon, 19 Mar 2018 16:14:38 +0100
From:   Sylwester Nawrocki <s.nawrocki@...sung.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Sangbeom Kim <sbkim73@...sung.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        alsa-devel@...a-project.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ASoC: samsung: Mark unused Odroid compatibles as
 deprecated

On 03/19/2018 11:56 AM, Krzysztof Kozlowski wrote:
> On Mon, Mar 19, 2018 at 11:29 AM, Sylwester Nawrocki
> <s.nawrocki@...sung.com> wrote:
>> On 03/18/2018 04:35 PM, Krzysztof Kozlowski wrote:
>>> Compatible for XU4 audio is not being used.  Instead the board uses the
>>> same compatible as XU3.  The devices are now just compatible so they
>>> should use the same value.  Mark "hardkernel,odroid-xu4-audio" as being
>>> deprecated so in this future could be removed to limit useless
>>> properties.
>>
>> It doesn't feel right to obsolete the "hardkernel,odroid-xu4-audio"
>> compatible, there is significant difference between XU3 and XU4 - there
>> is no audio CODEC on XU4, this board only supports audio over HDMI interface.
>> XU4 could be compatible with XU3, but not the other way around.
>> It just happens we have other DT properties that help to handle such HW
>> design difference.
> 
> The compatible does not describe physical differences. It does not
> mean that devices are the same. In this case they are just coming from
> the same family and they operate the same, from the bindings
> perspective.

>From the ePAPR 'compatible' string definition you cited, the compatible 
string is supposed to indicate programming model of a device, for the purpose 
of matching a driver. I thought the programming model refers to the driver's
SW interfaces used to control the hardware, rather than only to a particular
DT binding design. And XU4 is not compatible with XU3 from device programming
perspective.

> The XU4 binding is not being used. Adding a compatible which is not
> used in the moment of adding is a proof that this compatible is not
> needed. It is just a duplicate. There is no point of adding
> duplicates.

I disagree it is just an unnecessary duplicate, I think dts for XU4 could
fixed instead of dropping that compatible from the binding.
>> Moreover, only XU4 is still in production and should be in few more years [1],
>> others are obsoleted now.
> 
> It is not a problem. Whether device is manufactured or not, does not
> reflect what bindings we are using. Deprecated XU4 compatible does not
> mean that XU4 itself is deprecated. Just this compatible should not be
> used for new DTS.

>> So I think we should keep at least these 2 compatible strings:
>>
>> - "hardkernel,odroid-xu3-audio" - for boards with audio CODEC,
>> - "hardkernel,odroid-xu4-audio" - for boards without audio CODEC,
>>    supporting only HDMI interface.
> 
> Yeah, and then we inflate this list into X, X2, U3, HC1 and all others
> which are the same. And then we should add XU3-lite (it is different
> device). This goes to some nonsense. Compatible is not for each device
> but for family even though there are differences between specific
> devices.

You are not listening, I refer only to major audio subsystem differences.
It would have been:

 - "hardkernel,odroid-xu3-audio" for: U2, U3, X, X2, XU, XU3, XU3-Lite
 - "hardkernel,odroid-xu4-audio" for: XU4

But if you insist on only one compatible I'm not going to argue further,
you will be responsible for this. :)  

-- 
Regards,
Sylwester

Powered by blists - more mailing lists