Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1347767

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

From Krzysztof Kozlowski <k.kozlowski@samsung.com>
Newsgroups linux.kernel
Subject Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620 RTC IP
Date 2016-03-02 05:00 +0100
Message-ID <r8678-23N-5@gated-at.bofh.it> (permalink)
References <r7vTY-3v4-15@gated-at.bofh.it> <r83iY-8oR-67@gated-at.bofh.it> <r84I3-18B-47@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620 RTC IP Laxman Dewangan <ldewangan@nvidia.com> - 2016-02-29 14:20 +0100
  [PATCH 2/2] rtc: max77686: Use REGMAP_IRQ_REG for regmap-rtc-irqs initialisation Laxman Dewangan <ldewangan@nvidia.com> - 2016-02-29 14:20 +0100
    Re: [PATCH 2/2] rtc: max77686: Use REGMAP_IRQ_REG for regmap-rtc-irqs  initialisation Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-02 02:10 +0100
      Re: [PATCH 2/2] rtc: max77686: Use REGMAP_IRQ_REG for regmap-rtc-irqs  initialisation Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-02 03:20 +0100
        Re: [PATCH 2/2] rtc: max77686: Use REGMAP_IRQ_REG for regmap-rtc-irqs  initialisation Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-02 04:50 +0100
  Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620 RTC IP Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-02 02:00 +0100
    Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620  RTC IP Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-02 03:30 +0100
      Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620 RTC IP Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-02 05:00 +0100
        Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620 RTC IP Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-02 05:30 +0100
          Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620  RTC IP Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-02 07:20 +0100
        Re: [PATCH 1/2] rtc: max77686: Add support for MAX20024/MAX77620  RTC IP Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-02 05:30 +0100

csiph-web