From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932466AbcGOJht (ORCPT ); Fri, 15 Jul 2016 05:37:49 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:39841 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932260AbcGOJhp (ORCPT ); Fri, 15 Jul 2016 05:37:45 -0400 X-AuditID: cbfec7f5-f792a6d000001302-02-5788aee6eb03 Message-id: <5788AEE4.8080606@samsung.com> Date: Fri, 15 Jul 2016 11:37:40 +0200 From: Jacek Anaszewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-version: 1.0 To: Krzysztof Kozlowski Cc: Shuah Khan , robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, kgene@kernel.org, mchehab@osg.samsung.com, andrzej.p@samsung.com, hans.verkuil@cisco.com, javier@osg.samsung.com, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] media: Doc add missing documentation for samsung,exynos4212-jpeg References: <1468526499-8840-1-git-send-email-shuahkh@osg.samsung.com> <578890BA.8040101@samsung.com> <57889B73.4090607@samsung.com> <57889C23.3050106@samsung.com> <57889EAB.30502@samsung.com> <57889FD5.9070302@samsung.com> <5788AA5E.3070301@samsung.com> <5788AD39.1010108@samsung.com> In-reply-to: <5788AD39.1010108@samsung.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsVy+t/xa7rP1nWEG3QtYLaY9bKdxWL+kXOs Fv1vFrJaLPm5i8ni3KuVjBZv3q5hsnj9wtCi//FrZotNj6+xWlzeNYfNYsb5fUwWS69fZLJY /azCYsL0tSwWrXuPsFtM/fKBxUHAY828NYweU35vZPW43NfL5LFy+Rc2j02rOtk8Ni+p99jS f5fdo2/LKkaPz5vkAjijuGxSUnMyy1KL9O0SuDK6muYwF8wUrJjT0svSwHiLt4uRk0NCwETi 4pa37BC2mMSFe+vZuhi5OIQEljJKXG5eygSSEBJ4xihx5kAAiM0roCXx8vRjRhCbRUBVYtHE FlYQm03AUOLni9dg9aICERJ/Tu9jhagXlPgx+R4LiC0CVHNw93YmkAXMArOYJY6+28sGkhAW CJeYeP43C9RmJol/V5YygyQ4BbQl9m6YBXYes4CtxIL361ggbHmJzWveMk9gFJiFZMksJGWz kJQtYGRexSiaWppcUJyUnmukV5yYW1yal66XnJ+7iRESZV93MC49ZnWIUYCDUYmHd8eh9nAh 1sSy4srcQ4wSHMxKIryeazvChXhTEiurUovy44tKc1KLDzFKc7AoifPO3PU+REggPbEkNTs1 tSC1CCbLxMEp1cC4S+Hv7HfeKes23eZvX6jeYar2fqXl/HtakTXbVwlrro2cdtlXx7yzYlLO 2r+HIlhOzQzZGHpttvkeJbcgtVYrm/tvfiS3Wq1+XOtf5nh+62FjGWtDdnYHP5UGjt05+/r5 wjetf3f+vW43jzP70/Bvbxmc/zqe07Bjntb34n3xFGH/6wZNjw8rsRRnJBpqMRcVJwIANftm 0a4CAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/15/2016 11:30 AM, Krzysztof Kozlowski wrote: > On 07/15/2016 11:18 AM, Jacek Anaszewski wrote: >> On 07/15/2016 10:33 AM, Krzysztof Kozlowski wrote: >>> On 07/15/2016 10:28 AM, Jacek Anaszewski wrote: >>>> On 07/15/2016 10:17 AM, Krzysztof Kozlowski wrote: >>>>> On 07/15/2016 10:14 AM, Jacek Anaszewski wrote: >>>>>>> However if these compatibles are exactly equal then >>>>>>> only one should be preferred. It makes everything easier. Second >>>>>>> can be >>>>>>> still documented e.g. as deprecated. >>>>>> >>>>>> Still, both of them are present in the driver. Shouldn't it be >>>>>> reflected >>>>>> in the documentation? >>>>> >>>>> Right, it is a good practice, so how about: >>>>> >>>>> - compatible : should be one of: >>>>> "samsung,s5pv210-jpeg", "samsung,exynos3250-jpeg", >>>>> "samsung,exynos4210-jpeg", "samsung,exynos5420-jpeg", >>>>> "samsung,exynos5433-jpeg"; >>>>> >>>>> Deprecated: "samsung,exynos4212-jpeg" >>>>> >>>>> (or any other formatting) >>>>> plus update to DTS changing it to 4210? >>>> >>>> Why newer 4212 version should be made deprecated? >>> >>> I don't mind the other way. However it seems logical to me that newer >>> chip is compatible with existing one so the existing one (older) is >>> used. When adding support for new devices, for most of re-usable drivers >>> we use old compatibles. But as I said, it doesn't really matter to me. >> >> Frankly speaking marking a compatible deprecated looks weird to me. >> It can be interpreted in the way that the device itself is deprecated >> or it is not fully reliable. > > Marking a compatible or a property deprecated is commonly used, if > needed of course. It has nothing to do with device being deprecated. > This is documentation for bindings and deprecation affects only > bindings. It is not weird or something strange. We already did this for > some of Exynos compatibles (later removing them) and there are quite > many examples in Documentation already. If this is broadly accepted pattern, then I will not argue against. Let's proceed as you proposed. -- Best regards, Jacek Anaszewski