Re: [PATCH 01/10] mfd/extcon: max77693: Remove unused extern declarations and max77693_dev members

[Krzysztof KozÅowski]

2015-05-04 15:54 GMT+09:00 Chanwoo Choi <cw00.choi@xxxxxxxxxxx>:
> On 05/04/2015 03:49 PM, Krzysztof KozÅowski wrote:
>> 2015-05-04 15:45 GMT+09:00 Chanwoo Choi <cw00.choi@xxxxxxxxxxx>:
>>> On 04/29/2015 07:58 PM, Krzysztof Kozlowski wrote:
>>>> Clean up the max77693 private header file by removing:
>>>> 1. Left-overs from previous way of interrupt handling (driver uses
>>>>    regmap_irq_chip).
>>>> 2. Unused members of struct 'max77693_dev' related to interrupts in
>>>>    extcon driver.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@xxxxxxxxx>
>>>> ---
>>>>  drivers/extcon/extcon-max77693.c     | 4 ----
>>>>  include/linux/mfd/max77693-private.h | 8 --------
>>>>  2 files changed, 12 deletions(-)
>>>>
>>>> diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
>>>> index a66bec8f6252..760e1e2cc1ce 100644
>>>> --- a/drivers/extcon/extcon-max77693.c
>>>> +++ b/drivers/extcon/extcon-max77693.c
>>>> @@ -1218,10 +1218,6 @@ static int max77693_muic_probe(struct platform_device *pdev)
>>>>                       irq_src = MUIC_INT3;
>>>>                       break;
>>>>               }
>>>> -
>>>> -             if (irq_src < MAX77693_IRQ_GROUP_NR)
>>>> -                     info->max77693->irq_masks_cur[irq_src]
>>>> -                             = init_data[i].data;
>>>>       }
>>>
>>> When removing the unused statement, I think you better to remove it as following:
>>> because 'enum max77693_irq_source irq_src' is not used.
>>
>> Yes, you're right. Actually some time ago I removed all of this:
>> extcon: max77693: Remove left-over code after switching to regmap irq chip
>> http://lkml.iu.edu/hypermail/linux/kernel/1410.2/03403.html
>>
>>>
>>>         for (i = 0; i < num_init_data; i++) {
>>> -               enum max77693_irq_source irq_src
>>> -                               = MAX77693_IRQ_GROUP_NR;
>>> -
>>>                 regmap_write(info->max77693->regmap_muic,
>>>                                 init_data[i].addr,
>>>                                 init_data[i].data);
>>> -
>>> -               switch (init_data[i].addr) {
>>> -               case MAX77693_MUIC_REG_INTMASK1:
>>> -                       irq_src = MUIC_INT1;
>>> -                       break;
>>> -               case MAX77693_MUIC_REG_INTMASK2:
>>> -                       irq_src = MUIC_INT2;
>>> -                       break;
>>> -               case MAX77693_MUIC_REG_INTMASK3:
>>> -                       irq_src = MUIC_INT3;
>>> -                       break;
>>> -               }
>>> -
>>> -               if (irq_src < MAX77693_IRQ_GROUP_NR)
>>> -                       info->max77693->irq_masks_cur[irq_src]
>>> -                               = init_data[i].data;
>>>         }
>>>
>>> [snip]
>>>
>>> Except for upper comment, Looks good to me.
>>
>> Okay, I'll do as you suggested and add your ack (in case it will go
>> through some other tree).
>
> I'm wondering the merge confilct if this patch will be merged on other tree.
> Because extcon-max77693.c was already modified on extcon-next branch.
>
> So, If the base commit of this patch is different, there are potential merge conflict.

Right, we can solve it by an immutable branch shared between trees. I
suspect that getting acks for whole patchset will take some time, so
the cleanups (few first patches) can be picked at beginning by
someone. Then, if needed, the maintainer can provide the branch for
other. Fortunately currently I don't see many conflicts between this
patch and extcon-next.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/