All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <treding@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: iommu@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, m.szyprowski@samsung.com,
	hch@lst.de, rmk+kernel@armlinux.org.uk, bskeggs@redhat.com,
	tjakobi@math.uni-bielefeld.de, b.zolnierkie@samsung.com
Subject: Re: [PATCH] ARM: dma-mapping: Clear DMA ops on teardown
Date: Mon, 21 Jan 2019 16:34:40 +0100	[thread overview]
Message-ID: <20190121153439.GA21078@ulmo> (raw)
In-Reply-To: <2f5833b7639543d614095cd3f5ab0dc0274e26d6.1548081277.git.robin.murphy@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Mon, Jan 21, 2019 at 02:52:16PM +0000, Robin Murphy wrote:
> Installing the appropriate non-IOMMU DMA ops in arm_iommu_detch_device()
> serves the case where IOMMU-aware drivers choose to control their own
> mapping but still make DMA API calls, however it also affects the case
> when the arch code itself tears down the mapping upon driver unbinding,
> where the ops now get left in place and can inhibit arch_setup_dma_ops()
> on subsequent re-probe attempts.
> 
> Fix the latter case by making sure that arch_teardown_dma_ops() cleans
> up whenever the ops were automatically installed by its counterpart.
> 
> Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Fixes: 1874619a7df4 "ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()"
> Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> 
> Sorry for the delay - there was a giant email infrastructure cock-up just
> at the point I wanted to go back through my archive and double-check the
> discussion around the original commit...
> 
> Robin.
> 
>  arch/arm/mm/dma-mapping.c | 2 ++
>  1 file changed, 2 insertions(+)

I had also tested your draft on Tegra last week and this looks
identical, so:

Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <treding@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: b.zolnierkie@samsung.com, rmk+kernel@armlinux.org.uk,
	linux-kernel@vger.kernel.org, tjakobi@math.uni-bielefeld.de,
	iommu@lists.linux-foundation.org, bskeggs@redhat.com, hch@lst.de,
	linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com
Subject: Re: [PATCH] ARM: dma-mapping: Clear DMA ops on teardown
Date: Mon, 21 Jan 2019 16:34:40 +0100	[thread overview]
Message-ID: <20190121153439.GA21078@ulmo> (raw)
In-Reply-To: <2f5833b7639543d614095cd3f5ab0dc0274e26d6.1548081277.git.robin.murphy@arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]

On Mon, Jan 21, 2019 at 02:52:16PM +0000, Robin Murphy wrote:
> Installing the appropriate non-IOMMU DMA ops in arm_iommu_detch_device()
> serves the case where IOMMU-aware drivers choose to control their own
> mapping but still make DMA API calls, however it also affects the case
> when the arch code itself tears down the mapping upon driver unbinding,
> where the ops now get left in place and can inhibit arch_setup_dma_ops()
> on subsequent re-probe attempts.
> 
> Fix the latter case by making sure that arch_teardown_dma_ops() cleans
> up whenever the ops were automatically installed by its counterpart.
> 
> Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Fixes: 1874619a7df4 "ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()"
> Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> 
> Sorry for the delay - there was a giant email infrastructure cock-up just
> at the point I wanted to go back through my archive and double-check the
> discussion around the original commit...
> 
> Robin.
> 
>  arch/arm/mm/dma-mapping.c | 2 ++
>  1 file changed, 2 insertions(+)

I had also tested your draft on Tegra last week and this looks
identical, so:

Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <treding@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: <iommu@lists.linux-foundation.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <m.szyprowski@samsung.com>,
	<hch@lst.de>, <rmk+kernel@armlinux.org.uk>, <bskeggs@redhat.com>,
	<tjakobi@math.uni-bielefeld.de>, <b.zolnierkie@samsung.com>
Subject: Re: [PATCH] ARM: dma-mapping: Clear DMA ops on teardown
Date: Mon, 21 Jan 2019 16:34:40 +0100	[thread overview]
Message-ID: <20190121153439.GA21078@ulmo> (raw)
In-Reply-To: <2f5833b7639543d614095cd3f5ab0dc0274e26d6.1548081277.git.robin.murphy@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Mon, Jan 21, 2019 at 02:52:16PM +0000, Robin Murphy wrote:
> Installing the appropriate non-IOMMU DMA ops in arm_iommu_detch_device()
> serves the case where IOMMU-aware drivers choose to control their own
> mapping but still make DMA API calls, however it also affects the case
> when the arch code itself tears down the mapping upon driver unbinding,
> where the ops now get left in place and can inhibit arch_setup_dma_ops()
> on subsequent re-probe attempts.
> 
> Fix the latter case by making sure that arch_teardown_dma_ops() cleans
> up whenever the ops were automatically installed by its counterpart.
> 
> Reported-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Fixes: 1874619a7df4 "ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()"
> Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> 
> Sorry for the delay - there was a giant email infrastructure cock-up just
> at the point I wanted to go back through my archive and double-check the
> discussion around the original commit...
> 
> Robin.
> 
>  arch/arm/mm/dma-mapping.c | 2 ++
>  1 file changed, 2 insertions(+)

I had also tested your draft on Tegra last week and this looks
identical, so:

Tested-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-01-21 15:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190121145305epcas4p1df032b4c2c44d5f291eb2bedde9de40d@epcas4p1.samsung.com>
2019-01-21 14:52 ` [PATCH] ARM: dma-mapping: Clear DMA ops on teardown Robin Murphy
2019-01-21 14:52   ` Robin Murphy
2019-01-21 15:34   ` Thierry Reding [this message]
2019-01-21 15:34     ` Thierry Reding
2019-01-21 15:34     ` Thierry Reding
2019-02-04 11:48   ` Marek Szyprowski
2019-02-04 11:48     ` Marek Szyprowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190121153439.GA21078@ulmo \
    --to=treding@nvidia.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=bskeggs@redhat.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robin.murphy@arm.com \
    --cc=tjakobi@math.uni-bielefeld.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.