Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp52701pxb; Wed, 13 Jan 2021 23:04:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJw41vjDwQ/7b3s1quoFq+NI/sqS7fD6EaE7v5nj1VeqJdwD+xLUPeluhfyEz90xEBYCm3zY X-Received: by 2002:a17:906:3404:: with SMTP id c4mr4403184ejb.86.1610607854853; Wed, 13 Jan 2021 23:04:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610607854; cv=none; d=google.com; s=arc-20160816; b=p0Bxd0RCddV8VCVWEK0pI6S6rysY4unYOdQUVEIB3NnNTWi4DPGzWnl2Ph+VMNUg5y kR24EH8GgzBPsANkEHYcClRdZNVTaWrFPllc82nWNuQH5+FWoCYJRGl98Czx1WnDTvIy fUMbpsKIOa7+FmGjHOGrchQ7cQJO1aqWxsKVbeXx8KZ9iFNhRvZdbPI0nQGo5FqMmvID u2u2Q6yTib/UCsVe8DyzF3WasXFjsitnBtMeA4YL9LaXrOe4ydZu7j/2tmU8z7MKAzoS aoRl9B+qDmJGLFyzCk5Xrh/y3vJOq/YbKVPdUtzj9qkia7SLT39/VQuoH3IrdDeecYG/ CXBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:date:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version :dkim-signature; bh=JYt8EI7ieKorpASVOTgek/+xr+Y9gbz77CFyRzCwwWc=; b=VlxjSlCiIXxJaJLrQFvxVZK6R4s8SoXRfm/3Nfx3j+dVVpYmxW79wXoLPO0OowB4nX Y5xO9tfluYjg6CfHu7gJ/rkyU7SsHzF3sMO6kUkrI5IQnwbdWOiK2KJrUYRNpiFqrHt0 TA0kXtR7ai1X3rksVpYwHAzUeeP+WRbnwMf9YgTxnpj8GarxIULbbap/VviVPv91WHbY NV2Ro/pP+3PPJYgmGJl2ePlsCSGyuBK4Hj9qQOdihNUR95sawF+7wvuierMJoBNr0v74 GWMm0Pe0x4/O60phmIsocAg+kmi1SRFwBQ0szXEcsodsLJjNF7znNRiChFlOUZao7Nom Rffg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=LFFNI2M+; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b1si2001061edy.429.2021.01.13.23.03.29; Wed, 13 Jan 2021 23:04:14 -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=@chromium.org header.s=google header.b=LFFNI2M+; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726204AbhANHCi (ORCPT + 99 others); Thu, 14 Jan 2021 02:02:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726055AbhANHCh (ORCPT ); Thu, 14 Jan 2021 02:02:37 -0500 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF8C7C061794 for ; Wed, 13 Jan 2021 23:01:56 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id l23so2688173pjg.1 for ; Wed, 13 Jan 2021 23:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:in-reply-to:references :subject:from:cc:to:date:message-id:user-agent; bh=JYt8EI7ieKorpASVOTgek/+xr+Y9gbz77CFyRzCwwWc=; b=LFFNI2M+BRcL71xQeiE/HQKmU6e8hRTnsGw7tApsujH74JkBAe7fqku6FUdkM5IR+Q SJhfYYVAxqyypI4g788jHX+tNEe5BpDe+vRDiFNdrtMlJ94LTtXniKeisrj4iSf/B8Sf voXJ0UtPw/36wMa3gDL2uiOjH3OxNXB9WkmaI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :in-reply-to:references:subject:from:cc:to:date:message-id :user-agent; bh=JYt8EI7ieKorpASVOTgek/+xr+Y9gbz77CFyRzCwwWc=; b=H0RunK+BYTP9HlItg/nPpT3XfQS8dyZ4O0EsXf4LsMIqyCG+eeIy2mrnInYTpjCHel c4s+Pau3oemf4bhDRSD2GGY0NhLo0szx8PqJDSrhNzK9oX5pc1ef4iAyVqMCvQtxgSDn 0f9iqIgWWv+qeEziTcDoRTmigWR1X9Qslua+L9aBcSz2GyNU4yib4rHcQV1RjnHHeqsn WHeqzwkjrQoK4h8GHqIrlqo09/D3vADC71RcGjljSbfx0EvFfyldKHi+XXratKj/nj62 TtqjdS50p/Cl76UisZQdeuVm9bXQFl/uo2rkCiR2szZ/O6bE1eOyZmfOEKaSGApTD3th nJfw== X-Gm-Message-State: AOAM530FmBB4zpBq1/+eBQcfCwdPJFv/ngPCGDCjR5dKGdRJKJqC5A2a ku99AvVZ9Cc0jwDPMU9X9asCGA== X-Received: by 2002:a17:90a:c791:: with SMTP id gn17mr3543162pjb.28.1610607716259; Wed, 13 Jan 2021 23:01:56 -0800 (PST) Received: from chromium.org ([2620:15c:202:201:3e52:82ff:fe6c:83ab]) by smtp.gmail.com with ESMTPSA id b12sm4286109pft.114.2021.01.13.23.01.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jan 2021 23:01:55 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20210108093339.v5.2.I3635de080604e1feda770591c5563bd6e63dd39d@changeid> References: <20210108093339.v5.1.I3ad184e3423d8e479bc3e86f5b393abb1704a1d1@changeid> <20210108093339.v5.2.I3635de080604e1feda770591c5563bd6e63dd39d@changeid> Subject: Re: [PATCH v5 2/4] pinctrl: qcom: No need to read-modify-write the interrupt status From: Stephen Boyd Cc: Bjorn Andersson , Neeraj Upadhyay , Rajendra Nayak , Maulik Shah , linux-gpio@vger.kernel.org, Srinivas Ramana , linux-arm-msm@vger.kernel.org, Douglas Anderson , Andy Gross , linux-kernel@vger.kernel.org To: Douglas Anderson , Jason Cooper , Linus Walleij , Marc Zyngier , Thomas Gleixner Date: Wed, 13 Jan 2021 23:01:54 -0800 Message-ID: <161060771402.3661239.1174238618385699475@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Douglas Anderson (2021-01-08 09:35:14) > When the Qualcomm pinctrl driver wants to Ack an interrupt, it does a > read-modify-write on the interrupt status register. On some SoCs it > makes sure that the status bit is 1 to "Ack" and on others it makes > sure that the bit is 0 to "Ack". Presumably the first type of > interrupt controller is a "write 1 to clear" type register and the > second just let you directly set the interrupt status register. >=20 > As far as I can tell from scanning structure definitions, the > interrupt status bit is always in a register by itself. Thus with > both types of interrupt controllers it is safe to "Ack" interrupts > without doing a read-modify-write. We can do a simple write. >=20 > It should be noted that if the interrupt status bit _was_ ever in a > register with other things (like maybe status bits for other GPIOs): > a) For "write 1 clear" type controllers then read-modify-write would > be totally wrong because we'd accidentally end up clearing > interrupts we weren't looking at. > b) For "direct set" type controllers then read-modify-write would also > be wrong because someone setting one of the other bits in the > register might accidentally clear (or set) our interrupt. > I say this simply to show that the current read-modify-write doesn't > provide any sort of "future proofing" of the code. In fact (for > "write 1 clear" controllers) the new code is slightly more "future > proof" since it would allow more than one interrupt status bits to > share a register. >=20 > NOTE: this code fixes no bugs--it simply avoids an extra register > read. >=20 > Signed-off-by: Douglas Anderson > --- Reviewed-by: Stephen Boyd