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;
Date:   Mon, 21 Feb 2022 16:38:15 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Jiaxun Yang <jiaxun.yang@flygoat.com>
cc:     linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
        chenhuacai@kernel.org,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: [RFC PATCH 0/3] MIPS: Chaos of barrier misuses
In-Reply-To: <20220221145531.10479-1-jiaxun.yang@flygoat.com>
Message-ID: <alpine.DEB.2.21.2202211602080.56785@angie.orcam.me.uk>
References: <20220221145531.10479-1-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
Precedence: bulk

On Mon, 21 Feb 2022, Jiaxun Yang wrote:

> This series clears the chaos of barrier misuse.
> In prepration of light weight barrier series.

 What problem are you trying to solve here?

 The MIPS port currently implements the semantics documented in
Documentation/memory-barriers.txt, in particular the "KERNEL I/O BARRIER 
EFFECTS" section, with extra I/O barriers borrowed from the PowerPC port 
for consistency for platform use, due to the weakly ordered architectural 
MMIO model (implementations are allowed to have a stronger model in place 
of course, and you are free to optimise for them with the respective 
configurations).

 Stating that we have a "chaos of barrier misuse" doesn't say anything 
really in my opinion and isn't particularly constructive either.  This 
area is very fragile and you need to understand all the consequences when 
trying to make any changes here and show it with your submission, that is 
properly describe and justify your changes so that people are convinced 
your changes are correct and good to make.

  Maciej