Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2468619ybt; Tue, 16 Jun 2020 06:59:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKEzmL3N2cuYQVzoyvnI52H11jnibwgUHDHj/9UNFgU0B63uIZ5tl7Loc4xG9CWJBIOcyH X-Received: by 2002:a17:906:6b8a:: with SMTP id l10mr2713863ejr.465.1592315991408; Tue, 16 Jun 2020 06:59:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592315991; cv=none; d=google.com; s=arc-20160816; b=ZQPdArZDvOnDFuQ/fIySHwwZjDVlCBuhoLSa/6XztbjRKCPXV/WhDaS83mhtuEMF74 xOKduoMhmbaiAaJTtP+Qs+2uCOQVKlqZL9ep+HeTjiMrZs94Kbi4bSFUHm1Fr/03uvxv 4z/Wt47X2wv6wrt1ZKqvRribJQ5ZFjYa3jjAVjjM5+CgOu5G1lQFxe9frhqIjR2awWJZ DDcoCHk6+3WhzZ4S0HmhWwCyrWxVSABa7/62qM3N/+OmkdXhicoX63apxuadix28gxJr MAaKkSgCJGX+eRNokqCDAvwqWAuEM87DpRYN5rXHqqQlTM8MN8JLSUO2LCuOrcIvmMxO DRCg== 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=wE52dDGBB1IyA3KYJ/UgEqxa+4ale1VMkAnaVtJrmUQ=; b=SP8d5uvzpCl61+04+OAZCrBmVsdm3L+9b6gVBWowPtfqn37vaSA2F8IkjROVnt+jys PHG3JZBaTxSv3TZA8EHSg2Vu3RhBuDCNagAlASLJjMSBvtGSdj1TT0f5M/QNMkaHzZni 7ON9cR8w7/YuOXLUpinqK1DF8/rC4KNiH02jJLYQ3hXA8R0ktkmKrtApzCtYjF8t3lhK xC4rjKRysiwhVUhyJHvgmf8r1UnAaNCnY9KIaztRBUBzJJS2pqIcknGJeQ+ToiYWaFyk a+dqfeVmELqCS7vB8UQ5KhLo+7ZR+7R6Roj9B28XonqB0s33pxhhNKFx2ucoXcVolXqD yxlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=E5AQZP5r; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v7si10379666edw.193.2020.06.16.06.59.29; Tue, 16 Jun 2020 06:59:51 -0700 (PDT) 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=@ellerman.id.au header.s=201909 header.b=E5AQZP5r; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728997AbgFPNz6 (ORCPT + 99 others); Tue, 16 Jun 2020 09:55:58 -0400 Received: from ozlabs.org ([203.11.71.1]:37287 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728908AbgFPNzz (ORCPT ); Tue, 16 Jun 2020 09:55:55 -0400 Received: by ozlabs.org (Postfix, from userid 1034) id 49mV8l58Vcz9sT6; Tue, 16 Jun 2020 23:55:51 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1592315751; bh=KyN/8xEV1ocUHJUV+svHFzygU+CKYg1ZOnKHC5triV4=; h=From:To:Cc:Subject:Date:From; b=E5AQZP5r9bIEHpD7dBNDSa1Gd4Pp4mQa23qIcRl+V41xprJ/mCcEl0ve5r7DhrqiW YpQes4BXZnfCAr/ZYh7mp8YD6L39BAGqbFnr5cbuAolScyOTMtYvkEvxXacK9a9DU6 SGAuL/0Y3LeyPeVHxQDc7O5ET7tAavb8ss4IS5v1qeoRRUiQ/yJkfxJMq6jbr++jKZ A7FIgtw0Crbi5i/Nh/vSr2x0cTKqjsqUdgLpHDu7wnu8dmxbbcUyK8DI+f/ZXDlm/k bVXPj94vvbHhNHH7l5orReLRlv+ow0NEhvFeG2ourmrEUKL+iw1QrovJrPKeRzN0yO EdoMnVWmgk6GQ== From: Michael Ellerman To: linuxppc-dev@ozlabs.org Cc: arnd@arndb.de, linux-arch@ozlabs.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] powerpc/syscalls: Use the number when building SPU syscall table Date: Tue, 16 Jun 2020 23:56:16 +1000 Message-Id: <20200616135617.2937252-1-mpe@ellerman.id.au> X-Mailer: git-send-email 2.25.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 Currently the macro that inserts entries into the SPU syscall table doesn't actually use the "nr" (syscall number) parameter. This does work, but it relies on the exact right number of syscall entries being emitted in order for the syscal numbers to line up with the array entries. If for example we had two entries with the same syscall number we wouldn't get an error, it would just cause all subsequent syscalls to be off by one in the spu_syscall_table. So instead change the macro to assign to the specific entry of the array, meaning any numbering overlap will be caught by the compiler. Signed-off-by: Michael Ellerman Acked-by: Arnd Bergmann Link: https://lore.kernel.org/r/20190116132714.20094-1-mpe@ellerman.id.au --- arch/powerpc/platforms/cell/spu_callbacks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/spu_callbacks.c b/arch/powerpc/platforms/cell/spu_callbacks.c index cbee3666da07..abdef9bcf432 100644 --- a/arch/powerpc/platforms/cell/spu_callbacks.c +++ b/arch/powerpc/platforms/cell/spu_callbacks.c @@ -35,7 +35,7 @@ */ static void *spu_syscall_table[] = { -#define __SYSCALL(nr, entry) entry, +#define __SYSCALL(nr, entry) [nr] = entry, #include #undef __SYSCALL }; -- 2.25.1