Received: by 10.223.185.116 with SMTP id b49csp4404032wrg; Mon, 26 Feb 2018 17:29:49 -0800 (PST) X-Google-Smtp-Source: AH8x225jPiLcS8bJCSyDJVZjx3v0g7+hZwlmAzI9BzvWYcONqTG1zRg9dBiCL6HP27oJTMqLZ2VH X-Received: by 2002:a17:902:bc3:: with SMTP id 61-v6mr12375229plr.407.1519694989161; Mon, 26 Feb 2018 17:29:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519694989; cv=none; d=google.com; s=arc-20160816; b=jZDLmViBKqV0kYh8yxCdB/EFVkTx7pqXA0VHky6gTvyeIppuVJ7i79XC/FJJiT2OqW eM4Cby/71mxzjupn2kJS8IwqGNlVKwgM1c/MREvyeShEKU9B9XmIziVzYVVhG7ktqvLL Y05EdZH+nt9UMmOaLNHUhF4LMbmCqUubtq6Y8FEIpA69u9TgmDuUIXDD+Xpz+QZME9QA XwbhYEAW7rNZOQxUvHVO4Zd4+Ynj9rQ9aix/kk7F8BoMu+v7gVAA2D3URyu/+Ck2AT7F RTHwSNNPyF0oT7SCLlvFraC2E2OAlKUkkiISNKAL4pmhnKnyLcQHm8JJIZ35zEWaEohg vbcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature :arc-authentication-results; bh=kPnw+T26b8giEZyqGpYyw0zXVKbPvDZVwhv4MiIYIOs=; b=sG6SjrJMMWDWib6D3NgsAKkCuyZ7QPy/bxB4Hu5dKNTYSkUFK0mt4pgns567M2WWrs ily2t8GPQGUGch9+LPiFMJny8VCl67olYOLIWWMgGXVFWGVi850m//xLnQE3DqHjv+hq cmnMnexFSoq51vebk3Eu5MldBG9iCq82emRS5CfNkIMhey3kk9ZbAhuGjdr21nIyBgvE YHBzGZOnlOw7BqRQPVMPmKT+EIACw4db/ofOHvKi8LX0HCLW1MSHApZGLVPhzg8728fI VMWpSfRXO2LGH5PG/g3TpPOqB80i2YyZulk2fFNbC3+BLUfDurUjOO9DegYTJgyS98Xe vsAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=hY5n4AXT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w34-v6si7580818pla.686.2018.02.26.17.29.34; Mon, 26 Feb 2018 17:29:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=hY5n4AXT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751530AbeB0B24 (ORCPT + 99 others); Mon, 26 Feb 2018 20:28:56 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:33714 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751094AbeB0B2z (ORCPT ); Mon, 26 Feb 2018 20:28:55 -0500 Received: by mail-pg0-f65.google.com with SMTP id g12so6911220pgs.0 for ; Mon, 26 Feb 2018 17:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=kPnw+T26b8giEZyqGpYyw0zXVKbPvDZVwhv4MiIYIOs=; b=hY5n4AXTTXMhnmN3PdkYYPX9zEGwfXEjDfPkcb08jE1xrwJtVlvrKBXJD20+zqh9Ul OJrR0yaU5FpYg12pU3feSRe6BZbyKyP5GzvtJ+8EXFWGh7QKkyNe6uTsiJGbzYeCiFAb BJlNAXB+VXmuT+WuH9eo14vmdc9pT19JRrHG72gKHnC0B0CZtfSYrIs4OxM2rPvSme48 PWFVw6jX7f4lbnvzHd+0aM4yVR5EtloeBl+SH+bdtVnS2hb1GL7ERp7hQA2UIpqAu+3G p/XKldZ9EWfWTSHcitcGOoJwD89FlTdpeFqG4rDsdLjpgV2M+aYbngit21AQUbid/+AN gIAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=kPnw+T26b8giEZyqGpYyw0zXVKbPvDZVwhv4MiIYIOs=; b=m+is9wIcFgHx0bCWOd1pEAG1oFFpor9yJHQyjie1ogjIqaRZkY5RjgCoIs+LJgxa+k okTQAGWxakDOsflm/hMHR31Vj8S/u2K/e1ndnywv+p33KPiilfy2aK/mfc3O1F7vnhpU ViI0N/2vNjicDBVkYMJubr+nKdsCozwowF0v6+NwP/BbF9l3mea+xvq1qxTKmDENnb5F GNkZSMzu4Vz1MoJyPDipg23/IXOVmRmub4PI9UROpuYqrWIULrYHsLzu9IKSsdsXFEQI O9GyPPnHE2U6R6qzj7RA+29nGuyQBlfZj9GM8G0Jhg8TUZENYEp4rNAiwb25UmyKjWqn w1bw== X-Gm-Message-State: APf1xPBV63/8P0h5iFMigfJbJwgby+eZOlPjE+WOZYVQrfnFYZqIogu7 ZTVudaCEwkldgQnA5ObjMbhVjg== X-Received: by 10.99.128.195 with SMTP id j186mr9941572pgd.15.1519694933926; Mon, 26 Feb 2018 17:28:53 -0800 (PST) Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id h69sm21209991pfe.97.2018.02.26.17.28.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 17:28:53 -0800 (PST) Date: Mon, 26 Feb 2018 17:28:53 -0800 (PST) X-Google-Original-Date: Mon, 26 Feb 2018 17:28:25 PST (-0800) Subject: Re: [PATCH RFC] riscv/barrier: Define __smp_{mb,rmb,wmb} In-Reply-To: <20180226103552.GA9138@andrea> CC: albert@sifive.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org From: Palmer Dabbelt To: parri.andrea@gmail.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 26 Feb 2018 02:35:52 PST (-0800), parri.andrea@gmail.com wrote: > On Thu, Feb 22, 2018 at 03:14:52PM -0800, Palmer Dabbelt wrote: >> On Tue, 20 Feb 2018 02:17:28 PST (-0800), parri.andrea@gmail.com wrote: >> >Introduce __smp_{mb,rmb,wmb}, and rely on the generic definitions >> >for smp_{mb,rmb,wmb}. A first consequence is that smp_{mb,rmb,wmb} >> >map to a compiler barrier on !SMP (while their definition remains >> >unchanged on SMP). As a further consequence, smp_load_acquire and >> >smp_store_release have "fence rw,rw" instead of "fence iorw,iorw". >> > >> >Signed-off-by: Andrea Parri >> >--- >> > arch/riscv/include/asm/barrier.h | 6 +++--- >> > 1 file changed, 3 insertions(+), 3 deletions(-) >> > >> >diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h >> >index c0319cbf1eec5..5510366d169ae 100644 >> >--- a/arch/riscv/include/asm/barrier.h >> >+++ b/arch/riscv/include/asm/barrier.h >> >@@ -34,9 +34,9 @@ >> > #define wmb() RISCV_FENCE(ow,ow) >> > >> > /* These barriers do not need to enforce ordering on devices, just memory. */ >> >-#define smp_mb() RISCV_FENCE(rw,rw) >> >-#define smp_rmb() RISCV_FENCE(r,r) >> >-#define smp_wmb() RISCV_FENCE(w,w) >> >+#define __smp_mb() RISCV_FENCE(rw,rw) >> >+#define __smp_rmb() RISCV_FENCE(r,r) >> >+#define __smp_wmb() RISCV_FENCE(w,w) >> > >> > /* >> > * This is a very specific barrier: it's currently only used in two places in >> >> Thanks! I'm going to take this for the next RC. > > Thank you, Palmer. I'm planning to post more changes to the file, > but I'd like to build on top of this change: could you point me to > the appropriate branch/repo for this? Here's the canonical RISC-V Linux git repo https://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git/ Your branch is now the HEAD of the "for-linus" branch, which means it'll be sent to Linus the next time I send patches. I generate and tag "for-linus" on Monday mornings and then send it out on Wednesday mornings, just to make sure everything has time to bake. https://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git/ Additionally, I mantain a "for-next" branch that contains everything that's been sufficiently reviewed to be made part of Linux, but that is being staged for a bit longer than what's in for-linus for one reason or another (usually it's just not RC material and is targeted for the next merge window). There is also a RISC-V integration branch named "riscv-all" that contains all our work in progress patches. This is likely to be unstable, but it's best to check there to see if anything interesting is going on related to what you're working on to avoid duplicating work. These branches are all generated from my personal git tree https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/ There's a bunch of branches in here tracking each change set (yours is called "fix-smp_mb", to indicate it can go in during an RC) that's still in flight. There's some scripts to generate some of these branches, but the commits I actually send upstream are merged by hand https://github.com/riscv/riscv-linux-infra "for-next" and "riscv-all" are rebased regularly, so it's probably best to track commits back to their original WIP branch and work from there to avoid major headaches.