linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 4/7] iommu: provide helper function to configure an IOMMU for an of master
Date: Tue, 02 Sep 2014 21:10:10 +0200	[thread overview]
Message-ID: <5768908.PeRFksrdyQ@wuerfel> (raw)
In-Reply-To: <1409680587-29818-5-git-send-email-will.deacon@arm.com>

On Tuesday 02 September 2014 18:56:24 Will Deacon wrote:
> +struct iommu_dma_mapping *of_iommu_configure(struct device *dev)
> +{
> +       struct of_phandle_args iommu_spec;
> +       struct iommu_dma_mapping *mapping;
> +       struct bus_type *bus = dev->bus;
> +       const struct iommu_ops *ops = bus->iommu_ops;

I think it would be best to not even introduce the tight coupling
between bus_type and iommu_ops here, one of the main reasons we
are doing this is to break that connection.

Better put the iommu_ops into the iommu_data pointer that gets looked
up per iommu device.

> +       struct iommu_data *iommu = NULL;
> +       int idx = 0;
> +
> +       if (!iommu_present(bus) || !ops->of_xlate)
> +               return NULL;
> +
> +       /*
> +        * We don't currently walk up the tree looking for a parent IOMMU.
> +        * See the `Notes:' section of
> +        * Documentation/devicetree/bindings/iommu/iommu.txt
> +        */
> +        */
> +       while (!of_parse_phandle_with_args(dev->of_node, "iommus",
> +                                          "#iommu-cells", idx,
> +                                          &iommu_spec)) {
> +               struct device_node *np = iommu_spec.np;
> +               struct iommu_data *data = of_iommu_get_data(np);
> +
> +               if (!iommu) {
> +                       if (!ops->of_xlate(dev, &iommu_spec))
> +                               iommu = data;

I would make the first argument of the of_xlate function the iommu_data,
so the code can find the right instance.

Maybe also add an extra argument at the end that can be used by the
PCI code and potentially other drivers with multiple master IDs
behind one "iommus" property to pass some value identifying which of
the masters is meant.

The format of that is unfortunately bus specific and our platform_bus
really covers a number of different hardware buses (AXI, AHB, OPB, ...)
but the caller should be able to provide the data in the right form
that the iommu understands. I would try using a single u64 argument
as a start, hoping that this covers all the buses we need. At least
it's enough for PCI (bus/device/function) and for AXI (requester-id?).

> +               } else if (iommu != data) {
> +                       pr_warn("Rejecting device %s with multiple IOMMU instances\n",
> +                               dev_name(dev));
> +                       iommu = NULL;
> +               }
> +
> +               of_node_put(np);
> +
> +               if (!iommu)
> +                       break;
> +
> +               idx++;
> +       }
> +
> +       if (!iommu)
> +               return NULL;
> +
> +       mapping = devm_kzalloc(dev, sizeof(*mapping), GFP_KERNEL);
> +       if (!mapping)
> +               return NULL;
> 

I don't think it's safe to use devm_* functions here: this is during
device discovery, and this data will be freed if probe() fails or
the device gets removed from a driver.

	Arnd

  reply	other threads:[~2014-09-02 19:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 17:56 [RFC PATCH v2 0/7] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-09-02 17:56 ` [RFC PATCH v2 1/7] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-09-10 11:29   ` Marek Szyprowski
2014-09-02 17:56 ` [RFC PATCH v2 2/7] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-09-05 15:37   ` Grygorii Strashko
2014-09-08 10:31     ` Will Deacon
2014-09-09 14:15       ` Grygorii Strashko
2014-09-02 17:56 ` [RFC PATCH v2 3/7] iommu: add new iommu_ops callback for adding an OF device Will Deacon
2014-09-10 11:16   ` Marek Szyprowski
2014-09-10 11:22     ` Will Deacon
2014-09-10 11:33       ` Will Deacon
2014-09-02 17:56 ` [RFC PATCH v2 4/7] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-09-02 19:10   ` Arnd Bergmann [this message]
2014-09-04 11:26     ` Will Deacon
2014-09-04 11:59       ` Arnd Bergmann
2014-09-04 12:28         ` Will Deacon
2014-09-10 13:01   ` Laurent Pinchart
2014-09-10 13:06     ` Will Deacon
2014-09-02 17:56 ` [RFC PATCH v2 5/7] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-09-02 17:56 ` [RFC PATCH v2 6/7] arm: call iommu_init before of_platform_populate Will Deacon
2014-09-02 18:13   ` Arnd Bergmann
2014-09-02 17:56 ` [RFC PATCH v2 7/7] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-09-02 18:14   ` Arnd Bergmann
2014-09-02 19:11 ` [RFC PATCH v2 0/7] Introduce automatic DMA configuration for IOMMU masters Arnd Bergmann

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=5768908.PeRFksrdyQ@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;
as well as URLs for NNTP newsgroup(s).