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
