Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp483907imu; Thu, 8 Nov 2018 11:03:49 -0800 (PST) X-Google-Smtp-Source: AJdET5cXosortYkxsyxzxR6OglH/d0HM5wcFdwZ9eleKrcL6uw2cNXz19WKtie7/RMN6/8E72eYr X-Received: by 2002:a17:902:bd0b:: with SMTP id p11-v6mr5651432pls.35.1541703829210; Thu, 08 Nov 2018 11:03:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541703829; cv=none; d=google.com; s=arc-20160816; b=LsBPpPQK0DdSFSwFiCXfP7cYUEMYfpa+H/cMcP0DlP5SAWrm0kmOISSPst4RfyBqWT ddPjbqFqFHOma+hlgsyqPTWJyjGk2ekJe6MRy4nA55HLQT3iEXDAn0khh36VcpKnwUTh OEopVIUqzVKB7HERQsyAh5NePZTVExdrIoHQVGF4b33EZrAA8zMrcXySwVOnjY1X9F+T OmzuyHFY4N0V26sjTYP31tJwwRpSctiztbcqGy3f4crd6/X1C6pKz1JSF1Rta28yPGwI 864cu/Y5u5XuMc518+E2EcJm3askqcbjJk32hIpWfEtgg7YOX9cOdzAQooAJqoueJgf6 L+qA== 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:date:subject:cc:to:from:dkim-signature; bh=LJVLUDV11EDb2vbd+GFA7UxacxtSc2FBZExCPPIxd7g=; b=pxl1uwsujr82cCRHAo37c3uw4y9RlgmYJFrRh3Fh/QkHuuG1dfOcG8hHiACSppHC4F mWZY7cW50BI9hA3FygkvUMwRKqJjlEbHjia6FkGKUY5hOFybJ7dgHWaiYi2OUnorr1It EJXwXj5hpE19sk3Z7WUyxc2TjSpGbn0X49W1YFXdhDIKMek36qbTIMc4+yTP52o77dPx w9hHe8AZzpicHvfPJXsZ0Mi1ddKuOwUPTrPN9RTxBPkQNWlK0ir08XkX47OlbeYEO4rv NASB+XOqAur6BDmhbIaNbmAH+99D3DJnqR0Lug9iPxRgUdrxCr50WrkAg7QNQHUeUFiS pCsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="aDo/l2h4"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16-v6si4275385pgk.358.2018.11.08.11.03.33; Thu, 08 Nov 2018 11:03: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=@gmail.com header.s=20161025 header.b="aDo/l2h4"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727247AbeKIEjm (ORCPT + 99 others); Thu, 8 Nov 2018 23:39:42 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:40789 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726801AbeKIEjm (ORCPT ); Thu, 8 Nov 2018 23:39:42 -0500 Received: by mail-wm1-f65.google.com with SMTP id b203-v6so2225016wme.5 for ; Thu, 08 Nov 2018 11:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=LJVLUDV11EDb2vbd+GFA7UxacxtSc2FBZExCPPIxd7g=; b=aDo/l2h4KNNUXOkCOFBackchxvkURX5rxDhACDcsSXBcMwLv+QkoAsyyASuNybud4P M8WPfiN5W2OqHvSGLqPnEF1P3Boct4Wmhy3STo3IVPQRwnb5boyPY+7Zik947jJURi2q 46LM8x8pIbnl4AKDojzaeHdCya76FnWn2g/ikl77l7KboGJIzndqhBcsEvXnmCF10otA IdMlCs6JMx7WkMei4ZVIBRuaQ5tO+aKdWUrsvKVKs7ZrP1mulAlie2V+Qa8hMbIuvynF BDcqnCpGL6MSKVaerxnPz3QscSmT4hEsN6W/t44TtOQ2VIVjy0g4wpI3tRFKOMS0uBdG wBmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=LJVLUDV11EDb2vbd+GFA7UxacxtSc2FBZExCPPIxd7g=; b=pPvOeesJycn9K9QRHdiYDFXozeltqGxiOxQs1qAvB3lZVcrZrn6CqC/lITOiIY+8fO VGAzPGJi6I2WNhFcfQze007gXjbOFzHX9ICaldL+ku+PvWshwavnRT5Vq187HfBTAJP3 ZMO4GpMT+4dxn1odsF/oa0nVm5N06Bs37JCSBHG18L2bR3/1hETP4CP6qFqr9iW5SyuJ H5dVz9Dx1NwqOn4ggZARZLWc57PyPN9i/wmZ9wU6Icgmug1dP84pzKwvF0smJzP6xXzH /KZRACBwQ0YJ9tuIiBTw41iokoV9KmQiIIsFO7gY0dJ0+BqodVD2buESCYdQmAEhkR1s DAYQ== X-Gm-Message-State: AGRZ1gJaibnSUfHxDN4KXymWQixt6+/59VuHnQnzAmacSXrHxR0UeUkl pSfg3xu6ORp55yctdvmbQ4A= X-Received: by 2002:a1c:8a11:: with SMTP id m17-v6mr2147499wmd.15.1541703770065; Thu, 08 Nov 2018 11:02:50 -0800 (PST) Received: from localhost.localdomain (ip-76.net-89-3-178.rev.numericable.fr. [89.3.178.76]) by smtp.gmail.com with ESMTPSA id q20-v6sm5110625wmc.33.2018.11.08.11.02.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Nov 2018 11:02:49 -0800 (PST) From: David Abdurachmanov To: palmer@sifive.com, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: David Abdurachmanov , Arnd Bergmann , Marcin Juszkiewicz , Guenter Roeck Subject: [PATCH v2] riscv: add asm/unistd.h UAPI header Date: Thu, 8 Nov 2018 20:02:39 +0100 Message-Id: <20181108190239.29633-1-david.abdurachmanov@gmail.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Marcin Juszkiewicz reported issues while generating syscall table for riscv using 4.20-rc1. The patch refactors our unistd.h files to match some other architectures. - Add asm/unistd.h UAPI header, which has __ARCH_WANT_NEW_STAT only for 64-bit - Remove asm/syscalls.h UAPI header and merge to asm/unistd.h - Adjust kernel asm/unistd.h So now asm/unistd.h UAPI header should show all syscalls for riscv. Before this, Makefile simply put `#include ` into generated asm/unistd.h UAPI header thus user didn't see: - __NR_riscv_flush_icache - __NR_newfstatat - __NR_fstat which are supported by riscv kernel. Signed-off-by: David Abdurachmanov Cc: Arnd Bergmann Cc: Marcin Juszkiewicz Cc: Guenter Roeck Fixes: 67314ec7b025 ("RISC-V: Request newstat syscalls") Signed-off-by: David Abdurachmanov --- arch/riscv/include/asm/unistd.h | 5 ++-- arch/riscv/include/uapi/asm/syscalls.h | 29 ------------------ arch/riscv/include/uapi/asm/unistd.h | 41 ++++++++++++++++++++++++++ 3 files changed, 43 insertions(+), 32 deletions(-) delete mode 100644 arch/riscv/include/uapi/asm/syscalls.h create mode 100644 arch/riscv/include/uapi/asm/unistd.h diff --git a/arch/riscv/include/asm/unistd.h b/arch/riscv/include/asm/unistd.h index eff7aa9aa163..fef96f117b4d 100644 --- a/arch/riscv/include/asm/unistd.h +++ b/arch/riscv/include/asm/unistd.h @@ -13,10 +13,9 @@ /* * There is explicitly no include guard here because this file is expected to - * be included multiple times. See uapi/asm/syscalls.h for more info. + * be included multiple times. */ -#define __ARCH_WANT_NEW_STAT #define __ARCH_WANT_SYS_CLONE + #include -#include diff --git a/arch/riscv/include/uapi/asm/syscalls.h b/arch/riscv/include/uapi/asm/syscalls.h deleted file mode 100644 index 206dc4b0f6ea..000000000000 --- a/arch/riscv/include/uapi/asm/syscalls.h +++ /dev/null @@ -1,29 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* - * Copyright (C) 2017-2018 SiFive - */ - -/* - * There is explicitly no include guard here because this file is expected to - * be included multiple times in order to define the syscall macros via - * __SYSCALL. - */ - -/* - * Allows the instruction cache to be flushed from userspace. Despite RISC-V - * having a direct 'fence.i' instruction available to userspace (which we - * can't trap!), that's not actually viable when running on Linux because the - * kernel might schedule a process on another hart. There is no way for - * userspace to handle this without invoking the kernel (as it doesn't know the - * thread->hart mappings), so we've defined a RISC-V specific system call to - * flush the instruction cache. - * - * __NR_riscv_flush_icache is defined to flush the instruction cache over an - * address range, with the flush applying to either all threads or just the - * caller. We don't currently do anything with the address range, that's just - * in there for forwards compatibility. - */ -#ifndef __NR_riscv_flush_icache -#define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15) -#endif -__SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache) diff --git a/arch/riscv/include/uapi/asm/unistd.h b/arch/riscv/include/uapi/asm/unistd.h new file mode 100644 index 000000000000..1f3bd3ebbb0d --- /dev/null +++ b/arch/riscv/include/uapi/asm/unistd.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +/* + * Copyright (C) 2018 David Abdurachmanov + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + */ + +#ifdef __LP64__ +#define __ARCH_WANT_NEW_STAT +#endif /* __LP64__ */ + +#include + +/* + * Allows the instruction cache to be flushed from userspace. Despite RISC-V + * having a direct 'fence.i' instruction available to userspace (which we + * can't trap!), that's not actually viable when running on Linux because the + * kernel might schedule a process on another hart. There is no way for + * userspace to handle this without invoking the kernel (as it doesn't know the + * thread->hart mappings), so we've defined a RISC-V specific system call to + * flush the instruction cache. + * + * __NR_riscv_flush_icache is defined to flush the instruction cache over an + * address range, with the flush applying to either all threads or just the + * caller. We don't currently do anything with the address range, that's just + * in there for forwards compatibility. + */ +#ifndef __NR_riscv_flush_icache +#define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15) +#endif +__SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache) -- 2.19.1