Re: [PATCH v2] ASoC: samsung: Mark unused Odroid compatibles as deprecated

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/19/2018 11:56 AM, Krzysztof Kozlowski wrote:
> On Mon, Mar 19, 2018 at 11:29 AM, Sylwester Nawrocki
> <s.nawrocki@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux