From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755376AbbJ1Dn0 (ORCPT ); Tue, 27 Oct 2015 23:43:26 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:60453 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755077AbbJ1DnY (ORCPT ); Tue, 27 Oct 2015 23:43:24 -0400 X-AuditID: cbfee691-f79d66d000001509-c3-5630444a3ec2 Message-id: <5630421B.5010803@samsung.com> Date: Wed, 28 Oct 2015 09:03:47 +0530 From: Alim Akhtar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-version: 1.0 To: Krzysztof Kozlowski , Mark Brown Cc: lee.jones@linaro.org, mturquette@baylibre.com, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, rtc-linux@googlegroups.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC References: <1445863883-5187-1-git-send-email-alim.akhtar@samsung.com> <1445863883-5187-6-git-send-email-alim.akhtar@samsung.com> <56302514.4090407@samsung.com> <20151028015323.GZ28319@sirena.org.uk> <56303054.8060804@samsung.com> <56303DA3.5020306@samsung.com> <5630419F.1000300@samsung.com> In-reply-to: <5630419F.1000300@samsung.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsWyRsSkRtfLxSDMoP2cqsXUh0/YLF6/MLS4 //Uoo8XHnnusFpd3zWGzmHF+H5PFxVOuFvs7OxgdODze32hl99gz8SSbx6ZVnWwed67tYfPo 27KK0ePzJrkAtigum5TUnMyy1CJ9uwSujEMf/7IV7Bas2H7zH1sD4yfeLkYODgkBE4lpP2y6 GDmBTDGJC/fWs3UxcnEICaxglOicdIUdImEisfTVcajEUkaJk0d6mSCcB4wSJ/b0M4NU8Qpo SUyed4sVxGYRUJVobr8PZrMJaEvcnb6FCWSbqECExOMLQhDlghI/Jt9jAQmLCIRI7D1hCDKS WWAto0TvoetsIDXCAn4S62c+Z4fYtYZJ4uz364wgCU6gmZ/nLge7jlnAVmLB+3UsELa8xOY1 b5lBGiQE7rFLNL3+xQhxkIDEt8mHWCBelpXYdIAZ4jNJiYMrbrBMYBSbheSmWUjGzkIydgEj 8ypG0dSC5ILipPQiU73ixNzi0rx0veT83E2MwDg8/e/ZxB2M9w9YH2IU4GBU4uE1qNALE2JN LCuuzD3EaAp0xURmKdHkfGC055XEGxqbGVmYmpgaG5lbmimJ8+pI/wwWEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwHjkzQ3nX3uE2T9NSLSs9sg+ePBod6bn9inWfydVTzx6/O7bF5fmt77R NbUqLM66v6T55imTqaf23EpUdRWMVBWMb2na3TNtX1dJoo7z3pSfwtl75YReL8h+zOaysKRj guDdJu4bkU+3qXB2uNlOkL2lUjUr7kIL3zPBxeEeSR8jxRM6JTIZTZVYijMSDbWYi4oTATdy ddC+AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsVy+t9jAV0vF4Mwg8aTUhZTHz5hs3j9wtDi /tejjBYfe+6xWlzeNYfNYsb5fUwWF0+5Wuzv7GB04PB4f6OV3WPPxJNsHptWdbJ53Lm2h82j b8sqRo/Pm+QC2KIaGG0yUhNTUosUUvOS81My89JtlbyD453jTc0MDHUNLS3MlRTyEnNTbZVc fAJ03TJzgO5RUihLzCkFCgUkFhcr6dthmhAa4qZrAdMYoesbEgTXY2SABhLWMGYc+viXrWC3 YMX2m//YGhg/8XYxcnJICJhILH11nA3CFpO4cG89kM3FISSwlFHi5JFeJgjnAaPEiT39zCBV vAJaEpPn3WIFsVkEVCWa2++D2WwC2hJ3p28BauDgEBWIkHh8QQiiXFDix+R7LCBhEYEQib0n DEFGMgusZZToPXQdbLGwgJ/E+pnP2SF2rWGSOPv9OiNIghNo5ue5y9lBbGYBW4kF79exQNjy EpvXvGWewCgwC8mOWUjKZiEpW8DIvIpRIrUguaA4KT3XKC+1XK84Mbe4NC9dLzk/dxMjONqf Se9gPLzL/RCjAAejEg+vQYVemBBrYllxZe4hRgkOZiUR3hpBgzAh3pTEyqrUovz4otKc1OJD jKbAQJjILCWanA9MRHkl8YbGJuamxqaWJhYmZpZK4rwXMjTChATSE0tSs1NTC1KLYPqYODil GhiZt0q5OPxxOl9fWK7z+eWy9vwNTmtZ3VwXB1WL/v56dWlW8pl7THPlxSTdX9n7zJl4cXLt lcMTzseWVZ2JWBy9ubrihem23VKVyfvitu5yb7jzyH5puMo6962KM6/tDncOs/D95y3/v/yK SMNt0T+HE1dlxH+MWpw7Y+eXxWc/5JZk5HnozslWYinOSDTUYi4qTgQAXv+NWQwDAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/28/2015 09:01 AM, Krzysztof Kozlowski wrote: > On 28.10.2015 12:14, Alim Akhtar wrote: >> Hello, >> >> On 10/28/2015 07:47 AM, Krzysztof Kozlowski wrote: >>> On 28.10.2015 10:53, Mark Brown wrote: >>>> On Wed, Oct 28, 2015 at 10:29:56AM +0900, Krzysztof Kozlowski wrote: >>>> >>>>> If that's true, then don't add new compatibles, new names etc. Re-use. >>>>> No new code needed, no changes needed. Keep it simple. >>>> >>>> Well, it depends - it can be useful to get the information about it >>>> being a different part into DT so that if in future we realise that >>>> there is some difference (perhaps a bug workaround even if the IP is >>>> intended to be the same). Though in the case of a MFD that information >>>> can be obtained from the MFD for the device. >>> >>> We can always differentiate later and introduce new compatible. >>> Declaring a compatible right now would be useful only if we really cared >>> about using the workaround on older DTBs. >>> >>> Since I cannot judge the difference (I don't have the datasheet of >>> S2MPS15) then I don't see the need of adding new compatible/name for the >>> "same device". >>> >>> Of course maybe there is such need? Alim? >>> >> Well I did think of keeping the changes as minimal as possible, like >> just have "{ "s2mps15-rtc", S2MPS14X }", since I don't have >> access to s2mps14 UM, I could not confirm that s2mps14 and s2mps15 are >> exactly the same w.r.t rtc block. So I proposed the current changes. >> >> Well I do agree with Mark here, a name/compatible matching with the pmic >> is good to at least avoid confusion while looking at the sysfs. > > What kind of confusion in sysfs? I don't see any... and already the > s2mps14-rtc name is used for S2MPS11 and S2MPS14. > > The s2mps13 clock driver added new name and compatible... which was > probably totally unneeded (I missed that during review). We don't have > to make this as a rule... > > Since we do not have any data about future workarounds and the > differences then just follow Ockham's razor - use the same name and > compatible. > ok, have request s2smp14 UM, will cross check and update accordingly. Thanks. > Best regards, > Krzysztof >