Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5607824ybl; Tue, 27 Aug 2019 07:13:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDlyVrc0e9wCUVplXMT9HHLADL+1uPz2Qj0C9vm9ThpaOFKMsLMPdGu8lN+0BbTq6iQHZg X-Received: by 2002:a17:90a:246f:: with SMTP id h102mr25471388pje.125.1566915190492; Tue, 27 Aug 2019 07:13:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566915190; cv=none; d=google.com; s=arc-20160816; b=RX7DECVAtCWiw/etJKcdLHPWt2AQvwHAr5py0kQiYemW+CMCu5SjDirv2zWh5Scvfx yeQ/HxCc6AJ/91YUfjtP2LU02dns76IEMnpI7aJLQ0eUbkeEgKZTL0eXCuM0ueXAr1oZ 3j/2SXSWH7whURfu0sSX/j/Q11kwWJLxYadaBVtsDIxhjxCPbeDAkxK9f+0xi1SgVHQo c1ImXttE2ZTN4z87B+T0IFY+8ZyxhS6fQV4epZYvt9/T9G6Y2pwb52jtxoOJTkSjMKG6 5tC6x+dNOHCJCqrkL4ziddxrwMlCoUhBujZhW0x9NrT+D3qnBDoLd8mPZyjCKiyLqLvF hYQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Jn68BdvZhJrmEXMt74AaFJ4t5OFYoY/FSvB04ozunVk=; b=ZfGlZdoO4h3wugpnLcN3+j5aZ1gBtSLFuAIBGhiNHnCYJxfh7t7ZJO+VFW7jISiWD1 cUCQNB9UF2fJZQXnZWJ/KTUNaZA1P7QaVrSTaspud+YTnC6Y+PbYUhMxcyT1+HRopxrR ywV4N3WEPooE9h+BMcDqtbBjnapCr0uP9oyd0DXmXXn5DwSTGAAQq9xghE6LbCShgDWy eTlMBr1v2S2wVQEK4IITqsOtJL6nn+lFuPVYCJmKY31RAt4KOTP902b5BOFaN4mMUtl+ UTYbBb3HNUF3yLicGFZ0Lj0AcugoJFxntvUyB1k6oJJgskmJ73JSq02bezhUPVUsUecu fE2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=Sf8vBT1T; 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 j23si12055602pfr.41.2019.08.27.07.12.54; Tue, 27 Aug 2019 07:13:10 -0700 (PDT) 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=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=Sf8vBT1T; 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 S1729588AbfH0OLb (ORCPT + 99 others); Tue, 27 Aug 2019 10:11:31 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:45416 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725920AbfH0OLb (ORCPT ); Tue, 27 Aug 2019 10:11:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Jn68BdvZhJrmEXMt74AaFJ4t5OFYoY/FSvB04ozunVk=; b=Sf8vBT1TC/Qn3jbU46GFV/fPn pY8Os4CfxDsanw82XFqNEsUjR1fk17yNzSxH4zqssCMYkJL5uctl2L7st0SqAtQQApp5NpN66RiY4 2t6KLu2SyF1PnMFxashJAtAxDl0BZDbNRQ5zlt6mwkgszxFilA7z2vWvidwev8jRCJ6ozoUZOw5UL 2gvXPcB1c2CgNW6B9lvVv3Tulb5MfEEX+22aMo6CPZVPKIZRyW0YpvzJstm3OPDUt+ybRKsEWlUzt t5PHAQvzzeZx2LXhVWxxdP+cO88KmEZU16ozAFDTQwNyF9eilVKc/9LDY9vZ7F/DEABmHkjQQ0dhH RywpB7qDw==; Received: from hch by bombadil.infradead.org with local (Exim 4.92 #3 (Red Hat Linux)) id 1i2cC2-0007KK-LQ; Tue, 27 Aug 2019 14:11:30 +0000 Date: Tue, 27 Aug 2019 07:11:30 -0700 From: Christoph Hellwig To: Atish Patra Cc: linux-kernel@vger.kernel.org, Albert Ou , Alan Kao , Alexios Zavras , Anup Patel , Palmer Dabbelt , Mike Rapoport , Paul Walmsley , Gary Guo , Greg Kroah-Hartman , linux-riscv@lists.infradead.org, Thomas Gleixner Subject: Re: [RFC PATCH 2/2] RISC-V: Add basic support for SBI v0.2 Message-ID: <20190827141130.GC21855@infradead.org> References: <20190826233256.32383-1-atish.patra@wdc.com> <20190826233256.32383-3-atish.patra@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190826233256.32383-3-atish.patra@wdc.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +#define SBI_EXT_BASE 0x10 I think you want an enum enumerating the extensions. > +#define SBI_CALL_LEGACY(ext, fid, arg0, arg1, arg2, arg3) ({ \ > register uintptr_t a0 asm ("a0") = (uintptr_t)(arg0); \ > register uintptr_t a1 asm ("a1") = (uintptr_t)(arg1); \ > register uintptr_t a2 asm ("a2") = (uintptr_t)(arg2); \ > register uintptr_t a3 asm ("a3") = (uintptr_t)(arg3); \ > - register uintptr_t a7 asm ("a7") = (uintptr_t)(which); \ > + register uintptr_t a6 asm ("a6") = (uintptr_t)(fid); \ > + register uintptr_t a7 asm ("a7") = (uintptr_t)(ext); \ This seems to break the calling convention. I also think we should go back to the Unix platform working group and make the calling convention backwards compatible. There is really no advantage or disadvantag in swapping a6 and a7 in the calling convention itself, but doing so means you can just push the ext field in always and it will be ignored by the old sbi. > +struct sbiret riscv_sbi_ecall(int ext, int fid, int arg0, int arg1, > + int arg2, int arg3); > + > +#define SBI_CALL_0(ext, fid) riscv_sbi_ecall(ext, fid, 0, 0, 0, 0) > +#define SBI_CALL_1(ext, fid, arg0) riscv_sbi_ecall(ext, fid, arg0, 0, 0, 0) > +#define SBI_CALL_2(ext, fid, arg0, arg1) \ > + riscv_sbi_ecall(ext, fid, arg0, arg1, 0, 0) > +#define SBI_CALL_3(ext, fid, arg0, arg1, arg2) \ > + riscv_sbi_ecall(ext, fid, arg0, arg1, arg2, 0) > +#define SBI_CALL_4(ext, fid, arg0, arg1, arg2, arg3) \ > + riscv_sbi_ecall(ext, fid, arg0, arg1, arg2, arg3) Again, no point in having these wrappers. > +struct sbiret riscv_sbi_ecall(int ext, int fid, int arg0, int arg1, > + int arg2, int arg3) > +{ > + struct sbiret ret; > + > + register uintptr_t a0 asm ("a0") = (uintptr_t)(arg0); > + register uintptr_t a1 asm ("a1") = (uintptr_t)(arg1); > + register uintptr_t a2 asm ("a2") = (uintptr_t)(arg2); > + register uintptr_t a3 asm ("a3") = (uintptr_t)(arg3); > + register uintptr_t a6 asm ("a6") = (uintptr_t)(fid); > + register uintptr_t a7 asm ("a7") = (uintptr_t)(ext); > + asm volatile ("ecall" > + : "+r" (a0), "+r" (a1) > + : "r" (a2), "r" (a3), "r" (a6), "r" (a7) > + : "memory"); > + ret.error = a0; > + ret.value = a1; > + > + return ret; Again much simpler done in pure asm.. > + /* legacy SBI version*/ > + sbi_firmware_version = 0x1; > + ret = sbi_get_spec_version(); > + if (!ret.error) > + sbi_firmware_version = ret.value; Why not: ret = sbi_get_spec_version(); if (ret.error) sbi_firmware_version = 0x1; /* legacy SBI */ else sbi_firmware_version = ret.value; btw, I'd find a calling convention that returns the value as a pointer much nicer than the return by a struct. Yes, the RISC-V ABI still returns that in registers, but it is a pain in the b**t to use. Without that we could simply pass the variable to fill by reference.