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

Message-id: <56D6636F.6090403@samsung.com>
Date:	Wed, 02 Mar 2016 12:52:15 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Laxman Dewangan <ldewangan@...dia.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 02.03.2016 11:15, Laxman Dewangan wrote:
> 
> On Wednesday 02 March 2016 06:28 AM, Krzysztof Kozlowski wrote:
>> On 29.02.2016 21:58, Laxman Dewangan wrote:
>> +    .alarm_pending_status_reg = MAX77620_RTC_ALARM_PENDING_STATUS_REG,
>> Just skip the alarm_pending_status_reg (so it will be 0x0) and check for
>> non-zero value later?
>>
>> It might be a little bit non consistent approach to how we map RTC
>> registers (REG_RTC_NONE)... so I don't have strong feelings about this.
> 
> I choose -1 because 0 is also valid.
> So I can have macro for INVALID register which is -1 and use here, other
> places direct register as STATUS2.

There is only one value used here so 0 not valid. But I don't mind that
approach.

> 
> 
>>
>>> +    if (info->drv_data->rtc_irq_from_platform) {
>>> +        struct platform_device *pdev = to_platform_device(info->dev);
>>> +
>>> +        info->rtc_irq = platform_get_irq(pdev, 0);
>> It may return -ERRNO. What happens then?
> 
> MFD is initializing the irq and so it will not fail on this particular
> case.
> Even if error, the regmap_add_irq should fail.
> 
> Let me handle error at this point only to avoid any assumption and
> further processing with error, by returning error.
> 
> 
>>
>>> +    } else {
>>> +        info->rtc_irq =  parent_i2c->irq;
>>> +    }
>>>         info->regmap = dev_get_regmap(parent, NULL);
>>>       if (!info->regmap) {
>>> @@ -802,6 +840,8 @@ static SIMPLE_DEV_PM_OPS(max77686_rtc_pm_ops,
>>>   static const struct platform_device_id rtc_id[] = {
>>>       { "max77686-rtc", .driver_data =
>>> (kernel_ulong_t)&max77686_drv_data, },
>>>       { "max77802-rtc", .driver_data =
>>> (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.

For me, code like this:
{ "max77802-rtc", .driver_data = (kernel_ulong_t)&max77802_drv_data, },
{ "max77620-rtc", .driver_data = (kernel_ulong_t)&max77620_drv_data, },
{ "max77621-rtc", .driver_data = (kernel_ulong_t)&max77620_drv_data, },
{ "max77622-rtc", .driver_data = (kernel_ulong_t)&max77620_drv_data, },
{ "max77623-rtc", .driver_data = (kernel_ulong_t)&max77620_drv_data, },
{ "max776xx-some-other-rtc", .driver_data =
(kernel_ulong_t)&max77620_drv_data, },
{ "max77624-rtc", .driver_data = (kernel_ulong_t)&max77620_drv_data, },

is useless, ridiculous and obfuscated. It is duplication of code just
"because". The child driver is selected by matching mfd-cell or
compatible. We are reusing child drivers so reuse under the same name.

Best regards,
Krzysztof