Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 17 May 2018 15:30:47 +0100
From:   James Hogan <jhogan@kernel.org>
To:     Matt Redfearn <matt.redfearn@mips.com>
Cc:     Ralf Baechle <ralf@linux-mips.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
        Philippe Ombredanne <pombredanne@nexb.com>,
        Kate Stewart <kstewart@linuxfoundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 1/6] MIPS: Move ehb() to barrier.h
Message-ID: <20180517143046.GA24704@jamesdev>
References: <1515148270-9391-1-git-send-email-matt.redfearn@mips.com>
 <1515148270-9391-2-git-send-email-matt.redfearn@mips.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
Content-Disposition: inline
In-Reply-To: <1515148270-9391-2-git-send-email-matt.redfearn@mips.com>
User-Agent: Mutt/1.9.5 (2018-04-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Fri, Jan 05, 2018 at 10:31:05AM +0000, Matt Redfearn wrote:
> The current location of ehb() in mipsmtregs.h does not make sense, since
> it is not strictly related to multi-threading, and may be used in code
> which does not include mipsmtregs.h

>  arch/mips/include/asm/barrier.h    | 13 +++++++++++++
>  arch/mips/include/asm/mipsmtregs.h |  8 --------

But ehb isn't really a memory barrier like the other barriers in
barrier.h, its an execution hazard barrier, as used when available by
the hazard macros in hazards.h, and in fact there is already an _ehb()
there.

I suspect the intention was that most MIPS arch code using ehb would do
so using the appropriate hazard abstractions, which would do the right
number of NOPs on hardware without the EHB instruction. Code that is
specific to certain arch revisions (like the MIPS MT code and MIPS KVM)
can get away with using _ehb/ehb, but should use the abstractions where
they exist to make intentions clear.

None of the specific hazards in hazards.h really match the case in patch
2, I suppose you could have a new sync_mfc0_hazard() macro, but its so
specific and EHB should be guaranteed to exist there, so perhaps _ehb()
should just be used instead of ehb() there? (with a comment to describe
what operations are being protected from what hazards).

Cheers
James

--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQS7lRNBWUYtqfDOVL41zuSGKxAj8gUCWv2SFQAKCRA1zuSGKxAj
8g1NAQDbRoahEifuu6/yUogKV60Ye0OY1HPN5uhoF/Sps8q+6AD8DQ8sqzB6icvF
yii4y7HzTo+e6WZ7o9i1Z1pm2g8YqgA=
=6e5S
-----END PGP SIGNATURE-----

--fUYQa+Pmc3FrFX/N--