search for: arm_iommu_attach_device

...;data->iommu; +} - data = dev_iommu_priv_get(dev); +static void mtk_iommu_probe_finalize(struct device *dev) +{ + struct dma_iommu_mapping *mtk_mapping; + struct mtk_iommu_data *data; + int err; + + data = dev_iommu_priv_get(dev); mtk_mapping = data->dev->archdata.iommu; - err = arm_iommu_attach_device(dev, mtk_mapping); - if (err) { - iommu_group_remove_device(dev); - return err; - } - return iommu_device_link(&data->iommu, dev); + err = arm_iommu_attach_device(dev, mtk_mapping); + if (err) + dev_err(dev, "Can't create IOMMU mapping - DMA-OPS will not work\n"); } -st...

...efore you try to operate on it is never the > > best idea. Plus arm_iommu_detach_device() already releases a reference > > appropriately anyway, so it's a double-free. > > But the reference released by arm_iommu_detach_device() is to balance > out the reference acquired by arm_iommu_attach_device(), isn't it? In > the above, the arm_iommu_release_mapping() is supposed to drop the > final reference which was obtained by arm_iommu_create_mapping(). The > mapping shouldn't go away irrespective of the order in which these > will be called. Going over the DMA/IOMMU code I ju...

On 30/05/18 09:03, Thierry Reding wrote: > From: Thierry Reding <treding at nvidia.com> > > Implement this function to enable drivers from detaching from any IOMMU > domains that architecture code might have attached them to so that they > can take exclusive control of the IOMMU via the IOMMU API. > > Signed-off-by: Thierry Reding <treding at nvidia.com> > ---

...operate on it is never the >>> best idea. Plus arm_iommu_detach_device() already releases a reference >>> appropriately anyway, so it's a double-free. >> >> But the reference released by arm_iommu_detach_device() is to balance >> out the reference acquired by arm_iommu_attach_device(), isn't it? In >> the above, the arm_iommu_release_mapping() is supposed to drop the >> final reference which was obtained by arm_iommu_create_mapping(). The >> mapping shouldn't go away irrespective of the order in which these >> will be called. > > Going ov...

...lly freeing the mapping before you try to operate on it is never the > best idea. Plus arm_iommu_detach_device() already releases a reference > appropriately anyway, so it's a double-free. But the reference released by arm_iommu_detach_device() is to balance out the reference acquired by arm_iommu_attach_device(), isn't it? In the above, the arm_iommu_release_mapping() is supposed to drop the final reference which was obtained by arm_iommu_create_mapping(). The mapping shouldn't go away irrespective of the order in which these will be called. > > + arm_iommu_detach_device(dev); > > +...

Hi, here is a patch-set to rename iommu_param to dev_iommu and establish it as a struct for generic per-device iommu-data. Also move the iommu_fwspec pointer from struct device into dev_iommu to have less iommu-related pointers in struct device. The bigger part of this patch-set moves the iommu_priv pointer from struct iommu_fwspec to dev_iommu, making is usable for iommu-drivers which do not

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the third version of this patch-set. Older versions can be found here: v1: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ (Has some more introductory text) v2: https://lore.kernel.org/lkml/20200414131542.25608-1-joro at 8bytes.org/ Changes v2 -> v3: * Rebased v5.7-rc3 * Added a missing iommu_group_put() as reported by Lu Baolu. * Added a

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a