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.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 F37C7C433DF for ; Mon, 25 May 2020 15:54:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFB9F2071A for ; Mon, 25 May 2020 15:54:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eDfxjlZZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391101AbgEYPyg (ORCPT ); Mon, 25 May 2020 11:54:36 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:28442 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2391055AbgEYPyg (ORCPT ); Mon, 25 May 2020 11:54:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590422075; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=G5HlSdeXArcl1605FHe8FaMeiLyTdkgKVGZzS1ZjLN4=; b=eDfxjlZZYH4WE81OhZwHqVH8g5m6oIQsifHDQC/iLGA77/CRg7/QBZF9/FEl0XwfG9e4Fk XghJZxaJ8aAHq+nBDPfEAirr8WIAgTLB/tMtzSVmg0EoV3kyK3rbS0B36tRZzVs/RwRSC8 /VL9VSZetPNnVw/AmneiQUfwT8iTzv4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-354-3grEl76VPr20ohY9Z3MxjA-1; Mon, 25 May 2020 11:54:33 -0400 X-MC-Unique: 3grEl76VPr20ohY9Z3MxjA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D4595802EAC; Mon, 25 May 2020 15:54:31 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B306360C47; Mon, 25 May 2020 15:54:31 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id 04PFsVKW004355; Mon, 25 May 2020 11:54:31 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id 04PFsVMt004352; Mon, 25 May 2020 11:54:31 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Mon, 25 May 2020 11:54:31 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: "Maciej W. Rozycki" 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.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-rtc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org On Mon, 25 May 2020, Maciej W. Rozycki wrote: > 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. Anyway, I've sent a next version of the patch that makes read*_relaxed extern inline. Mikulas