From patchwork Thu Sep 1 10:47:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Murzin X-Patchwork-Id: 9308821 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C87DE607D2 for ; Thu, 1 Sep 2016 10:49:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B0ACA292EE for ; Thu, 1 Sep 2016 10:49:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A3B95292F1; Thu, 1 Sep 2016 10:49:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 2E9B4292EE for ; Thu, 1 Sep 2016 10:49:03 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bfPWz-0002sv-5u; Thu, 01 Sep 2016 10:47:37 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bfPWv-0002pt-4c for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2016 10:47:33 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4756D2B; Thu, 1 Sep 2016 03:47:12 -0700 (PDT) Received: from login2.euhpc.arm.com (login2.euhpc.arm.com [10.6.26.144]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8823B3F303; Thu, 1 Sep 2016 03:47:11 -0700 (PDT) From: Vladimir Murzin To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] arm64: spinlock: clarify implementation details of arch_spin_lock Date: Thu, 1 Sep 2016 11:47:00 +0100 Message-Id: <1472726820-32959-1-git-send-email-vladimir.murzin@arm.com> X-Mailer: git-send-email 2.0.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160901_034733_190319_8E1A720C X-CRM114-Status: UNSURE ( 9.61 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: catalin.marinas@arm.com, will.deacon@arm.com, liguozhu@hisilicon.com MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP It seems to be quite confusing to see atomic load not being paired with atomic store down to arch_spin_lock function. To prevent the same questions/patches around this add a comment block explaining what is going on there. The comment has been stolen from Catalin's reply [1]. [1] https://lkml.org/lkml/2016/8/30/127 Signed-off-by: Vladimir Murzin --- arch/arm64/include/asm/spinlock.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/arch/arm64/include/asm/spinlock.h b/arch/arm64/include/asm/spinlock.h index e875a5a..9a2155c 100644 --- a/arch/arm64/include/asm/spinlock.h +++ b/arch/arm64/include/asm/spinlock.h @@ -113,6 +113,18 @@ static inline void arch_spin_lock(arch_spinlock_t *lock) */ " sevl\n" "2: wfe\n" + /* + * Don't be confused with atomic load bellow not being paired + * with atomic store. This is needed because the + * arch_spin_unlock() code only uses an STLR without an + * explicit SEV (like we have on AArch32). An event is + * automatically generated when the exclusive monitor is + * cleared by STLR. But without setting it with a load + * exclusive in arch_spin_lock() (even though it does not + * acquire the lock), there won't be anything to clear, hence + * no event to be generated. In this case, the WFE would wait + * indefinitely. + */ " ldaxrh %w2, %4\n" " eor %w1, %w2, %w0, lsr #16\n" " cbnz %w1, 2b\n"