Re: cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver
On Mon, Mar 1, 2021 at 2:44 AM Christoph Hellwig wrote: > > Hi all, > > there are a bunch of IOMMU APIs that are entirely unused, or only used as > a private communication channel between the FSL PAMU driver and it's only > consumer, the qbman portal driver. > > So this series drops a huge chunk of entirely unused FSL PAMU > functionality, then drops all kinds of unused IOMMU APIs, and then > replaces what is left of the iommu_attrs with properly typed, smaller > and easier to use specific APIs. It looks like the unused APIs were added for functionality that were never completed later on. So Acked-by: Li Yang > > Diffstat: > arch/powerpc/include/asm/fsl_pamu_stash.h | 12 > drivers/gpu/drm/msm/adreno/adreno_gpu.c |2 > drivers/iommu/amd/iommu.c | 23 > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 85 --- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 122 +--- > drivers/iommu/dma-iommu.c |8 > drivers/iommu/fsl_pamu.c| 264 -- > drivers/iommu/fsl_pamu.h| 10 > drivers/iommu/fsl_pamu_domain.c | 694 > ++-- > drivers/iommu/fsl_pamu_domain.h | 46 - > drivers/iommu/intel/iommu.c | 55 -- > drivers/iommu/iommu.c | 75 --- > drivers/soc/fsl/qbman/qman_portal.c | 56 -- > drivers/vfio/vfio_iommu_type1.c | 31 - > drivers/vhost/vdpa.c| 10 > include/linux/iommu.h | 81 --- > 16 files changed, 214 insertions(+), 1360 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/arm-smmu: fix module name for parameters
Commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module")
introduced a side effect that changed the module name from arm-smmu to
arm-smmu-mod. This breaks the users of kernel parameters for the driver
(e.g. arm-smmu.disable_bypass). This patch changes the module name for
parameters back to arm-smmu to be consistent with older kernel.
Signed-off-by: Li Yang
---
drivers/iommu/arm-smmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 16c4b87af42b..8d5a19bfde5c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -58,6 +58,8 @@
#define MSI_IOVA_BASE 0x800
#define MSI_IOVA_LENGTH0x10
+#undef MODULE_PARAM_PREFIX
+#define MODULE_PARAM_PREFIX "arm-smmu."
static int force_stage;
module_param(force_stage, int, S_IRUGO);
MODULE_PARM_DESC(force_stage,
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/arm-smmu: fix the module name to be consistent with older kernel
On Wed, Feb 12, 2020 at 4:50 AM Will Deacon wrote:
>
> On Tue, Feb 11, 2020 at 06:37:20PM -0600, Li Yang wrote:
> > Commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module")
> > introduced a side effect that changed the module name from arm-smmu to
> > arm-smmu-mod. This breaks the users of kernel parameters for the driver
> > (e.g. arm-smmu.disable_bypass). This patch changes the module name back
> > to be consistent.
> >
> > Signed-off-by: Li Yang
> > ---
> > drivers/iommu/Makefile | 4 ++--
> > drivers/iommu/{arm-smmu.c => arm-smmu-common.c} | 0
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> > rename drivers/iommu/{arm-smmu.c => arm-smmu-common.c} (100%)
>
> Can't we just override MODULE_PARAM_PREFIX instead of renaming the file?
I can do that. But on the other hand, the "mod" in the module name
arm-smmu-mod.ko seems to be redundant and looks a little bit weird.
Wouldn't it be cleaner to make it just arm-smmu.ko?
Regards,
Leo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/arm-smmu: fix the module name to be consistent with older kernel
Commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module")
introduced a side effect that changed the module name from arm-smmu to
arm-smmu-mod. This breaks the users of kernel parameters for the driver
(e.g. arm-smmu.disable_bypass). This patch changes the module name back
to be consistent.
Signed-off-by: Li Yang
---
drivers/iommu/Makefile | 4 ++--
drivers/iommu/{arm-smmu.c => arm-smmu-common.c} | 0
2 files changed, 2 insertions(+), 2 deletions(-)
rename drivers/iommu/{arm-smmu.c => arm-smmu-common.c} (100%)
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 2104fb8afc06..f39e82e68640 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -14,8 +14,8 @@ obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o
obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o amd_iommu_quirks.o
obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd_iommu_debugfs.o
obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
-obj-$(CONFIG_ARM_SMMU) += arm-smmu-mod.o
-arm-smmu-mod-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o
+obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
+arm-smmu-objs := arm-smmu-common.o arm-smmu-impl.o arm-smmu-qcom.o
obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o intel-pasid.o
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu-common.c
similarity index 100%
rename from drivers/iommu/arm-smmu.c
rename to drivers/iommu/arm-smmu-common.c
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/arm-smmu: fix the module name for disable_bypass parameter
On Tue, Feb 11, 2020 at 5:47 PM Russell King - ARM Linux admin
wrote:
>
> On Tue, Feb 11, 2020 at 05:36:55PM -0600, Li Yang wrote:
> > Since commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module"),
> > there is a side effect that the module name is changed from arm-smmu to
> > arm-smmu-mod. So the kernel parameter for disable_bypass need to be
> > changed too. Fix the Kconfig help and error message to the correct
> > parameter name.
>
> Hmm, this seems to be a user-visible change - so those of us who have
> been booting with "arm-smmu.disable_bypass=0" now need to change that
> depending on which kernel is being booted - which is not nice, and
> makes the support side on platforms that need this kernel parameter
> harder.
I have sent a new patch replacing this patch. That patch will keep
the command line unchanged.
>
> >
> > Signed-off-by: Li Yang
> > ---
> > drivers/iommu/Kconfig| 2 +-
> > drivers/iommu/arm-smmu.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index d2fade984999..fb54be903c60 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -415,7 +415,7 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
> > hardcode the bypass disable in the code.
> >
> > NOTE: the kernel command line parameter
> > - 'arm-smmu.disable_bypass' will continue to override this
> > + 'arm-smmu-mod.disable_bypass' will continue to override this
> > config.
> >
> > config ARM_SMMU_V3
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 16c4b87af42b..2ffe8ff04393 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -512,7 +512,7 @@ static irqreturn_t arm_smmu_global_fault(int irq, void
> > *dev)
> > if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
> > (gfsr & ARM_SMMU_sGFSR_USF))
> > dev_err(smmu->dev,
> > - "Blocked unknown Stream ID 0x%hx; boot with
> > \"arm-smmu.disable_bypass=0\" to allow, but this may have security
> > implications\n",
> > + "Blocked unknown Stream ID 0x%hx; boot with
> > \"arm-smmu-mod.disable_bypass=0\" to allow, but this may have security
> > implications\n",
> > (u16)gfsynr1);
> > else
> > dev_err(smmu->dev,
> > --
> > 2.17.1
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/arm-smmu: fix the module name for disable_bypass parameter
Since commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module"),
there is a side effect that the module name is changed from arm-smmu to
arm-smmu-mod. So the kernel parameter for disable_bypass need to be
changed too. Fix the Kconfig help and error message to the correct
parameter name.
Signed-off-by: Li Yang
---
drivers/iommu/Kconfig| 2 +-
drivers/iommu/arm-smmu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d2fade984999..fb54be903c60 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -415,7 +415,7 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
hardcode the bypass disable in the code.
NOTE: the kernel command line parameter
- 'arm-smmu.disable_bypass' will continue to override this
+ 'arm-smmu-mod.disable_bypass' will continue to override this
config.
config ARM_SMMU_V3
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 16c4b87af42b..2ffe8ff04393 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -512,7 +512,7 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
(gfsr & ARM_SMMU_sGFSR_USF))
dev_err(smmu->dev,
- "Blocked unknown Stream ID 0x%hx; boot with
\"arm-smmu.disable_bypass=0\" to allow, but this may have security
implications\n",
+ "Blocked unknown Stream ID 0x%hx; boot with
\"arm-smmu-mod.disable_bypass=0\" to allow, but this may have security
implications\n",
(u16)gfsynr1);
else
dev_err(smmu->dev,
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
On Thu, May 30, 2019 at 5:09 PM David Miller wrote: > > From: laurentiu.tu...@nxp.com > Date: Thu, 30 May 2019 17:19:45 +0300 > > > Depends on this pull request: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html > > I'm not sure how you want me to handle this. One suggestion from the arm-soc maintainers is that after this pull request is merged by arm-soc tree. You can also merge this pull request and then apply the patches. Regards, Leo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/9] soc/fsl/qman: fixup liodns only on ppc targets
On Sat, Apr 27, 2019 at 2:14 AM wrote:
>
> From: Laurentiu Tudor
>
> ARM SoCs use SMMU so the liodn fixup done in the qman driver is no
> longer making sense and it also breaks the ICID settings inherited
> from u-boot. Do the fixups only for PPC targets.
>
> Signed-off-by: Laurentiu Tudor
Applied for next. Thanks.
Leo
> ---
> drivers/soc/fsl/qbman/qman_ccsr.c | 2 +-
> drivers/soc/fsl/qbman/qman_priv.h | 9 -
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
> b/drivers/soc/fsl/qbman/qman_ccsr.c
> index 109b38de3176..a6bb43007d03 100644
> --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> @@ -596,7 +596,7 @@ static int qman_init_ccsr(struct device *dev)
> }
>
> #define LIO_CFG_LIODN_MASK 0x0fff
> -void qman_liodn_fixup(u16 channel)
> +void __qman_liodn_fixup(u16 channel)
> {
> static int done;
> static u32 liodn_offset;
> diff --git a/drivers/soc/fsl/qbman/qman_priv.h
> b/drivers/soc/fsl/qbman/qman_priv.h
> index 75a8f905f8f7..04515718cfd9 100644
> --- a/drivers/soc/fsl/qbman/qman_priv.h
> +++ b/drivers/soc/fsl/qbman/qman_priv.h
> @@ -193,7 +193,14 @@ extern struct gen_pool *qm_cgralloc; /* CGR ID allocator
> */
> u32 qm_get_pools_sdqcr(void);
>
> int qman_wq_alloc(void);
> -void qman_liodn_fixup(u16 channel);
> +#ifdef CONFIG_FSL_PAMU
> +#define qman_liodn_fixup __qman_liodn_fixup
> +#else
> +static inline void qman_liodn_fixup(u16 channel)
> +{
> +}
> +#endif
> +void __qman_liodn_fixup(u16 channel);
> void qman_set_sdest(u16 channel, unsigned int cpu_idx);
>
> struct qman_portal *qman_create_affine_portal(
> --
> 2.17.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/9] soc/fsl/qbman_portals: add APIs to retrieve the probing status
On Sat, Apr 27, 2019 at 2:14 AM wrote:
>
> From: Laurentiu Tudor
>
> Add a couple of new APIs to check the probing status of the required
> cpu bound qman and bman portals:
> 'int bman_portals_probed()' and 'int qman_portals_probed()'.
> They return the following values.
> * 1 if qman/bman portals were all probed correctly
> * 0 if qman/bman portals were not yet probed
> * -1 if probing of qman/bman portals failed
> Portals are considered successful probed if no error occurred during
> the probing of any of the portals and if enough portals were probed
> to have one available for each cpu.
> The error handling paths were slightly rearranged in order to fit this
> new functionality without being too intrusive.
> Drivers that use qman/bman portal driver services are required to use
> these APIs before calling any functions exported by these drivers or
> otherwise they will crash the kernel.
> First user will be the dpaa1 ethernet driver, coming in a subsequent
> patch.
>
> Signed-off-by: Laurentiu Tudor
Applied for next. Thanks.
Leo
> ---
> drivers/soc/fsl/qbman/bman_portal.c | 20
> drivers/soc/fsl/qbman/qman_portal.c | 21 +
> include/soc/fsl/bman.h | 8
> include/soc/fsl/qman.h | 9 +
> 4 files changed, 50 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/bman_portal.c
> b/drivers/soc/fsl/qbman/bman_portal.c
> index 2c95cf59f3e7..cf4f10d6f590 100644
> --- a/drivers/soc/fsl/qbman/bman_portal.c
> +++ b/drivers/soc/fsl/qbman/bman_portal.c
> @@ -32,6 +32,7 @@
>
> static struct bman_portal *affine_bportals[NR_CPUS];
> static struct cpumask portal_cpus;
> +static int __bman_portals_probed;
> /* protect bman global registers and global data shared among portals */
> static DEFINE_SPINLOCK(bman_lock);
>
> @@ -87,6 +88,12 @@ static int bman_online_cpu(unsigned int cpu)
> return 0;
> }
>
> +int bman_portals_probed(void)
> +{
> + return __bman_portals_probed;
> +}
> +EXPORT_SYMBOL_GPL(bman_portals_probed);
> +
> static int bman_portal_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -104,8 +111,10 @@ static int bman_portal_probe(struct platform_device
> *pdev)
> }
>
> pcfg = devm_kmalloc(dev, sizeof(*pcfg), GFP_KERNEL);
> - if (!pcfg)
> + if (!pcfg) {
> + __bman_portals_probed = -1;
> return -ENOMEM;
> + }
>
> pcfg->dev = dev;
>
> @@ -113,14 +122,14 @@ static int bman_portal_probe(struct platform_device
> *pdev)
> DPAA_PORTAL_CE);
> if (!addr_phys[0]) {
> dev_err(dev, "Can't get %pOF property 'reg::CE'\n", node);
> - return -ENXIO;
> + goto err_ioremap1;
> }
>
> addr_phys[1] = platform_get_resource(pdev, IORESOURCE_MEM,
> DPAA_PORTAL_CI);
> if (!addr_phys[1]) {
> dev_err(dev, "Can't get %pOF property 'reg::CI'\n", node);
> - return -ENXIO;
> + goto err_ioremap1;
> }
>
> pcfg->cpu = -1;
> @@ -128,7 +137,7 @@ static int bman_portal_probe(struct platform_device *pdev)
> irq = platform_get_irq(pdev, 0);
> if (irq <= 0) {
> dev_err(dev, "Can't get %pOF IRQ'\n", node);
> - return -ENXIO;
> + goto err_ioremap1;
> }
> pcfg->irq = irq;
>
> @@ -150,6 +159,7 @@ static int bman_portal_probe(struct platform_device *pdev)
> spin_lock(_lock);
> cpu = cpumask_next_zero(-1, _cpus);
> if (cpu >= nr_cpu_ids) {
> + __bman_portals_probed = 1;
> /* unassigned portal, skip init */
> spin_unlock(_lock);
> return 0;
> @@ -175,6 +185,8 @@ static int bman_portal_probe(struct platform_device *pdev)
> err_ioremap2:
> memunmap(pcfg->addr_virt_ce);
> err_ioremap1:
> +__bman_portals_probed = -1;
> +
> return -ENXIO;
> }
>
> diff --git a/drivers/soc/fsl/qbman/qman_portal.c
> b/drivers/soc/fsl/qbman/qman_portal.c
> index 661c9b234d32..e2186b681d87 100644
> --- a/drivers/soc/fsl/qbman/qman_portal.c
> +++ b/drivers/soc/fsl/qbman/qman_portal.c
> @@ -38,6 +38,7 @@ EXPORT_SYMBOL(qman_dma_portal);
> #define CONFIG_FSL_DPA_PIRQ_FAST 1
>
> static struct cpumask portal_cpus;
> +static int __qman_portals_probed;
> /* protect qman global registers and global data shared among portals */
> static DEFINE_SPINLOCK(qman_lock);
>
> @@ -220,6 +221,12 @@ static int qman_online_cpu(unsigned int cpu)
> return 0;
> }
>
> +int qman_portals_probed(void)
> +{
> + return __qman_portals_probed;
> +}
> +EXPORT_SYMBOL_GPL(qman_portals_probed);
> +
> static int qman_portal_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -238,8 +245,10 @@ static int
Re: [PATCH 06/13] soc/fsl/qbman_portals: add APIs to retrieve the probing status
On Fri, Mar 29, 2019 at 9:03 AM wrote:
>
> From: Laurentiu Tudor
>
> Add a couple of new APIs to check the probing status of the required
> cpu bound qman and bman portals:
> 'int bman_portals_probed()' and 'int qman_portals_probed()'.
> They return the following values.
> * 1 if qman/bman portals were all probed correctly
> * 0 if qman/bman portals were not yet probed
> * -1 if probing of qman/bman portals failed
> Portals are considered successful probed if no error occurred during
> the probing of any of the portals and if enough portals were probed
> to have one available for each cpu.
> The error handling paths were slightly rearranged in order to fit this
> new functionality without being too intrusive.
> Drivers that use qman/bman portal driver services are required to use
> these APIs before calling any functions exported by these drivers or
> otherwise they will crash the kernel.
> First user will be the dpaa1 ethernet driver, coming in a subsequent
> patch.
>
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/soc/fsl/qbman/bman_portal.c | 22 ++
> drivers/soc/fsl/qbman/qman_portal.c | 23 +++
> include/soc/fsl/bman.h | 8
> include/soc/fsl/qman.h | 9 +
> 4 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/bman_portal.c
> b/drivers/soc/fsl/qbman/bman_portal.c
> index 2c95cf59f3e7..7819bc29936d 100644
> --- a/drivers/soc/fsl/qbman/bman_portal.c
> +++ b/drivers/soc/fsl/qbman/bman_portal.c
> @@ -32,6 +32,7 @@
>
> static struct bman_portal *affine_bportals[NR_CPUS];
> static struct cpumask portal_cpus;
> +static int __bman_portals_probed;
> /* protect bman global registers and global data shared among portals */
> static DEFINE_SPINLOCK(bman_lock);
>
> @@ -87,6 +88,12 @@ static int bman_online_cpu(unsigned int cpu)
> return 0;
> }
>
> +int bman_portals_probed(void)
> +{
> + return __bman_portals_probed;
> +}
> +EXPORT_SYMBOL_GPL(bman_portals_probed);
> +
> static int bman_portal_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -104,8 +111,10 @@ static int bman_portal_probe(struct platform_device
> *pdev)
> }
>
> pcfg = devm_kmalloc(dev, sizeof(*pcfg), GFP_KERNEL);
> - if (!pcfg)
> + if (!pcfg) {
> + __bman_portals_probed = -1;
> return -ENOMEM;
> + }
>
> pcfg->dev = dev;
>
> @@ -113,14 +122,14 @@ static int bman_portal_probe(struct platform_device
> *pdev)
> DPAA_PORTAL_CE);
> if (!addr_phys[0]) {
> dev_err(dev, "Can't get %pOF property 'reg::CE'\n", node);
> - return -ENXIO;
> + goto err_ioremap1;
> }
>
> addr_phys[1] = platform_get_resource(pdev, IORESOURCE_MEM,
> DPAA_PORTAL_CI);
> if (!addr_phys[1]) {
> dev_err(dev, "Can't get %pOF property 'reg::CI'\n", node);
> - return -ENXIO;
> + goto err_ioremap1;
> }
>
> pcfg->cpu = -1;
> @@ -128,7 +137,7 @@ static int bman_portal_probe(struct platform_device *pdev)
> irq = platform_get_irq(pdev, 0);
> if (irq <= 0) {
> dev_err(dev, "Can't get %pOF IRQ'\n", node);
> - return -ENXIO;
> + goto err_ioremap1;
> }
> pcfg->irq = irq;
>
> @@ -156,6 +165,9 @@ static int bman_portal_probe(struct platform_device *pdev)
> }
>
> cpumask_set_cpu(cpu, _cpus);
> + if (!__bman_portals_probed &&
> + cpumask_weight(_cpus) == num_online_cpus())
> + __bman_portals_probed = 1;
Given the fact that the portal_cpus bit will get set even for offline
cpus, this is not correct either. Probably the previous code for
checking cpu >= nr_cpu_ids is actually the right way to do it.
> spin_unlock(_lock);
> pcfg->cpu = cpu;
>
> @@ -175,6 +187,8 @@ static int bman_portal_probe(struct platform_device *pdev)
> err_ioremap2:
> memunmap(pcfg->addr_virt_ce);
> err_ioremap1:
> +__bman_portals_probed = -1;
> +
> return -ENXIO;
> }
>
> diff --git a/drivers/soc/fsl/qbman/qman_portal.c
> b/drivers/soc/fsl/qbman/qman_portal.c
> index bce56da2b01f..11ba6c77c0d6 100644
> --- a/drivers/soc/fsl/qbman/qman_portal.c
> +++ b/drivers/soc/fsl/qbman/qman_portal.c
> @@ -39,6 +39,7 @@ EXPORT_SYMBOL(qman_dma_portal);
> #define CONFIG_FSL_DPA_PIRQ_FAST 1
>
> static struct cpumask portal_cpus;
> +static int __qman_portals_probed;
> /* protect qman global registers and global data shared among portals */
> static DEFINE_SPINLOCK(qman_lock);
>
> @@ -221,6 +222,12 @@ static int qman_online_cpu(unsigned int cpu)
> return 0;
> }
>
> +int qman_portals_probed(void)
> +{
> + return __qman_portals_probed;
> +}
> +EXPORT_SYMBOL_GPL(qman_portals_probed);
> +
>
Re: [PATCH 05/13] soc/fsl/bqman: page align iommu mapping sizes
On Fri, Mar 29, 2019 at 9:01 AM wrote:
>
> From: Laurentiu Tudor
>
> Prior to calling iommu_map()/iommu_unmap() page align the size or
> failures such as below could happen:
>
> iommu: unaligned: iova 0x... pa 0x... size 0x4000 min_pagesz 0x1
> qman_portal 5.qman-portal: failed to iommu_map() -22
>
> Seen when booted a kernel compiled with 64K page size support.
This will silently incease the actual space mapped to 64K when the
driver is actually trying to map 4K. Will this potentially cause
security breaches? If it is really safe to map 64K, probably the
better way is to increase the region size to 64k in the device tree
explicitly.
>
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/soc/fsl/qbman/bman_ccsr.c | 2 +-
> drivers/soc/fsl/qbman/qman_ccsr.c | 4 ++--
> drivers/soc/fsl/qbman/qman_portal.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> index b209c79511bb..3a6e01bde32d 100644
> --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> @@ -230,7 +230,7 @@ static int fsl_bman_probe(struct platform_device *pdev)
> /* Create an 1-to-1 iommu mapping for FBPR area */
> domain = iommu_get_domain_for_dev(dev);
> if (domain) {
> - ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> + ret = iommu_map(domain, fbpr_a, fbpr_a, PAGE_ALIGN(fbpr_sz),
> IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> if (ret)
> dev_warn(dev, "failed to iommu_map() %d\n", ret);
> diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
> b/drivers/soc/fsl/qbman/qman_ccsr.c
> index eec7700507e1..8d3c950ce52d 100644
> --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> @@ -783,11 +783,11 @@ static int fsl_qman_probe(struct platform_device *pdev)
> /* Create an 1-to-1 iommu mapping for fqd and pfdr areas */
> domain = iommu_get_domain_for_dev(dev);
> if (domain) {
> - ret = iommu_map(domain, fqd_a, fqd_a, fqd_sz,
> + ret = iommu_map(domain, fqd_a, fqd_a, PAGE_ALIGN(fqd_sz),
> IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> if (ret)
> dev_warn(dev, "iommu_map(fqd) failed %d\n", ret);
> - ret = iommu_map(domain, pfdr_a, pfdr_a, pfdr_sz,
> + ret = iommu_map(domain, pfdr_a, pfdr_a, PAGE_ALIGN(pfdr_sz),
> IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> if (ret)
> dev_warn(dev, "iommu_map(pfdr) failed %d\n", ret);
> diff --git a/drivers/soc/fsl/qbman/qman_portal.c
> b/drivers/soc/fsl/qbman/qman_portal.c
> index dfb62f9815e9..bce56da2b01f 100644
> --- a/drivers/soc/fsl/qbman/qman_portal.c
> +++ b/drivers/soc/fsl/qbman/qman_portal.c
> @@ -297,7 +297,7 @@ static int qman_portal_probe(struct platform_device *pdev)
> */
> err = iommu_map(domain,
> addr_phys[0]->start, addr_phys[0]->start,
> - resource_size(addr_phys[0]),
> + PAGE_ALIGN(resource_size(addr_phys[0])),
> IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> if (err)
> dev_warn(dev, "failed to iommu_map() %d\n", err);
> --
> 2.17.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/13] soc/fsl/qman: fixup liodns only on ppc targets
On Fri, Mar 29, 2019 at 9:01 AM wrote:
>
> From: Laurentiu Tudor
>
> ARM SoCs use SMMU so the liodn fixup done in the qman driver is no
> longer making sense and it also breaks the ICID settings inherited
> from u-boot. Do the fixups only for PPC targets.
>
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/soc/fsl/qbman/qman_ccsr.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
> b/drivers/soc/fsl/qbman/qman_ccsr.c
> index 109b38de3176..12e414ca3b03 100644
> --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> @@ -598,6 +598,7 @@ static int qman_init_ccsr(struct device *dev)
> #define LIO_CFG_LIODN_MASK 0x0fff
> void qman_liodn_fixup(u16 channel)
> {
> +#ifdef CONFIG_PPC
> static int done;
> static u32 liodn_offset;
> u32 before, after;
> @@ -617,6 +618,7 @@ void qman_liodn_fixup(u16 channel)
> qm_ccsr_out(REG_REV3_QCSP_LIO_CFG(idx), after);
> else
> qm_ccsr_out(REG_QCSP_LIO_CFG(idx), after);
> +#endif
According to the Linux coding style recommendation, it would be better
to put the #ifdef into the header files
"drivers/soc/fsl/qbman/qman_priv.h". And I'm not sure if this is
needed on PPC when IOMMU(PAMU) driver is not compiled, if not,
probably using CONFIG_PAMU as condition would be even better.
> }
>
> #define IO_CFG_SDEST_MASK 0x00ff
> --
> 2.17.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
On Fri, Mar 29, 2019 at 9:03 AM wrote:
>
> From: Laurentiu Tudor
>
> Add a one-to-one iommu mapping for bman private data memory (FBPR).
> This is required for BMAN to work without faults behind an iommu.
>
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> index 7c3cc968053c..b209c79511bb 100644
> --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> @@ -29,6 +29,7 @@
> */
>
> #include "bman_priv.h"
> +#include
>
> u16 bman_ip_rev;
> EXPORT_SYMBOL(bman_ip_rev);
> @@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device *pdev)
> int ret, err_irq;
> struct device *dev = >dev;
> struct device_node *node = dev->of_node;
> + struct iommu_domain *domain;
> struct resource *res;
> u16 id, bm_pool_cnt;
> u8 major, minor;
> @@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device *pdev)
>
> dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz);
>
> + /* Create an 1-to-1 iommu mapping for FBPR area */
> + domain = iommu_get_domain_for_dev(dev);
> + if (domain) {
> + ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> + IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> + if (ret)
> + dev_warn(dev, "failed to iommu_map() %d\n", ret);
> + }
Like Robin has pointed out, could you explain why the mapping in this
patch and other similar patches cannot be dealt with the dma APIs
automatically? If the current bqman driver doesn't use the dma APIs
correctly, we need to fix that instead of doing the mapping
explicitly.
> +
> bm_set_memory(fbpr_a, fbpr_sz);
>
> err_irq = platform_get_irq(pdev, 0);
> --
> 2.17.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
