From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755651AbcBCNYp (ORCPT ); Wed, 3 Feb 2016 08:24:45 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:19557 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755127AbcBCNYn (ORCPT ); Wed, 3 Feb 2016 08:24:43 -0500 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Wed, 03 Feb 2016 05:24:42 -0800 Message-ID: <56B1FCF3.2040307@nvidia.com> Date: Wed, 3 Feb 2016 18:43:23 +0530 From: Laxman Dewangan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Krzysztof Kozlowski , , , CC: , , Subject: Re: [PATCH V2 5/5] rtc: max77686: move initialisation of rtc regmap, irq chip locally References: <1454491848-26551-1-git-send-email-ldewangan@nvidia.com> <1454491848-26551-6-git-send-email-ldewangan@nvidia.com> <56B1DA31.7070109@samsung.com> <56B1E2F3.9010502@samsung.com> In-Reply-To: <56B1E2F3.9010502@samsung.com> X-Originating-IP: [10.19.65.30] X-ClientProxiedBy: DRUKMAIL101.nvidia.com (10.25.59.19) To bgmail102.nvidia.com (10.25.59.11) Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 03 February 2016 04:52 PM, Krzysztof Kozlowski wrote: > On 03.02.2016 19:45, Krzysztof Kozlowski wrote: >> On 03.02.2016 18:30, Laxman Dewangan wrote: >>> >>> err_rtc: >>> + if (info->rtc) >>> + i2c_unregister_device(info->rtc); >>> + regmap_del_irq_chip(info->rtc_irq, info->rtc_irq_data); >>> + >> You should clean up in reverse order of allocation, so first >> regmap_del_irq_chip then i2c_unregister_device. This >> is a common pattern of cleaning up. Sometimes such order >> is even necessary because of dependencies between >> components... which is not a case here but still the >> natural way is reversing the allocation code. I made the change in other place (remove callback) but not this place. It is just missed by me. my bad.. Will do in next patch. >> [ 88.296055] [] (do_filp_open) from [] (do_sys_open+0x114/0x1c0) >> [ 88.303699] [] (do_sys_open) from [] (ret_fast_syscall+0x0/0x3c) >> [ 88.311419] Code: e7905003 e3550000 0a00001f e5943014 (e7950003) >> [ 88.317573] ---[ end trace 9502799e3ea05a80 ]--- > However removal of "remove" callback helps... which could be expected... > maybe it is not an error of the driver itself? OK, looked it and found that we are registering the chip_irq as normal and interrupt as devm_*. So when we remove, we delete the regmap_irq_chip first and then free irq. That is creating issue. It seems I can not use the devm_requested_irq_thread() and need to use requested_irq_thread() for proper sequence of freeing it. Otherwise we need to add the devm_regmap_add_irq_chip() first and then use it. I am spinning the series to use the requested_thread_irq() only to avoid unbind issue.