[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190807054431.GA6475@lst.de>
Date: Wed, 7 Aug 2019 07:44:31 +0200
From: Christoph Hellwig <hch@....de>
To: Sasha Levin <sashal@...nel.org>
Cc: Robin Murphy <robin.murphy@....com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Fugang Duan <fugang.duan@....com>,
Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 5.2 073/131] dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device
On Tue, Aug 06, 2019 at 06:04:48PM -0400, Sasha Levin wrote:
> On Tue, Aug 06, 2019 at 01:57:56PM +0100, Robin Murphy wrote:
>> Given that the two commits touch entirely separate files I'm not sure what
>> the imagined dependency could be :/
>
>> From the commit message of 3de433c5b38a ("drm/msm: Use the correct
> dma_sync calls in msm_gem"):
>
> Fixes the combination of two patches:
>
> Fixes: 0036bc73ccbe (drm/msm: stop abusing dma_map/unmap for cache)
> Fixes: 449fa54d6815 (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device)
>
>> 0036bc73ccbe is indeed not a fix (frankly I'm not convinced it's even a
>> valid change at all) but even conceptually it bears no relation whatsoever
>> to the genuine bug fixed by 449fa54d6815.
>
> Given that Rob Clark asked me to drop 0036bc73ccbe not because it's
> irrelevant but because it's potentially dangerous, I did not feel
> confident enough ignoring the statement in the commit message and
> dropped this patch instead.
449fa54d6815 fixes swiotlb misbehaving vs the API spec for the call,
something that real users on x86 cought. Robs fix works around the
fact that msm is badly abusing dma API. So even if both are genuine
bugs it is pretty clear we need to decide the match for the proper
users of the API and not the single abuser.
Powered by blists - more mailing lists