Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8364950ybl; Thu, 16 Jan 2020 15:25:20 -0800 (PST) X-Google-Smtp-Source: APXvYqwATBGQIXrQMEQdfS9jXqLAU/1ievFizcsJRn9KL0VM0jHpvKk3j8UWg72FZWmTjrgWDkY8 X-Received: by 2002:a9d:da2:: with SMTP id 31mr4011839ots.319.1579217120237; Thu, 16 Jan 2020 15:25:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579217120; cv=none; d=google.com; s=arc-20160816; b=CnC2URLcVVI3NyyQ7SH69DKsQaYygDjEfjIQI7OGBkLpJB4txNvz57jKakPMVHj7kN wOhmLQyYc2eSolAg9nUyw4fyTsmIGZlTNk851qedgHYYHBNPuZ6oC1DYZ3Ym6zjxX2lx 4cOrMztPhDZU9y93fEtyEDB/8nNbX50gClgjdxbjVCI0rXKK7tqePpKbkRNAdz+viURv RtxM8z5WHHPh8x9XVxgxc6JKXYX5CKg6Sd8dGr+tf483CJ5DwxluDuq4qoi/QEYtQiME nJTXw7F9MAnTtiUt/GiyY2a+WSDlKU2B/jIHXckGrxb/RBFsZTLKYdZ5atMkBM1C0pZh uJjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=vPPz2KxZxdZZ+ecG6/sMMkz5CVao26O8S2gXjUgLJYw=; b=EkbyI+Nc0Cqi/AB27iutx9uCdOXoz7QXJ90dxRTLwR9qUWpyS2hyZXfheQ8+TKO1e6 IffABuzJ4imAISDDKFwP7li+yKJI8+2b8VihHZbfPtkdFCwYH9ToAl0ENXHLHOWkR/Q0 vA9M0ChNegB3HG2lqMimUHqVrjn2JDPNzR31QEjiFX0jzwD6gCSbXvqKfMZ7UlIlxjo4 mfTosszE/BKnC0OsVyXcTZOmASphochUIWKR4R/hrI61aC1mMuuEVtB6MVcbjmcqeQAi ZlL3OrrSW1LW0+3VOg9o+QeY8SIjSUX6uUhdd5mspJa4C08OuIoJhy5AgY/Z+IMj4QaM +qGA== ARC-Authentication-Results: i=1; mx.google.com; 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 l6si4473921otk.134.2020.01.16.15.25.06; Thu, 16 Jan 2020 15:25:20 -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; 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 S2387532AbgAPUOJ (ORCPT + 99 others); Thu, 16 Jan 2020 15:14:09 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:53240 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729030AbgAPUOJ (ORCPT ); Thu, 16 Jan 2020 15:14:09 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1isBWc-0000Wb-NU; Thu, 16 Jan 2020 21:13:54 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id F20D7101226; Thu, 16 Jan 2020 21:13:53 +0100 (CET) From: Thomas Gleixner To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , nathanl@linux.ibm.com, arnd@arndb.de, vincenzo.frascino@arm.com, luto@kernel.org Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, x86@kernel.org Subject: Re: [RFC PATCH v4 08/11] lib: vdso: allow fixed clock mode In-Reply-To: <1b278bc1f6859d4df734fb2cde61cf298e6e07fd.1579196675.git.christophe.leroy@c-s.fr> References: <1b278bc1f6859d4df734fb2cde61cf298e6e07fd.1579196675.git.christophe.leroy@c-s.fr> Date: Thu, 16 Jan 2020 21:13:53 +0100 Message-ID: <874kwvf9by.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: Can you please adjust the prefix for future patches to lib/vdso: and start the sentence after the colon with an uppercase letter? > On arches like POWERPC, the clock is always the timebase, it Please spell out architectures. Changelogs are not space constraint. > cannot be changed on the fly and it is always VDSO capable. Also this sentence does not make sense as it might suggests that architectures with a fixed compile time known clocksource have something named timebase. Something like this is more clear: Some architectures have a fixed clocksource which is known at compile time and cannot be replaced or disabled at runtime, e.g. timebase on PowerPC. For such cases the clock mode check in the VDSO code is pointless. Hmm? Thanks, tglx