public inbox for iommu@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	Olof Johansson <olof@lixom.net>
Cc: Diana Madalina Craciun <diana.craciun@nxp.com>,
	iommu@lists.linux-foundation.org,
	Robin Murphy <robin.murphy@arm.com>,
	Ioana Ciornei <ioana.ciornei@nxp.com>
Subject: Re: [PATCH] iommu: silence iommu group prints
Date: Wed, 4 Mar 2020 10:07:13 +0000	[thread overview]
Message-ID: <20200304100713.GZ25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <b9f4e9ad-033f-b5cf-9578-38f8367ef8cd@nxp.com>

On Wed, Mar 04, 2020 at 11:56:53AM +0200, Laurentiu Tudor wrote:
> From 44ae46501b5379bd0890df87fd3827248626ed03 Mon Sep 17 00:00:00 2001
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Date: Tue, 1 Oct 2019 16:22:48 +0300
> Subject: [PATCH 1/6] bus: fsl-mc: make mc work with smmu disable bypass on
> Content-Type: text/plain; charset="us-ascii"
> 
> Since this commit [1] booting kernel on MC based chips started to
> fail because this firmware starts before the kernel and as soon as
> SMMU is probed it starts to trigger contiguous faults.

I think you mean "continuous" here.

> This is a workaround that allows MC firmware to run with SMMU
> in disable bypass mode. It consists of the following steps:
>  1. pause the firmware at early boot to get a chance to setup SMMU
>  2. request direct mapping for MC device
>  3. resume the firmware
> The workaround relies on the fact that no state is lost when
> pausing / resuming firmware, as per the docs.
> With this patch, platforms with MC firmware can now boot without
> having to change the default config to set:
>   CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n

This alone is a definite improvement, and has been needed for a while.
Please submit this patch with an appropriate Fixes: tag so stable trees
can pick it up.

> [1] 954a03be033 ("iommu/arm-smmu: Break insecure users by disabling bypass by default")

Please put this where you're referencing it above - it's fine to wrap
the description of the commit when using it in the body of the commit
message.  However, that should _never_ when providing a Fixes: tag
(linux-next has a script which will detect and complain about broken
Fixes: tags.)

Thanks.

> 
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> ---
>  drivers/bus/fsl-mc/fsl-mc-bus.c | 53 +++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index a0f8854acb3a..683a6401ffe8 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -18,6 +18,8 @@
>  #include <linux/bitops.h>
>  #include <linux/msi.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/iommu.h>
> +#include <linux/io.h>
>  
>  #include "fsl-mc-private.h"
>  
> @@ -889,6 +891,12 @@ static int get_mc_addr_translation_ranges(struct device *dev,
>  	return 0;
>  }
>  
> +#define FSL_MC_GCR1	0x0
> +#define GCR1_P1_STOP	BIT(31)
> +
> +static u32 boot_gcr1;
> +static void __iomem *fsl_mc_regs;
> +
>  /**
>   * fsl_mc_bus_probe - callback invoked when the root MC bus is being
>   * added
> @@ -906,6 +914,21 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
>  	struct mc_version mc_version;
>  	struct resource res;
>  
> +	/*
> +	 * The MC firmware requires full access to the whole address space plus
> +	 * it has no way of dealing with any kind of address translation, so
> +	 * request direct mapping for it.
> +	 */
> +	error = iommu_request_dm_for_dev(&pdev->dev);
> +	if (error)
> +		dev_warn(&pdev->dev, "iommu_request_dm_for_dev() failed: %d\n",
> +			 error);
> +
> +	if (fsl_mc_regs) {
> +		/* Resume the firmware */
> +		writel(boot_gcr1 & ~GCR1_P1_STOP, fsl_mc_regs + FSL_MC_GCR1);
> +	}
> +
>  	mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
>  	if (!mc)
>  		return -ENOMEM;
> @@ -990,6 +1013,13 @@ static int fsl_mc_bus_remove(struct platform_device *pdev)
>  	if (!fsl_mc_is_root_dprc(&mc->root_mc_bus_dev->dev))
>  		return -EINVAL;
>  
> +	/*
> +	 * Pause back the firmware so that it doesn't trigger faults by the
> +	 * time SMMU gets brought down.
> +	 */
> +	writel(boot_gcr1 | GCR1_P1_STOP, fsl_mc_regs + FSL_MC_GCR1);
> +	iounmap(fsl_mc_regs);
> +
>  	fsl_mc_device_remove(mc->root_mc_bus_dev);
>  
>  	fsl_destroy_mc_io(mc->root_mc_bus_dev->mc_io);
> @@ -1018,6 +1048,8 @@ static struct platform_driver fsl_mc_bus_driver = {
>  static int __init fsl_mc_bus_driver_init(void)
>  {
>  	int error;
> +	struct device_node *np;
> +	struct resource res;
>  
>  	error = bus_register(&fsl_mc_bus_type);
>  	if (error < 0) {
> @@ -1039,9 +1071,30 @@ static int __init fsl_mc_bus_driver_init(void)
>  	if (error < 0)
>  		goto error_cleanup_dprc_driver;
>  
> +	np = of_find_matching_node(NULL, fsl_mc_bus_match_table);
> +	if (np && of_device_is_available(np)) {
> +		error = of_address_to_resource(np, 1, &res);
> +		if (error)
> +			goto error_cleanup_dprc_driver;
> +		fsl_mc_regs = ioremap(res.start, resource_size(&res));
> +		if (!fsl_mc_regs) {
> +			error = -ENXIO;
> +			goto error_cleanup_dprc_driver;
> +		}
> +
> +		boot_gcr1 = readl(fsl_mc_regs + FSL_MC_GCR1);
> +		/*
> +		 * If found running, pause MC firmware in order to get a chance
> +		 * to setup SMMU for it.
> +		 */
> +		if (!(boot_gcr1 & GCR1_P1_STOP))
> +			writel(boot_gcr1 | GCR1_P1_STOP,  fsl_mc_regs + FSL_MC_GCR1);
> +	}
> +
>  	return 0;
>  
>  error_cleanup_dprc_driver:
> +	iounmap(fsl_mc_regs);
>  	dprc_driver_exit();
>  
>  error_cleanup_driver:
> -- 
> 2.17.1
> 


-- 
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

  reply	other threads:[~2020-03-04 10:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 11:57 [PATCH] iommu: silence iommu group prints Russell King
2020-02-27 13:44 ` Robin Murphy
2020-02-27 13:48   ` Russell King - ARM Linux admin
2020-02-27 18:19     ` Robin Murphy
2020-02-27 19:00       ` Russell King - ARM Linux admin
2020-02-28  2:16 ` Lu Baolu
2020-02-28  9:33   ` John Garry
2020-02-28 10:06     ` Russell King - ARM Linux admin
2020-02-28 18:32       ` Robin Murphy
2020-03-02 11:48         ` Laurentiu Tudor
2020-03-03 14:18         ` Laurentiu Tudor
2020-03-03 15:49           ` Russell King - ARM Linux admin
2020-03-03 15:55             ` Laurentiu Tudor
2020-03-03 22:17               ` Russell King - ARM Linux admin
2020-03-04  8:56                 ` Laurentiu Tudor
2020-03-04  9:33                   ` Russell King - ARM Linux admin
2020-03-04  9:42                     ` Laurentiu Tudor
2020-03-04  9:51                       ` Russell King - ARM Linux admin
2020-03-04  9:56                         ` Laurentiu Tudor
2020-03-04 10:07                           ` Russell King - ARM Linux admin [this message]
2020-03-04 10:33                             ` Laurentiu Tudor
2020-03-04 10:52                               ` Russell King - ARM Linux admin
2020-03-04 11:26                                 ` Laurentiu Tudor
2020-03-02 15:44 ` Joerg Roedel

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=20200304100713.GZ25745@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=diana.craciun@nxp.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=laurentiu.tudor@nxp.com \
    --cc=olof@lixom.net \
    --cc=robin.murphy@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox