Re: [PATCH v8 20/24] iommu: Require a default_domain for all iommu drivers
On Tue, 3 Oct 2023 at 02:00, Jason Gunthorpe wrote:
>
> On Tue, Oct 03, 2023 at 12:21:59AM +0300, Dmitry Baryshkov wrote:
> > On Wed, 13 Sept 2023 at 16:45, Jason Gunthorpe wrote:
> > >
> > > At this point every iommu driver will cause a default_domain to be
> > > selected, so we can finally remove this gap from the core code.
> > >
> > > The following table explains what each driver supports and what the
> > > resulting default_domain will be:
> > >
> > > ops->defaut_domain
> > > IDENTITY DMA PLATFORMv ARM32
> > > dma-iommu ARCH
> > > amd/iommu.c Y Y N/A
> > > either
> > > apple-dart.cY Y N/A
> > > either
> > > arm-smmu.c Y Y IDENTITY
> > > either
> > > qcom_iommu.cG Y IDENTITY
> > > either
> > > arm-smmu-v3.c Y Y N/A
> > > either
> > > exynos-iommu.c G Y IDENTITY
> > > either
> > > fsl_pamu_domain.c Y Y N/A
> > > N/A PLATFORM
> > > intel/iommu.c Y Y N/A
> > > either
> > > ipmmu-vmsa.cG Y IDENTITY
> > > either
> > > msm_iommu.c G IDENTITY
> > > N/A
> >
> > Unfortunately this patch breaks msm_iommu platforms. This driver
> > doesn't select ARM_DMA_USE_IOMMU, so iommu_get_default_domain_type()
> > returns 0, bus_iommu_probe() fails with -ENODEV.
> > If I make MSM_IOMMU select ARM_DMA_USE_IOMMU, then GPU probing fails
> > with -EBUSY.
>
> Oh, OK.
>
> Does this fix it?
It indeed fixes the issue, so could you please post it, adding:
Tested-by: Dmitry Baryshkov
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index cdc7b730192a35..f7ef081c33dcb2 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -685,10 +685,16 @@ irqreturn_t msm_iommu_fault_handler(int irq, void
> *dev_id)
> return 0;
> }
>
> +static int msm_iommu_def_domain_type(struct device *dev)
> +{
> + return IOMMU_DOMAIN_IDENTITY;
> +}
> +
> static struct iommu_ops msm_iommu_ops = {
> .identity_domain = _iommu_identity_domain,
> .domain_alloc_paging = msm_iommu_domain_alloc_paging,
> .probe_device = msm_iommu_probe_device,
> + .def_domain_type = msm_iommu_def_domain_type,
> .device_group = generic_device_group,
> .pgsize_bitmap = MSM_IOMMU_PGSIZES,
> .of_xlate = qcom_iommu_of_xlate,
--
With best wishes
Dmitry
Re: [PATCH v8 20/24] iommu: Require a default_domain for all iommu drivers
On Wed, 13 Sept 2023 at 16:45, Jason Gunthorpe wrote:
>
> At this point every iommu driver will cause a default_domain to be
> selected, so we can finally remove this gap from the core code.
>
> The following table explains what each driver supports and what the
> resulting default_domain will be:
>
> ops->defaut_domain
> IDENTITY DMA PLATFORMv ARM32
> dma-iommu ARCH
> amd/iommu.c Y Y N/A either
> apple-dart.cY Y N/A either
> arm-smmu.c Y Y IDENTITYeither
> qcom_iommu.cG Y IDENTITYeither
> arm-smmu-v3.c Y Y N/A either
> exynos-iommu.c G Y IDENTITYeither
> fsl_pamu_domain.c Y Y N/A N/A
> PLATFORM
> intel/iommu.c Y Y N/A either
> ipmmu-vmsa.cG Y IDENTITYeither
> msm_iommu.c G IDENTITYN/A
Unfortunately this patch breaks msm_iommu platforms. This driver
doesn't select ARM_DMA_USE_IOMMU, so iommu_get_default_domain_type()
returns 0, bus_iommu_probe() fails with -ENODEV.
If I make MSM_IOMMU select ARM_DMA_USE_IOMMU, then GPU probing fails
with -EBUSY.
> mtk_iommu.c G Y IDENTITYeither
> mtk_iommu_v1.c G IDENTITYN/A
> omap-iommu.cG IDENTITYN/A
> rockchip-iommu.cG Y IDENTITYeither
> s390-iommu.cY Y N/A N/A
> PLATFORM
> sprd-iommu.cY N/A DMA
> sun50i-iommu.c G Y IDENTITYeither
> tegra-smmu.cG Y IDENTITY
> IDENTITY
> virtio-iommu.c Y Y N/A either
> spapr Y Y N/A N/A
> PLATFORM
> * G means ops->identity_domain is used
> * N/A means the driver will not compile in this configuration
>
> ARM32 drivers select an IDENTITY default domain through either the
> ops->identity_domain or directly requesting an IDENTIY domain through
> alloc_domain().
>
> In ARM64 mode tegra-smmu will still block the use of dma-iommu.c and
> forces an IDENTITY domain.
>
> S390 uses a PLATFORM domain to represent when the dma_ops are set to the
> s390 iommu code.
>
> fsl_pamu uses an PLATFORM domain.
>
> POWER SPAPR uses PLATFORM and blocking to enable its weird VFIO mode.
>
> The x86 drivers continue unchanged.
>
> After this patch group->default_domain is only NULL for a short period
> during bus iommu probing while all the groups are constituted. Otherwise
> it is always !NULL.
>
> This completes changing the iommu subsystem driver contract to a system
> where the current iommu_domain always represents some form of translation
> and the driver is continuously asserting a definable translation mode.
>
> It resolves the confusion that the original ops->detach_dev() caused
> around what translation, exactly, is the IOMMU performing after
> detach. There were at least three different answers to that question in
> the tree, they are all now clearly named with domain types.
>
> Tested-by: Heiko Stuebner
> Tested-by: Niklas Schnelle
> Tested-by: Steven Price
> Tested-by: Marek Szyprowski
> Tested-by: Nicolin Chen
> Reviewed-by: Lu Baolu
> Reviewed-by: Jerry Snitselaar
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/iommu/iommu.c | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 42a4585dd76da6..cfb597751f5bad 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1865,7 +1865,6 @@ static int iommu_get_def_domain_type(struct iommu_group
> *group,
> static int iommu_get_default_domain_type(struct iommu_group *group,
> int target_type)
> {
> - const struct iommu_ops *ops = group_iommu_ops(group);
> struct device *untrusted = NULL;
> struct group_device *gdev;
> int driver_type = 0;
> @@ -1876,11 +1875,13 @@ static int iommu_get_default_domain_type(struct
> iommu_group *group,
> * ARM32 drivers supporting CONFIG_ARM_DMA_USE_IOMMU can declare an
> * identity_domain and it will automatically become their default
> * domain. Later on ARM_DMA_USE_IOMMU will install its UNMANAGED
> domain.
> -* Override the selection to IDENTITY if we are sure the driver
>
Re: [PATCH v5 14/25] iommu/msm: Implement an IDENTITY domain
On 24/07/2023 20:22, Jason Gunthorpe wrote:
What msm does during omap_iommu_set_platform_dma() is actually putting the
typo: msm driver doesn't use/provide omap_iommu_set_platform_dma().
iommu into identity mode.
Move to the new core support for ARM_DMA_USE_IOMMU by defining
ops->identity_domain.
This driver does not support IOMMU_DOMAIN_DMA, however it cannot be
compiled on ARM64 either. Most likely it is fine to support dma-iommu.c
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/msm_iommu.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 79d89bad5132b7..26ed81cfeee897 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -443,15 +443,20 @@ static int msm_iommu_attach_dev(struct iommu_domain
*domain, struct device *dev)
return ret;
}
-static void msm_iommu_set_platform_dma(struct device *dev)
+static int msm_iommu_identity_attach(struct iommu_domain *identity_domain,
+struct device *dev)
{
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
- struct msm_priv *priv = to_msm_priv(domain);
+ struct msm_priv *priv;
unsigned long flags;
struct msm_iommu_dev *iommu;
struct msm_iommu_ctx_dev *master;
- int ret;
+ int ret = 0;
+ if (domain == identity_domain || !domain)
+ return 0;
+
+ priv = to_msm_priv(domain);
free_io_pgtable_ops(priv->iop);
spin_lock_irqsave(_iommu_lock, flags);
@@ -468,8 +473,18 @@ static void msm_iommu_set_platform_dma(struct device *dev)
}
fail:
spin_unlock_irqrestore(_iommu_lock, flags);
+ return ret;
}
+static struct iommu_domain_ops msm_iommu_identity_ops = {
+ .attach_dev = msm_iommu_identity_attach,
+};
+
+static struct iommu_domain msm_iommu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_identity_ops,
+};
+
static int msm_iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t pa, size_t pgsize, size_t pgcount,
int prot, gfp_t gfp, size_t *mapped)
@@ -675,10 +690,10 @@ irqreturn_t msm_iommu_fault_handler(int irq, void *dev_id)
}
static struct iommu_ops msm_iommu_ops = {
+ .identity_domain = _iommu_identity_domain,
.domain_alloc = msm_iommu_domain_alloc,
.probe_device = msm_iommu_probe_device,
.device_group = generic_device_group,
- .set_platform_dma_ops = msm_iommu_set_platform_dma,
.pgsize_bitmap = MSM_IOMMU_PGSIZES,
.of_xlate = qcom_iommu_of_xlate,
.default_domain_ops = &(const struct iommu_domain_ops) {
--
With best wishes
Dmitry
Re: [PATCH v2 01/16] of: device: make of_device_uevent_modalias() take a const device *
On 11/01/2023 17:26, Greg Kroah-Hartman wrote: On Wed, Jan 11, 2023 at 08:54:04AM -0600, Rob Herring wrote: On Wed, Jan 11, 2023 at 5:30 AM Greg Kroah-Hartman wrote: of_device_uevent_modalias() does not modify the device pointer passed to it, so mark it constant. In order to properly do this, a number of busses need to have a modalias function added as they were attempting to just point to of_device_uevent_modalias instead of their bus-specific modalias function. This is fine except if the prototype for a bus and device type modalias function diverges and then problems could happen. To prevent all of that, just wrap the call to of_device_uevent_modalias() directly for each bus and device type individually. Why not just put the wrapper function in the DT code instead of making 4 copies of it? I could, if you think that it would be better there instead of in each individual bus (like all of the other bus callbacks). This way each bus "owns" their implementation :) I'd vote for the generic wrapper instead of 4 similar wrapper. In the end, if of_device_uevent_modalias (or the bus callback) interface changes again for whatever reasons, there will be just a single place to fix rather than fixing 4 (or more) bus drivers. -- With best wishes Dmitry
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
Anatolij Gustschin wrote: This patch adds framebuffer driver for Fujitsu Carmine/Coral-P(A)/Lime graphics controllers. Lime GDC support is known to work on PPC440EPx based lwmon5 and MPC8544E based socrates embedded boards, both equipped with Lime GDC. Carmine/Coral-P PCI GDC support is known to work on PPC440EPx based Sequoia board and also on x86 platform. Signed-off-by: Anatolij Gustschin [EMAIL PROTECTED] --- There are some PPC OF bits, so I'm cc'ing linuxppc-dev list. I though there is already carminefb driver. Probably you should either merge them or state that carminefb should be dropped. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Maple D info
Hi, Sorry to bother you. I'm searching for the information/guides related to the Maple D board (XSC-100). I've downloaded all the info I could get from the IBM, but I'm still missing the docs about board jumpers/settings/etc. All official sources for info are dead since long ago. So, if one has any technical docs regarding XSC-100 board, could you please contact me. Thanks in advance. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
