From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933919AbcHaLtA (ORCPT <rfc822;w@1wt.eu>);
        Wed, 31 Aug 2016 07:49:00 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:36326 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S933252AbcHaLs4 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 31 Aug 2016 07:48:56 -0400
Date: Wed, 31 Aug 2016 13:48:47 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
        Adam Buchbinder <adam.buchbinder@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        linux-kernel@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
        Markos Chandras <markos.chandras@imgtec.com>,
        Paul Burton <paul.burton@imgtec.com>
Subject: Re: [PATCH 06/10] MIPS: pm-cps: Use MIPS standard lightweight
 ordering barrier
Message-ID: <20160831114847.GB10153@twins.programming.kicks-ass.net>
References: <1472640279-26593-1-git-send-email-matt.redfearn@imgtec.com>
 <1472640279-26593-7-git-send-email-matt.redfearn@imgtec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1472640279-26593-7-git-send-email-matt.redfearn@imgtec.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Aug 31, 2016 at 11:44:35AM +0100, Matt Redfearn wrote:
> Since R2 of the MIPS architecture, SYNC(0x10) has been an optional but
> architecturally defined ordering barrier. If a CPU does not implement it,
> the arch specifies that it must fall back to SYNC(0).
> 
> Define the barrier type and always use it in the pm-cps code rather than
> falling back to the heavyweight sync(0) such that we can benefit from
> the lighter weight sync.
> 

Changelog does not explain what 0x10 is, nor why its sufficient for this
case.

Changelog also fails to explain why you do this.

How do you expect anybody to review this?