Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1465673pxk; Fri, 4 Sep 2020 10:00:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyz2Y21ZwGdwUP1UC06j+FjgFhO5JkbR+aqBSSkaoysdePm7pS8NcFoF6hsR6qBMj9Ag9ED X-Received: by 2002:a17:906:3a81:: with SMTP id y1mr8049779ejd.464.1599238844801; Fri, 04 Sep 2020 10:00:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599238844; cv=none; d=google.com; s=arc-20160816; b=m8Keq8sjaFOsehgya+qD/9iiHPKrXz/ygU19drdlZVuQwxeMr4AIFRfWx87svWu6tT 0SlIyLJhQrrO81p+Awn/WWALrXKW99Z0KZlvdqd5yFcyg0gM3E7muRVaQ3Xu87aOP2oM gquVUO4ep3b/y7E4x/9IRBYvIV4x4FCqqTa9T8foFtyeY1XVymOWDdD0VjjSu7ABxisY gD2JTJSFb5MJdhMJejc/nes0wrr9UM79k0LyaQ08e3Os/EwW/T9w1DoNq+SvjP9Zv9T6 8xvfEsboSxNp4DOMlWBzCjtlMc+GO1f4qgFOp1vL9SGlhkv06hph5UUkny3b1P0DKZwu 8reg== 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; bh=kxob697le6Ql6PUONYoI2Q1nJYFXaWfuOlsb53QIt14=; b=CBxVyWYh2dwSTji7CivCuebqHEc4SKF1RWjyq1Pbm/QG0GBfyiZKtyD1PN3dXnU9eO KiCIYPC2/XCUzveGXOUPZNkXICB+qhJcn3myWkrQrjlOzBZdGgEOY8ZMMKeJm9f9R7O1 14slBALRm751GB6up+5eOdcRQ3NTxvvCOFh57l9FdrXDfYkIrPCOSy3KKPBoLcvCUHe+ SV83eVMXOJdSddImDdqRxIZm/FA+2tHXXI0u3tuPEt3mj3tmoxkgdWGPHC+qLqTC7gKq NniKlfzONvUFK/rvOB5kQfEU9EJ8OfRZCqmEx14j+jOPJxo3N/yxyXqKL1XpTSVIol6c DbJA== ARC-Authentication-Results: i=1; mx.google.com; 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 c7si2085320edl.290.2020.09.04.10.00.18; Fri, 04 Sep 2020 10:00:44 -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; 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 S1727769AbgIDQ5P (ORCPT + 99 others); Fri, 4 Sep 2020 12:57:15 -0400 Received: from verein.lst.de ([213.95.11.211]:42596 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726135AbgIDQ5N (ORCPT ); Fri, 4 Sep 2020 12:57:13 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 64FF168BEB; Fri, 4 Sep 2020 18:57:09 +0200 (CEST) Date: Fri, 4 Sep 2020 18:57:09 +0200 From: Christoph Hellwig To: Anup Patel Cc: Christoph Hellwig , Anup Patel , Palmer Dabbelt , Palmer Dabbelt , Paul Walmsley , Albert Ou , Atish Patra , Alistair Francis , linux-riscv , "linux-kernel@vger.kernel.org List" , Linus Torvalds Subject: Re: [PATCH] RISC-V: Allow drivers to provide custom read_cycles64 for M-mode kernel Message-ID: <20200904165709.GA32667@lst.de> References: <20200904162121.279578-1-anup.patel@wdc.com> <20200904162530.GA32095@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 04, 2020 at 10:13:18PM +0530, Anup Patel wrote: > I respectfully disagree. IMHO, the previous code made the RISC-V > timer driver convoluted (both SBI call and CLINT in one place) and > mandated CLINT for NoMMU kernel. In fact, RISC-V spec does not > mandate CLINT or PLIC. The RISC-V SOC vendors are free to > implement their own timer device, IPI device and interrupt controller. Yes, exactly what we need is everyone coming up with another stupid non-standard timer and irq driver. But the point is this crap came in after -rc1, and it adds totally pointless indirect calls to the IPI path, and with your "fix" also to get_cycles which all have exactly one implementation for MMU or NOMMU kernels. So the only sensible thing is to revert all this crap. And if at some point we actually have to deal with different implementations do it with alternatives or static_branch infrastructure so that we don't pay the price for indirect calls in the super hot path.