[PATCH] iommu: arm-smmu: drop devm_free_irq when driver detach

There is no need to call devm_free_irq when driver detach. devres_release_all which is called after 'drv->remove' will release all managed resources. Signed-off-by: Peng Fan Cc: Will Deacon Cc: Robin Murphy ---

Re: [PATCH] iommu: arm-smmu: use devm_request_irq and devm_free_irq

Hi Robin, On Mon, Jul 11, 2016 at 11:32:55AM +0100, Robin Murphy wrote: >On 04/07/16 10:38, Peng Fan wrote: >> Use devm_request_irq to simplify error handling path, >> when probe smmu device. >> >> Also devm_{request|free}_irq when init or destroy domain context. >> >> Signed-off-by: Peng Fan

[PATCH] iommu/arm-smmu-v3: limit use of 2-level stream tables

In the current arm-smmu-v3 driver, all smmus that support 2-level stream tables are being forced to use them. This is suboptimal for smmus that support fewer stream id bits than would fill in a single second level table. This patch limits the use of 2-level tables to smmus that both support the

Re: [PATCH v2 6/6] dmaengine: pl330: Make sure microcode is privileged-executable

On 09/07/16 03:09, Mitchel Humpherys wrote: > The PL330 can perform privileged instruction fetches. This can result Nit: "can" is a bit of an understatement. Instruction fetches on both the manager and channel threads have the "privileged" and "instruction" AxPROT bits hard-coded whether you

Re: [PATCH v2 0/6] Add support for privileged mappings

On Mon, Jul 11, 2016 at 03:02:24PM +0100, Robin Murphy wrote: > Hey Mitch, > > Thanks for having the necessary go at the DMA API - I think the series > looks broadly workable now. > > On 09/07/16 03:09, Mitchel Humpherys wrote: > > The following patch to the ARM SMMU driver: > > > > commit

Re: [PATCH v2 5/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE

On 09/07/16 03:09, Mitchel Humpherys wrote: > The newly added DMA_ATTR_PRIVILEGED_EXECUTABLE is useful for creating > mappings that are executable by privileged DMA engines. Implement it in > dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. > > Signed-off-by: Mitchel Humpherys

Re: [PATCH v2 4/6] common: DMA-mapping: add DMA_ATTR_PRIVILEGED_EXECUTABLE attribute

On 09/07/16 03:09, Mitchel Humpherys wrote: > This patch adds the DMA_ATTR_PRIVILEGED_EXECUTABLE attribute to the > DMA-mapping subsystem. DMA_ATTR_PRIVILEGED. We can worry about the (much bigger) executable vs. NX issue some other time. > Some architectures require that writable mappings also

Re: [PATCH v2 3/6] Revert "iommu/arm-smmu: Treat all device transactions as unprivileged"

On 09/07/16 03:09, Mitchel Humpherys wrote: > This reverts commit d346180e70b9 ("iommu/arm-smmu: Treat all device > transactions as unprivileged") since some platforms actually make use of > privileged transactions. Super-nit: I know it makes bog-all difference in reality, but logically it would

Re: [PATCH v2 2/6] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

On 09/07/16 03:09, Mitchel Humpherys wrote: > From: Jeremy Gebben > > Allow the creation of privileged mode mappings, for stage 1 only. > > Signed-off-by: Jeremy Gebben > --- > drivers/iommu/io-pgtable-arm.c | 16 +++- > 1 file

Re: [PATCH v2 1/6] iommu: add IOMMU_PRIV attribute

On 09/07/16 03:09, Mitchel Humpherys wrote: > Add the IOMMU_PRIV attribute, which is used to indicate privileged > mappings. > > Signed-off-by: Mitchel Humpherys > --- > include/linux/iommu.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCH v2 0/6] Add support for privileged mappings

Hey Mitch, Thanks for having the necessary go at the DMA API - I think the series looks broadly workable now. On 09/07/16 03:09, Mitchel Humpherys wrote: > The following patch to the ARM SMMU driver: > > commit d346180e70b91b3d5a1ae7e5603e65593d4622bc > Author: Robin Murphy

Re: [PATCH v4 5/8] iommu/of: Introduce iommu_fwspec

On 07/07/16 17:56, Lorenzo Pieralisi wrote: > On Fri, Jul 01, 2016 at 05:50:14PM +0100, Robin Murphy wrote: > > [...] > >> +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids) >> +{ >> +struct iommu_fwspec *fwspec = dev->archdata.iommu; >> +size_t size; >> + >> +if

Re: [PATCH] iommu: arm-smmu: use devm_request_irq and devm_free_irq

On Mon, Jul 11, 2016 at 11:32:55AM +0100, Robin Murphy wrote: > On 04/07/16 10:38, Peng Fan wrote: > > Use devm_request_irq to simplify error handling path, > > when probe smmu device. > > > > Also devm_{request|free}_irq when init or destroy domain context. > > > > Signed-off-by: Peng Fan

Re: [PATCH] iommu: arm-smmu: use devm_request_irq and devm_free_irq

On 04/07/16 10:38, Peng Fan wrote: > Use devm_request_irq to simplify error handling path, > when probe smmu device. > > Also devm_{request|free}_irq when init or destroy domain context. > > Signed-off-by: Peng Fan > Cc: Will Deacon > Cc: Robin

Re: [PATCH] iommu/amd: Fix unity mapping initialization race

> >> Sorry, why you still say this 'init_device_table_dma' can block DMA? >> I just think this function will enable DMA transfer, since we set >> the V and TV bits, right? or I misunderstand what "block DMA" mean? > > When the V and TV bits are not set, it means that all DMA from that > device-id

Re: [PATCH] iommu/amd: Fix unity mapping initialization race

On Mon, Jul 11, 2016 at 05:25:29PM +0800, Wan Zongshun wrote: > Okay, this patch should also better to general case not only unity-mapping. > > How about the interrupt remap function? Do we need same considering > for IV bit enable for interrupt remap? No, there are no unity mappings for irqs,

Re: [PATCH] iommu/amd: Fix unity mapping initialization race

On 2016年07月11日 15:19, Joerg Roedel wrote: On Sun, Jul 10, 2016 at 07:40:53PM +0800, Wan Zongshun wrote: Do you mean we need enable the V and TV bits to DTE entry after all DTEs tables were initialized completely? Yes, this is what my patch does and what fixes the bug that was reported on

Re: [PATCH] iommu/amd: Fix unity mapping initialization race

On Sun, Jul 10, 2016 at 07:40:53PM +0800, Wan Zongshun wrote: > Do you mean we need enable the V and TV bits to DTE entry after all > DTEs tables were initialized completely? Yes, this is what my patch does and what fixes the bug that was reported on machines which have unity-mapping entries. >