Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp348551pxb; Tue, 9 Feb 2021 01:47:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJz6HQf7r35wlwE0pKZ1npQJGGi4s5qKAtrII14fbsPlYV0ZNzQgdlQRK7ENA7EyEJvwHwKM X-Received: by 2002:a17:906:8612:: with SMTP id o18mr21315949ejx.435.1612864045803; Tue, 09 Feb 2021 01:47:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612864045; cv=none; d=google.com; s=arc-20160816; b=nhUj43UkWLUYfw9nsi6w3vM1epjming27Vr37qPkpQFkmDxnkIlqUfAkfaLNZBY80w NMSdYotUwsIcGSf2J0HqowWHWrFmXdYG9Ty60abvSu7FtRTHkVfHfao4QY9COr5r5/Dc xv4TYHinrrgdYVgP16H5MOAIa/YlhZLIIQy3QS5HVCpjnFXTgRrXYMpNIZh0no0pYi83 s5lRXiT+UTXMhKj0IYKFzdTk9LFEnln6jzjWJRbqBCYPJHWTqzPdk+VR1GpN0vmdE/6z LsbyhbPPOSGf3ObNGwmFcWrQOR4vtWWDSICDGAdw5xu8TriTGsvEocu2bYlW5CbTeUPm N2fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=nyBvxkCfPk/R/IbU1O61DW4CxUbKmLFozPu7m+ODXT8=; b=oQUf/9jVFMg4v5N+lHaIjzh2k2U9PENBl+E1HCUbN62ZnFTYKAjjZ0k4+DgEW9ur2I k08O7qrejXfkxHosMApOajhIZot6FNOctdGhQgmvofjAh3xtxy6ibWgV0gZe0j1Y3oMd ApYptkOn22J3AHVUayf2878Yvq57Y6y0ShybpAd2VIJaXN6j7cg6EvhrU27lkVN+nbLu KWTjMIv7M2E81oChNnYVh7wrDc55u0Qd3Mqz9M4ARJqvhYGbcLFfaOsWGIQvRC3jGDBA 9awDO3zB7cmM66MNe2Ush4/pgd2wtzVgCfAYqx5t3YAsCgz7D0DUktuwcq5ihfEzHwTd mSlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=i9Knmxo0; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id de20si12692104ejc.753.2021.02.09.01.47.02; Tue, 09 Feb 2021 01:47:25 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=i9Knmxo0; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230283AbhBIJoR (ORCPT + 99 others); Tue, 9 Feb 2021 04:44:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229988AbhBIJnC (ORCPT ); Tue, 9 Feb 2021 04:43:02 -0500 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DFC6C06178A; Tue, 9 Feb 2021 01:42:22 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id t25so12121386pga.2; Tue, 09 Feb 2021 01:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nyBvxkCfPk/R/IbU1O61DW4CxUbKmLFozPu7m+ODXT8=; b=i9Knmxo0KW3yPP2bz7VS817JDZIiOPiEW5Jz0MmMygjLZbW51yC4exvn+7DAtxGQLX DdkD/sKXzgVusapZWf1xBZ8y6e47B1PBWcDnxvHlR33SXGai9/77Nm3szH0u3kW0/T71 Z9DMB5l+hPwx/hLQlpEe8G5BJ04sqJUelV43/t8AjFm+LoLuSBTFagClBHJMbQwVp3KB qEXSYA1xm48Xh2DuulHQ9q+Ebm+jtqLsA9cArlPcqeQQh38LAyxlE4/7ym7LyPuyAQSd HSRliAJEfCkUPinC/MR3YtHEGn/2JhX6ssiemmitt50yWL9rxVl0YGY+e+LR9eU4jw9A i6eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nyBvxkCfPk/R/IbU1O61DW4CxUbKmLFozPu7m+ODXT8=; b=GKW5ANoIGQ+DfjG+jEEWbfGRF4iSl+R9j4RiwsyLvVvZ5ATNJzMqDK7T7tE19mOTRC 58SZh3Vla5N1Em0frzrvXVa03SToLsxzP2hXgGDNKMYShyWIi/erQJwl5RiDpVHulHtl Cmgb9ojshsvaR3oEaAMoupTuY+qoYOo4pprPmT9COJfF02MAZW5o+4i0scFEFG2LIfb6 dxAHfdvWrCbmWWc8gmeVYj2VHjQePnlRoBSO0L9f90ZRgysmN20KS5GMR6w1SaZmgAJk BmZWULyYFr3y2yOaFmXTPNR4R8oBFTyf5WfYwl94jql/Dg2IUGQj0vBDNOBbFv3idX4R Gm0A== X-Gm-Message-State: AOAM530sF8XDVaogPNBwDedYv8P8O5mDIeJCB8ItWUVNvHcT2X9vUwRl ncQZ9H5cWqWP7qB/w5/KwkC20clvf2CJEMClIAI= X-Received: by 2002:a62:384c:0:b029:1e3:8bca:5701 with SMTP id f73-20020a62384c0000b02901e38bca5701mr1345365pfa.7.1612863741838; Tue, 09 Feb 2021 01:42:21 -0800 (PST) MIME-Version: 1.0 References: <1612774577-55943-1-git-send-email-luojiaxing@huawei.com> <2b8001bb-0bcd-3fea-e15c-2722e7243209@huawei.com> <1a5dfcf2-11a2-f549-782d-447d58e21305@huawei.com> In-Reply-To: <1a5dfcf2-11a2-f549-782d-447d58e21305@huawei.com> From: Andy Shevchenko Date: Tue, 9 Feb 2021 11:42:05 +0200 Message-ID: Subject: Re: [Linuxarm] [PATCH for next v1 0/2] gpio: few clean up patches to replace spin_lock_irqsave with spin_lock To: luojiaxing Cc: Linus Walleij , Andy Shevchenko , Grygorii Strashko , Santosh Shilimkar , Kevin Hilman , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , linuxarm@openeuler.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 9, 2021 at 11:24 AM luojiaxing wrote: > On 2021/2/8 21:28, Andy Shevchenko wrote: > > On Mon, Feb 8, 2021 at 11:11 AM luojiaxing wrote: > >> Sorry, my operation error causes a patch missing from this patch set. I > >> re-send the patch set. Please check the new one. > > What is the new one?! You have to give proper versioning and change > > log for your series. > > sure, I will send a new one later, but let me answer your question first. > > >> On 2021/2/8 16:56, Luo Jiaxing wrote: > >>> There is no need to use API with _irqsave in hard IRQ handler, So replace > >>> those with spin_lock. > > How do you know that another CPU in the system can't serve the The keyword here is: *another*. > > following interrupt from the hardware at the same time? > > Yes, I have some question before. > > There are some similar discussion here, please take a look, Song baohua > explained it more professionally. > > https://lore.kernel.org/lkml/e949a474a9284ac6951813bfc8b34945@hisilicon.com/ > > Here are some excerpts from the discussion: > > I think the code disabling irq in hardIRQ is simply wrong. Why? > Since this commit > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc > genirq: Run irq handlers with interrupts disabled > > interrupt handlers are definitely running in a irq-disabled context > unless irq handlers enable them explicitly in the handler to permit > other interrupts. This doesn't explain any changes in the behaviour on SMP. IRQ line can be disabled on a few stages: a) on the source (IP that generates an event) b) on IRQ router / controller c) on CPU side The commit above is discussing (rightfully!) the problem when all interrupts are being served by a *single* core. Nobody prevents them from being served by *different* cores simultaneously. Also, see [1]. [1]: https://www.kernel.org/doc/htmldocs/kernel-locking/cheatsheet.html -- With Best Regards, Andy Shevchenko