From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753762AbbFEFNj (ORCPT ); Fri, 5 Jun 2015 01:13:39 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:33090 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750850AbbFEFNf (ORCPT ); Fri, 5 Jun 2015 01:13:35 -0400 X-AuditID: cbfee691-f79ca6d00000456a-d4-55712fe940dd Message-id: <55712FE9.1070006@samsung.com> Date: Fri, 05 Jun 2015 14:13:13 +0900 From: Chanwoo Choi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-version: 1.0 To: myungjoo.ham@samsung.com Cc: =?UTF-8?B?6rmA7J6s7JuQ?= , "linux-kernel@vger.kernel.org" , "linux-samsung-soc@vger.kernel.org" Subject: Re: [PATCH] extcon: max77843: Clear IRQ bits state before request IRQ References: <1462057843.591181433480053438.JavaMail.weblogic@epmlwas08a> In-reply-to: <1462057843.591181433480053438.JavaMail.weblogic@epmlwas08a> Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42JZI2JSpPtSvzDUYOoVcYsdDUdYLS7vmsNm MeP8PiaL240r2BxYPPq2rGL0+LxJLoApissmJTUnsyy1SN8ugStj1aMzrAVn+Sq2LHzH1MD4 nruLkZNDQsBE4tridawQtpjEhXvr2boYuTiEBJYySjzt+M0CU/Sq6y07RGI6o8S/Jy+YIZwH jBI/lp1nAqniFdCSuNgwG2gUBweLgKrExNuOIGE2oPD+FzfYQGxRgTCJldOvsECUC0r8mHwP zBYRkJG4unE7C8hMZoHDjBI3js1kB0kIC/hJzFw1CWy+kICHxOqJH5lBbE4BT4nehmawGmYB dYlJ8xYxQ9jyEpvXvAU7TkJgGbvEuwVnwIpYBAQkvk0+xAJynISArMSmA8wQn0lKHFxxg2UC o9gsJDfNQjJ2FpKxCxiZVzGKphYkFxQnpReZ6hUn5haX5qXrJefnbmIERs/pf88m7mC8f8D6 EKMAB6MSD++Dw/mhQqyJZcWVuYcYTYGumMgsJZqcD4zRvJJ4Q2MzIwtTE1NjI3NLMyVxXh3p n8FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGEsYlBSMVzm9unrw6yLV47861RhnbZM/5BCg UMb/adUlJ9uaP8Yq/g1Ma30PuU4wXFovP+df9rzXfuUn22pXlQXd37eH85mdIX/iIbtvQkK3 fDZK741QeflTYnld3psj3qfNmVl+vReQNZEpKNE/LupweOvmmBWxsblxzzWM/Cs0WEzZfv57 pMRSnJFoqMVcVJwIAA88MO+ZAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAIsWRmVeSWpSXmKPExsVy+t9jQd2X+oWhBuu2CFnsaDjCanF51xw2 ixnn9zFZ3G5cwebA4tG3ZRWjx+dNcgFMUQ2MNhmpiSmpRQqpecn5KZl56bZK3sHxzvGmZgaG uoaWFuZKCnmJuam2Si4+AbpumTlAm5QUyhJzSoFCAYnFxUr6dpgmhIa46VrANEbo+oYEwfUY GaCBhDWMGasenWEtOMtXsWXhO6YGxvfcXYycHBICJhKvut6yQ9hiEhfurWfrYuTiEBKYzijx 78kLZgjnAaPEj2XnmUCqeAW0JC42zGbtYuTgYBFQlZh42xEkzAYU3v/iBhuILSoQJrFy+hUW iHJBiR+T74HZIgIyElc3bmcBmckscJhR4saxmWCbhQX8JGaumgQ2X0jAQ2L1xI/MIDangKdE b0MzWA2zgLrEpHmLmCFseYnNa94yT2AUmIVkxywkZbOQlC1gZF7FKJpakFxQnJSea6hXnJhb XJqXrpecn7uJERybz6R2MK5ssDjEKMDBqMTDa3EsP1SINbGsuDL3EKMEB7OSCK8WT2GoEG9K YmVValF+fFFpTmrxIUZTYAhMZJYSTc4Hpo28knhDYxMzI0sjc0MLI2NzJXHek/k+oUIC6Ykl qdmpqQWpRTB9TBycUg2Ms4/2ZWzf2/0t5sK7VS3zfA6c19zAkxH5dO+T8sJIH1XPdS2PHqQJ i35kXf6Djzm3462zcMfnaZmKe9TfCH5mMgg5NvvH56mLag89z0459/fM3EtOAkLXM84ZrrvD suxfmdkzO2O+HQ+O6Zt6eNZwip12eLEsJVIuoH2d5tXI1+rmKzLl37MLKrEUZyQaajEXFScC AAo3Mv/jAgAA DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/05/2015 01:54 PM, MyungJoo Ham wrote: >> >> IRQ signal before driver probe is needless because driver sends >> current state after platform booting done. >> So, this patch clears MUIC IRQ bits before request IRQ. >> >> Signed-off-by: Jaewon Kim >> --- >> drivers/extcon/extcon-max77843.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) > > Q1. Is this because the pending bits are USELESS? > or because the pendeing bits incurs INCORRECT behaviors? The max77843 datasheet includes following sentence: - "All bits are cleared after a read" about INT1/INT2/INT3 register. There are no problem about interrupt handling. > > Q2. Does clearing (by reading) INT1 do everything you need? > What about INT2 and INT3? The MAXIM MAX77843 MUIC support the one more interrupts (e.g., ADC1K, VBVolt, ChgTyp ...). The each interrupt is included in the one register among INT1/2/3. This patch clear the all interrupts of MAX77843 before requesting the interrupts. > > Q3. I presume that "driver sends current state after..." is > coming from the invokation of "queue_delayed_work()" at the end > of the probe function. It appears that you are only serving > the pending status of "cable detection" with it while INT1 > seems to have more functionalities. Does that delayed work > do everything that are pending, really? When completed kernel booting, the delayed work of extcon-max77843.c driver use the MAX77843_MUIC_STATUSx register to detect the type of connected external connectors. So, there are no problme about clearing all bits of INT1/2/3 interrupt register. If user-space platform don't finish the initialization of all user-process daemons and extcon driver send the uevent during only kernel booting, the uevent is not handled on user-space daemons. Thanks, Chanwoo Choi