Hello, Ingo,
This pull request contains additions to the memory-barrier documentation,
along with a downgrading of UNLOCK+LOCK to no longer be a full memory
barrier, and finally an smp_mb__after_unlock_lock() that allows upgrading
a particular LOCK to pair with a preceding UNLOCK to form a full me
> -Original Message-
> From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
> Sent: Thursday, December 12, 2013 1:24 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Alexey Kardashevskiy; Benjamin Herrenschmidt; Bhushan Bharat-R65777; Alex
> Graf; linux-ker...@vger.kernel.org
> Subject: [PATCH
> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, December 14, 2013 2:33 AM
> To: Alexey Kardashevskiy
> Cc: linuxppc-dev@lists.ozlabs.org; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Alex Williamson; Paul Mackerras; David Gibson; Sethi
> Varun-B16395; Bhushan Bh
On Fri, 2013-12-13 at 14:02 +1100, Alexey Kardashevskiy wrote:
> On 12/13/2013 10:35 AM, Scott Wood wrote:
> > On Tue, May 21, 2013 at 01:33:09PM +1000, Alexey Kardashevskiy wrote:
> >> +static int iommu_add_device(struct device *dev)
> >> +{
> >> + struct iommu_table *tbl;
> >> + int ret = 0;
>
On 12/09/2013 11:51 AM, Michael Ellerman wrote:
>
> As I said in my comments on version 3 which you ignored:
>
> I think it would be clearer if we actually checked for the possibilities
> we
> allow and let everything else fall through, eg:
>
> Â Â Â Â Â Â Â Â /* Ignore user/kernel/hv b
