All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
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 09:51:12 +0000	[thread overview]
Message-ID: <20200304095112.GY25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <78f175be-0701-b6cd-8feb-1343f9982d4c@nxp.com>

On Wed, Mar 04, 2020 at 11:42:16AM +0200, Laurentiu Tudor wrote:
> On 04.03.2020 11:33, Russell King - ARM Linux admin wrote:
> > On Wed, Mar 04, 2020 at 10:56:06AM +0200, Laurentiu Tudor wrote:
> > > 
> > > On 04.03.2020 00:17, Russell King - ARM Linux admin wrote:
> > > > On Tue, Mar 03, 2020 at 05:55:05PM +0200, Laurentiu Tudor wrote:
> > > > >   From c98dc05cdd45ae923654f2427985bd28bcde4bb2 Mon Sep 17 00:00:00 2001
> > > > > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > > > Date: Thu, 13 Feb 2020 11:59:12 +0200
> > > > > Subject: [PATCH 1/4] bus: fsl-mc: add custom .dma_configure implementation
> > > > > Content-Type: text/plain; charset="us-ascii"
> > > > > 
> > > > > The devices on this bus are not discovered by way of device tree
> > > > > but by queries to the firmware. It makes little sense to trick the
> > > > > generic of layer into thinking that these devices are of related so
> > > > > that we can get our dma configuration. Instead of doing that, add
> > > > > our custom dma configuration implementation.
> > > > 
> > > > Firstly, applying this to v5.5 results in a build failure, due to a
> > > > missing linux/iommu.h include.
> > > > 
> > > > Secondly, this on its own appears to make the DPAA2 network interfaces
> > > > completely disappear.  Looking in /sys/bus/fsl-mc/drivers/*, none of
> > > > the DPAA2 drivers are bound to anything, and looking in
> > > > /sys/bus/fsl-mc/devices/, there is:
> > > > 
> > > > lrwxrwxrwx 1 root root 0 Mar  3 22:06 dprc.1 -> ../../../devices/platform/soc/80c000000.fsl-mc/dprc.1
> > > > 
> > > > This is booting with u-boot, so using DT rather than ACPI.
> > > > 
> > > > > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > > > ---
> > > > >    drivers/bus/fsl-mc/fsl-mc-bus.c | 42 ++++++++++++++++++++++++++++++++-
> > > > >    1 file changed, 41 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > > > > index 36eb25f82c8e..3df015eedae4 100644
> > > > > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > > > > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > > > > @@ -132,11 +132,51 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > > >    static int fsl_mc_dma_configure(struct device *dev)
> > > > >    {
> > > > >    	struct device *dma_dev = dev;
> > > > > +	struct iommu_fwspec *fwspec;
> > > > > +	const struct iommu_ops *iommu_ops;
> > > > > +	struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> > > > > +	int ret;
> > > > > +	u32 icid;
> > > > > +
> > > > > +	/* Skip DMA setup for devices that are not DMA masters */
> > > > > +	if (dev->type == &fsl_mc_bus_dpmcp_type ||
> > > > > +	    dev->type == &fsl_mc_bus_dpbp_type ||
> > > > > +	    dev->type == &fsl_mc_bus_dpcon_type ||
> > > > > +	    dev->type == &fsl_mc_bus_dpio_type)
> > > > > +		return 0;
> > > > >    	while (dev_is_fsl_mc(dma_dev))
> > > > >    		dma_dev = dma_dev->parent;
> > > > > -	return of_dma_configure(dev, dma_dev->of_node, 0);
> > > > > +	fwspec = dev_iommu_fwspec_get(dma_dev);
> > > > > +	if (!fwspec)
> > > > > +		return -ENODEV;
> > > > 
> > > > The problem appears to be here - fwspec is NULL for dprc.1.
> > > 
> > > Ok, that's because the iommu config is missing from the DT node that's
> > > exposing the MC firmware. I've attached a fresh set of patches that include
> > > on top the missing config and a workaround that makes MC work over SMMU.
> > > Also added the missing #include, thanks for pointing out.
> > > Let me know how it goes.
> > 
> > Shouldn't patch 6 should be first in the series, so that patch 1 does
> > not cause a regression and bisectability damage?
> > 
> 
> Correct, width one comment: both 5 and 6 should go first. Once iommu-map is
> added in the device tree the workaround for MC with the
> arm-smmu.disable_bypass boot arg will no longer work.

So, wouldn't it be reasonable to arrange the patch series like that?

-- 
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  9:51 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 [this message]
2020-03-04  9:56                         ` Laurentiu Tudor
2020-03-04 10:07                           ` Russell King - ARM Linux admin
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=20200304095112.GY25745@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.