Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp4265796pxb; Mon, 21 Feb 2022 16:24:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJzb3WSH7PLlIL/6nKylPCayYlJpfuD6/xz9gs/GxM9dhtv0WCI7tWzRdqqSQu2oSdLqLKx9 X-Received: by 2002:aa7:cb8b:0:b0:410:9aaf:2974 with SMTP id r11-20020aa7cb8b000000b004109aaf2974mr23461545edt.173.1645489448791; Mon, 21 Feb 2022 16:24:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645489448; cv=none; d=google.com; s=arc-20160816; b=Rny1d1+ba4+09rbQY7RMZRBCV6IehKx8GLOY1tlJUpsiWr7816hB/53kxlagAPv8et DTKy0J7vcg7icqyvaeb+PcFtTAjb+rKnDJHhMAlEPhYgYl+XFTgMVP5iupgqCpZxG68p vieTNGQn/LaAq+D5P6tqNFm/Wifs/8dy58tU5IbzjV9xKpHqnouPsKm1Q0vbr1aByy0N ufC7uk6770OX+ko2rbX1+493C8StM7Xx8g88yPZFjxtHXm+3ILQPomKelSQelcOyDc6v tKPeqZvBQBLLom3FsOnbSypSCDw5GcdbFFpstJcS/wz6T2CEtSXSd/RRpQEa6Ve3yrA5 G4Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=OWrmBNNFqr9F8ccKULcIyrqRSTRD8D7/P85FsXWhf3M=; b=Cjq75IF9X1DGObFt3RMUOfI95FB5luD7EZ+hVX01hz9fM2VGq/TCcU1u1ha34HM1mV rxVg14S27GN5Bc1sikdEnyit5ZeshosCRzLKfgdaRwWugZ+RxgVhDd5Av2l+ya/LxakE w7PuyWYA7/7U3sDQujyZuRDuE/6bEILVxeMgmVpu4ANJDp3AofG1OoPCHra8F5PV4mE1 U88vXf6tu9fRo6H27MsvqUk5RscYcz2eMprvKONQBD3cdWCepT2WUh5LJEfTlgiHfhl1 rR2TVuw5G+B+rXdk4l8SN1xAqmyLnoOG+cW9f42GndG14uPyVM1cUDpGYFP8W2azeIaA sOwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ec5si9853482ejb.668.2022.02.21.16.23.44; Mon, 21 Feb 2022 16:24:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380925AbiBUQne (ORCPT + 99 others); Mon, 21 Feb 2022 11:43:34 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:57604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbiBUQnc (ORCPT ); Mon, 21 Feb 2022 11:43:32 -0500 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 219881EC6B; Mon, 21 Feb 2022 08:43:09 -0800 (PST) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 507BA92009C; Mon, 21 Feb 2022 17:43:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 49BE692009B; Mon, 21 Feb 2022 16:43:07 +0000 (GMT) Date: Mon, 21 Feb 2022 16:43:07 +0000 (GMT) From: "Maciej W. Rozycki" To: Jiaxun Yang cc: linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, chenhuacai@kernel.org, tsbogend@alpha.franken.de Subject: Re: [RFC PATCH 3/3] MIPS: io.h: Remove barriers before MMIO accessors for CPU without WB In-Reply-To: <20220221145531.10479-4-jiaxun.yang@flygoat.com> Message-ID: References: <20220221145531.10479-1-jiaxun.yang@flygoat.com> <20220221145531.10479-4-jiaxun.yang@flygoat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 Feb 2022, Jiaxun Yang wrote: > Commit 3d474da ("MIPS: Enforce strong ordering for MMIO accessors") Please follow the canonical commit reference format including a 12-digit hexadecimal hash reference (`scripts/checkpatch.pl' would have pointed it out). > SYNC based barrier is very heavy on Loongson and MTI cores as it will > issue a SYNC command on their bus and invalidate all present instrutions > in pipeline. We should generally avoid that. Use whatever lighterweight barrier instruction you have available for your specific platforms then that fulfills the ordering enforcement required here for your specific platforms of concern that you have identified and know well rather than across the board. The reason for this is this is an optimisation and the default barrier model needs to ensure correct execution with any implementation. Maciej