Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2375708pxu; Mon, 7 Dec 2020 05:09:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJybGvg6Aqc/dAG6R62GGoz1ev6lyaqdc1uaHIxR9SrFwWIL4inUSk1F/AG8LHdmV8top3JU X-Received: by 2002:a17:906:7784:: with SMTP id s4mr1170021ejm.93.1607346569447; Mon, 07 Dec 2020 05:09:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607346569; cv=none; d=google.com; s=arc-20160816; b=lRyMzmHtZwBmPpWg387IxeP21joI+g46tJN+SbLP5XSosDjvdNKROHkHMBvV0+OkYp Zd+yLz5T6klLPAl7d8wDHyamCzFe1h0dajpTHGv+7cQOKFNTW4GkSlcYtUEOihCW0jGm /qTczSWzJbPUeU3+4HyhiSFnOJxYzyTTe5QgdV8Kj1YkaEji1GKqt2eAWTx6ahJBjfwn 27/15C9JHeANB7q7kXbbpn0g90ip8Zlz22x7Z42V0TSopD3IfB3NYFpE6PsU2oBZN1Pt SXAaLgxGuBXh4oh4bhWBtrykzT9qrevf/+ghU7ut8F/3/VYs2lLmqImH8I3ZSVV93wQx VxEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=qV7mxnSW7PiexzKXLJOa4A1LeOxu5Xrdx4tq5T8kO9o=; b=sQ0ZcAbPBVMzj+WGQM8uilsBHQ8zN1PWYNVVKTNIuvhGA7QE5CcYxGjXbj+2IJQE8B tushCyoPcplwiEQRvIHoArvWvTIDSGiFl470CNffpIlAH8Xa8NnVT8ETOg0nQfbIYj8X atgcYBOZAdm0jqQ+uHkG5d6ytdV33xryhVLHbVKQhYMqzPrVfYJA8xisGvrtrqZgh9yJ VEj1eRPKEWPtLkDQbFUndInkzTASe/3vVIzneYt+QNCiqRc5mpuAzxxfUkMdzGGjO0CZ NAC88OGI5s44U1Ka3BUFRFI7+Y0SJLiGPhgeBq21EZQJm5c4YR8eKWY2zDjUv8L3ZJj4 uCFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lw15si6181765ejb.535.2020.12.07.05.09.03; Mon, 07 Dec 2020 05:09:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726164AbgLGNEz (ORCPT + 99 others); Mon, 7 Dec 2020 08:04:55 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:9114 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725842AbgLGNEy (ORCPT ); Mon, 7 Dec 2020 08:04:54 -0500 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4CqNm435ljzM1ZM; Mon, 7 Dec 2020 21:03:32 +0800 (CST) Received: from [127.0.0.1] (10.57.22.126) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.487.0; Mon, 7 Dec 2020 21:04:03 +0800 Subject: Re: [PATCH v1] gpio: dwapb: mask/unmask IRQ when disable/enable it To: Linus Walleij , Serge Semin CC: Thomas Gleixner , Jason Cooper , Marc Zyngier , Andy Shevchenko , Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , Linuxarm References: <1606728979-44259-1-git-send-email-luojiaxing@huawei.com> <20201130112250.GK4077@smile.fi.intel.com> <63f7dcc4-a924-515a-2fea-31ec80f3353e@huawei.com> <20201205221522.ifjravnir5bzmjff@mobilestation> From: luojiaxing Message-ID: <8592c7f0-a9e9-f48c-e9e4-0e24e22b3f57@huawei.com> Date: Mon, 7 Dec 2020 21:04:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.57.22.126] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/12/6 23:02, Linus Walleij wrote: > On Sat, Dec 5, 2020 at 11:15 PM Serge Semin wrote: > >> Hmm, that sounds like a problem, but the explanation is a bit unclear >> to me. AFAICS you are saying that the only callbacks which are >> called during the IRQ request/release are the irq_enable(), right? If >> so then the only reason why we haven't got a problem reported due to >> that so far is that the IRQs actually unmasked by default. > What we usually do in cases like that (and I have discussed this > with tglx in the past I think) is to simply mask off all IRQs in probe(). > Then they will be unmasked when requested by drivers. Yes, I agree. but in this case I mean that they will not unmasked when drivers request IRQ. Drivers request IRQ will only call irq_enable(), so if we mask all IRQ in gpio-dwab.'s probe(), no one will unmask the IRQ for drivers. Thanks Jiaxing > > See e.g. gpio-pl061 that has this line in probe(): > writeb(0, pl061->base + GPIOIE); /* disable irqs */ > > Yours, > Linus Walleij > > . >