[6.0,659/862] =?UTF-8?q?ARM/dma-mapp=D1=96ng:=20dont=20override=20->dma=5Fcohe?= =?UTF-8?q?rent=20when=20set=20from=20a=20bus=20notifier?=
Commit Message
Greg KH
Oct. 19, 2022, 8:32 a.m. UTC
From: Christoph Hellwig <hch@lst.de> [ Upstream commit 49bc8bebae79c8516cb12f91818f3a7907e3ebce ] Commit ae626eb97376 ("ARM/dma-mapping: use dma-direct unconditionally") caused a regression on the mvebu platform, wherein devices that are dma-coherent are marked as dma-noncoherent, because although mvebu_hwcc_notifier() after that commit still marks then as coherent, the arm_coherent_dma_ops() function, which is called later, overwrites this setting, since it is being called from drivers/of/device.c with coherency parameter determined by of_dma_is_coherent(), and the device-trees do not declare the 'dma-coherent' property. Fix this by defaulting never clearing the dma_coherent flag in arm_coherent_dma_ops(). Fixes: ae626eb97376 ("ARM/dma-mapping: use dma-direct unconditionally") Reported-by: Marek Behún <kabel@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Marek Behún <kabel@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/arm/mm/dma-mapping.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
Comments
Hi Greg,
I'm seeing:
Subject: [PATCH 6.0 659/862]
=?UTF-8?q?ARM/dma-mapp=D1=96ng:=20dont=20override=20->dma=5Fcohe?=
=?UTF-8?q?rent=20when=20set=20from=20a=20bus=20notifier?=
in mutt, and mutt seems to be unable to decode that. Either a mutt
bug or a bug in your scripts or git...
Russell.
On Wed, Oct 19, 2022 at 10:32:26AM +0200, Greg Kroah-Hartman wrote:
> From: Christoph Hellwig <hch@lst.de>
>
> [ Upstream commit 49bc8bebae79c8516cb12f91818f3a7907e3ebce ]
>
> Commit ae626eb97376 ("ARM/dma-mapping: use dma-direct unconditionally")
> caused a regression on the mvebu platform, wherein devices that are
> dma-coherent are marked as dma-noncoherent, because although
> mvebu_hwcc_notifier() after that commit still marks then as coherent,
> the arm_coherent_dma_ops() function, which is called later, overwrites
> this setting, since it is being called from drivers/of/device.c with
> coherency parameter determined by of_dma_is_coherent(), and the
> device-trees do not declare the 'dma-coherent' property.
>
> Fix this by defaulting never clearing the dma_coherent flag in
> arm_coherent_dma_ops().
>
> Fixes: ae626eb97376 ("ARM/dma-mapping: use dma-direct unconditionally")
> Reported-by: Marek Behún <kabel@kernel.org>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Tested-by: Marek Behún <kabel@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> arch/arm/mm/dma-mapping.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 089c9c644cce..bfc7476f1411 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1769,8 +1769,16 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) { }
> void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> const struct iommu_ops *iommu, bool coherent)
> {
> - dev->archdata.dma_coherent = coherent;
> - dev->dma_coherent = coherent;
> + /*
> + * Due to legacy code that sets the ->dma_coherent flag from a bus
> + * notifier we can't just assign coherent to the ->dma_coherent flag
> + * here, but instead have to make sure we only set but never clear it
> + * for now.
> + */
> + if (coherent) {
> + dev->archdata.dma_coherent = true;
> + dev->dma_coherent = true;
> + }
>
> /*
> * Don't override the dma_ops if they have already been set. Ideally
> --
> 2.35.1
>
>
>
>
On Wed, Oct 19, 2022 at 10:14:11AM +0100, Russell King (Oracle) wrote: > I'm seeing: > > Subject: [PATCH 6.0 659/862] > =?UTF-8?q?ARM/dma-mapp=D1=96ng:=20dont=20override=20->dma=5Fcohe?= > =?UTF-8?q?rent=20when=20set=20from=20a=20bus=20notifier?= > > in mutt, and mutt seems to be unable to decode that. Either a mutt > bug or a bug in your scripts or git... The real problem was me fat fingering the comments and adding a non-ASCII "і" character instead of and "i" into the Subject. And then it somehow went downhill from there..
On Wed, Oct 19, 2022 at 10:14:11AM +0100, Russell King (Oracle) wrote: > Hi Greg, > > I'm seeing: > > Subject: [PATCH 6.0 659/862] > =?UTF-8?q?ARM/dma-mapp=D1=96ng:=20dont=20override=20->dma=5Fcohe?= > =?UTF-8?q?rent=20when=20set=20from=20a=20bus=20notifier?= > > in mutt, and mutt seems to be unable to decode that. Either a mutt > bug or a bug in your scripts or git... It's probably between git and quilt and somewhere. The issue is that the original commit's subject line is: ARM/dma-mappіng: don't override ->dma_coherent when set from a bus notifier Note the 'і' character in there, which then causes git to emit a subject line that looks like: Subject: [PATCH] =?UTF-8?q?ARM/dma-mapp=D1=96ng:=20don't=20override=20->dm?= =?UTF-8?q?a=5Fcoherent=20when=20set=20from=20a=20bus=20notifier?= which is technically correct. Then quilt comes along and adds it's own counting of the patch and treats the whole thing as the subject and something gets confused. Anyway, I'll go drop the funny 'і' and turn it into ascii only for the subject line. thanks, greg k-h
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 089c9c644cce..bfc7476f1411 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1769,8 +1769,16 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) { } void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, const struct iommu_ops *iommu, bool coherent) { - dev->archdata.dma_coherent = coherent; - dev->dma_coherent = coherent; + /* + * Due to legacy code that sets the ->dma_coherent flag from a bus + * notifier we can't just assign coherent to the ->dma_coherent flag + * here, but instead have to make sure we only set but never clear it + * for now. + */ + if (coherent) { + dev->archdata.dma_coherent = true; + dev->dma_coherent = true; + } /* * Don't override the dma_ops if they have already been set. Ideally