public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/7] iommu: add new iommu_ops callback for adding a device with a set of IDs
Date: Mon, 01 Sep 2014 16:39:16 +0200	[thread overview]
Message-ID: <2811939.9L5BJIvoiz@wuerfel> (raw)
In-Reply-To: <20140901081320.GB24430@ulmo>

On Monday 01 September 2014 10:13:22 Thierry Reding wrote:
> On Fri, Aug 29, 2014 at 04:54:26PM +0100, Will Deacon wrote:
> > This patch adds a new function to the iommu_ops structure to allow a
> > device to be added to a specific IOMMU instance along with a set of
> > opaque IDs that are used internally by the IOMMU for identifying and
> > configuring translations.
> > 
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  include/linux/iommu.h | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> I don't really see the point of this new callback. As I understand it,
> the strength of the current .add_device() callback is that it uses only
> the struct device and figures out which exact IOMMU to associate it with
> in case there are multiple IOMMUs.
> 
> Although that doesn't seem to be the general case either. That's really
> been one of the difficulties in dealing with IOMMU. Every driver seems
> to do things very differently and the IOMMU subsystem itself is fairly
> different from other subsystems too.

The problem with add_device is that it assumes that each bus_type only
has one IOMMU instance, and that we know which one that is. Current
implementations do more or less nasty hacks to work around this where
necessary, and we should try to remove those hacks rather than adding
more of them into future drivers.

A smaller issue with the add_device callback is the point at which it
gets called: the caller is in the bus_notifier when the device gets
added, but at a time when we don't have access to the bus-specific
information.

> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index 20f9a527922a..3dd1b99c4542 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -114,6 +114,8 @@ struct iommu_ops {
> >       int (*domain_has_cap)(struct iommu_domain *domain,
> >                             unsigned long cap);
> >       int (*add_device)(struct device *dev);
> > +     int (*add_device_master_ids)(struct device *dev, int count, u32 *ids,
> > +                                  void *data);
> 
> If we want to pass around IOMMU instances I think we should make them
> proper objects rather than some loosely specified void *.

Agreed.

> Also the generic IOMMU binding doesn't require the IOMMU specifier to
> contain master IDs. So this seems to be a callback that would only be
> used by a restricted set of IOMMUs.

No, it should be used by all of them, but we might be passing empty
arguments.

	Arnd

  reply	other threads:[~2014-09-01 14:39 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 15:54 [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-08-29 15:54 ` [RFC PATCH 1/7] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-09-01  7:52   ` Thierry Reding
2014-09-01 14:31     ` Arnd Bergmann
2014-09-01 16:36       ` Will Deacon
2014-09-02  6:56     ` Laurent Pinchart
2014-09-02 14:47   ` Varun Sethi
2014-09-02 15:04     ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 2/7] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-09-01 14:27   ` Arnd Bergmann
2014-09-01 16:20     ` Will Deacon
2014-08-29 15:54 ` [RFC PATCH 3/7] iommu: add new iommu_ops callback for adding a device with a set of IDs Will Deacon
2014-09-01  8:13   ` Thierry Reding
2014-09-01 14:39     ` Arnd Bergmann [this message]
2014-09-01 16:34       ` Will Deacon
2014-09-01 17:18         ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 4/7] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-09-01  8:29   ` Thierry Reding
2014-09-01 14:46     ` Arnd Bergmann
2014-09-01 16:40       ` Will Deacon
2014-09-01 20:18         ` Arnd Bergmann
2014-09-02 10:03           ` Will Deacon
2014-09-02 12:15             ` Arnd Bergmann
2014-09-02 13:05               ` Will Deacon
2014-09-02 14:01                 ` Arnd Bergmann
2014-09-02 20:59                   ` jroedel at suse.de
2014-09-03  9:45                     ` Will Deacon
2014-09-02 15:03               ` Varun Sethi
2014-09-02 15:08                 ` Arnd Bergmann
2014-09-02 10:23       ` Laurent Pinchart
2014-09-02 10:51   ` Laurent Pinchart
2014-09-02 11:03     ` Will Deacon
2014-09-02 19:08       ` Laurent Pinchart
2014-09-02 14:55   ` Varun Sethi
2014-08-29 15:54 ` [RFC PATCH 5/7] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-09-01 14:53   ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 6/7] arm: call iommu_init before of_platform_populate Will Deacon
2014-08-29 15:54 ` [RFC PATCH 7/7] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-09-02  6:26 ` [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Marek Szyprowski
2014-09-02  8:31   ` Will Deacon
2014-09-02  8:48     ` Marek Szyprowski
2014-09-02  8:56       ` Arnd Bergmann
2014-09-02 10:42         ` Marek Szyprowski
2014-09-02 10:57           ` Will Deacon
2014-09-02 12:24             ` Marek Szyprowski
2014-09-02 12:43               ` Arnd Bergmann
2014-09-02 21:50                 ` Laurent Pinchart
2014-09-02 12:22           ` Arnd Bergmann
2014-09-02 12:30             ` Marek Szyprowski
2014-09-02 12:46               ` Arnd Bergmann
2014-09-02 13:11                 ` Marek Szyprowski

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=2811939.9L5BJIvoiz@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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