linux-kernel - Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <5630421B.5010803@samsung.com>
Date:	Wed, 28 Oct 2015 09:03:47 +0530
From:	Alim Akhtar <alim.akhtar@...sung.com>
To:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Mark Brown <broonie@...nel.org>
Cc:	lee.jones@...aro.org, mturquette@...libre.com,
	linux-samsung-soc@...r.kernel.org, linux-clk@...r.kernel.org,
	rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC



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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/