linux-kernel - Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620 RTC IP

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] [day] [month] [year] [list]

Date:	Wed, 2 Mar 2016 11:31:24 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	<alexandre.belloni@...e-electrons.com>, <a.zummo@...ertech.it>
CC:	<cw00.choi@...sung.com>, <rtc-linux@...glegroups.com>,
	<linux-kernel@...r.kernel.org>, <javier@....samsung.com>,
	<rklein@...dia.com>
Subject: Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620
 RTC IP


On Wednesday 02 March 2016 09:58 AM, Krzysztof Kozlowski wrote:
> On 02.03.2016 13:10, Laxman Dewangan wrote:
>> On Wednesday 02 March 2016 09:22 AM, Krzysztof Kozlowski wrote:
>>> On 02.03.2016 11:15, Laxman Dewangan wrote:
>>>
>>>>>> (kernel_ulong_t)&max77802_drv_data, },
>>>>>> +    { "max77620-rtc", .driver_data =
>>>>>> (kernel_ulong_t)&max77620_drv_data, },
>>>>>> +    { "max20024-rtc", .driver_data =
>>>>>> (kernel_ulong_t)&max77620_drv_data, },
>>>>> There shouldn't be "max20024-rtc". This is exactly the same as
>>>>> "max77620-rtc" so re-use existing id. No point of duplicating device
>>>>> names for 100% compatible devices.
>>>>>
>>>>>
>>>> I am thinking that having compatible for each device which it supports
>>>> is better.
>>>>
>>>> In MFD, I have made all sub module of max20024 as max20024-<module>.
>>>> I have not mixed the sub module name for max20024 with max77620 module.
>>> The point of compatible is to be... compatible so you don't create
>>> compatibles for the same meaning!
>>>
>>> However this is actually not a compatible but a matching name... which
>>> should follow the same idea. You did not give any argument why this is
>>> better.
>> My point is that if any driver supporting the any devices then it should
>> be there in their compatibility although other everything is same.
> Nope. The driver can describe supported devices in comment, Kconfig,
> module description, DT binding description but the compatible is one.
> One compatible for all compatible devices.

OK, got it.

>
>> This way, it is easy to find that the driver is available for the device
>> or not. Also easy way to tell that someone has invested time to find out
>> the driver corresponding to device and he confirmed that this driver is
>> compatible with that device.
>> Otherwise, it is difficult to quickly find out the driver whether this
>> is available/support or not for given device.
> This is so specific, imaginated use case... Regular users don't write
> DTS. This is strictly for developers and the engineer who develops
> code/platforms using maxim devices has this problem? No way...

It is generic and not very specific to Maxim.
As you suggested above, we can mention the same information in other places.


Will respin the patch to remove this extra compatibility.