From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EBFD3C433E0 for ; Mon, 25 May 2020 16:39:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C19D72070A for ; Mon, 25 May 2020 16:39:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=wdc.com header.i=@wdc.com header.b="VWjWo/Z2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731404AbgEYQjV (ORCPT ); Mon, 25 May 2020 12:39:21 -0400 Received: from esa5.hgst.iphmx.com ([216.71.153.144]:38488 "EHLO esa5.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726308AbgEYQjV (ORCPT ); Mon, 25 May 2020 12:39:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1590424760; x=1621960760; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=HjJ4fGKEInmzonc7zQeX2eEbQNJ3W01PKn/mnbplM8o=; b=VWjWo/Z2Fy56/QEiit5MK2l2mrSsYsOFw0HZVVTAQ6qC3Xe93AXye9D2 i0vfoZOgBoRPpNXfjAz9lIUOzZQSF9vBLmvJF5XvqBKvZGsAcd1pGxyYw 0eNZsaAIvMWJjVud/Z99AhT5wc+Qg9sSX0ZXo8CFhVpK7pAX/vJNek2CM rhkBNVSeGI6Je0IAWgnl+AYlk8s5g0HPQbEAXT5NzIL/r7r2A/Jtm14HU 3zSYfAMH7xJsEb+yGgRofrK5nSTeDa/C+60HTOyvX4N417UyPPIFMxd0y CpNGbLTpZhoaApc8brIVDH20doQxXgQoW60IdeT7NqbOA5v/9yN76LdmH Q==; IronPort-SDR: nMAhItbKPzsGT7R1xqIWjS66sMna08hJjvv0Ge+rZqIx5d02yITyFXC2+AwwSKu9+wS4O83z+5 FHv7rA/63KfPEM+zwMsdAYZIhe3qcBZvSX4KCzO0TkGd8S0x1XPHPxbWnaB6v2JBP9Al46wqS4 Cj5XB+Itt6ZIoaUnVQrTTg1mH1NJjilWlMkTryn7MUgm96uuDHYg3740LEwNI/vddZGjDXFz6v C7fOce6/0oZDoTjtqyoFttw+Uad6a+elrwWtUyDtk0lPOAMUy5azDzv6ZTdxkw1R8hD3ZpLyXt cYM= X-IronPort-AV: E=Sophos;i="5.73,434,1583164800"; d="scan'208";a="138792852" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 26 May 2020 00:39:20 +0800 IronPort-SDR: kdf1EtpkbUW+wedxlxDcIiZ3CDrKAbVRaxzF+lTv6e3wPBbP5irBwDkkz/VzUJ3ZJ7lroljtiW zoe/sa/dd3icH3vBKF0qVrC1jwj/JMq+A= Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2020 09:29:14 -0700 IronPort-SDR: bf0q3x4MbLY/3guTDJvLc8c+Zhu6WJ+c86jfkFDKK1LqYwmU9+Uk6oi7jBNAcb2V6e8PXWdA+6 yFUa6Xc240Jw== WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2020 09:39:17 -0700 Date: Mon, 25 May 2020 17:39:14 +0100 (BST) From: "Maciej W. Rozycki" To: Mikulas Patocka cc: Ivan Kokshaysky , "Maciej W. Rozycki" , Arnd Bergmann , Richard Henderson , Matt Turner , Greg Kroah-Hartman , alpha , linux-serial@vger.kernel.org, linux-rtc@vger.kernel.org Subject: Re: [PATCH v5] alpha: fix memory barriers so that they conform to the specification In-Reply-To: Message-ID: References: <20200513144128.GA16995@mail.rc.ru> <20200523151027.GA10128@mail.rc.ru> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-rtc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org On Mon, 25 May 2020, Mikulas Patocka wrote: > > > The functions __raw_read* are already extern inline, so the compiler will > > > inline/noinline them depending on the macros trivial_io_bw and > > > trivial_io_lq - so we can just call them from read*_relaxed without > > > repeating the extern inline pattern. > > > > The whole point of this peculiar arrangement for cooked accessors is to > > avoid having barriers inserted inline around out-of-line calls to raw > > accessors, > > I see, but why do we want to avoid that? Linux kernel has no binary > compatibility, so it doesn't matter if the barriers are inlined in the > drivers or not. It does matter as it expands code unnecessarily (at all call sites), as I noted in the original review. This has nothing to do with compatibility. > Anyway, I've sent a next version of the patch that makes read*_relaxed > extern inline. Thanks, I'll have a look. And now that you have this update, please run `size' on ALPHA_GENERIC `vmlinux', preferably monolithic, to see what the difference is between `read*_relaxed' handlers `static inline' and keyed with `*trivial_rw_*'. Maciej