From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers
Date: Thu, 04 Dec 2014 19:42:28 +0000 [thread overview]
Message-ID: <5480B924.2010205@arm.com> (raw)
In-Reply-To: <CACxGe6tpFHdP1-5NWiNVAqzXx-diN1xfRbu0AQDyVJ6AU_4RXg@mail.gmail.com>
Hi Grant,
On 04/12/14 17:58, Grant Likely wrote:
[...]
>>>> +struct of_iommu_node {
>>>> + struct list_head list;
>>>> + struct device_node *np;
>>>> + struct iommu_ops *ops;
>>>
>>>
>>> Why can't this be const? Why would anyone ever need to modify it? Also
>>> drivers do define their iommu_ops structures const these days, so you'll
>>> either still have to cast away at some point or the compiler will
>>> complain once you start calling this from drivers.
>>>
>>
>> ...whereas if we make everything const then the drivers that _do_ want to
>> use the private data introduced by this series and thus pass mutable
>> per-instance iommu_ops will be the ones having to cast. We have no users
>> either way until this series is merged, and the need to stash the
>> per-instance data somewhere other than np->data is in the way of getting it
>> merged - this is just a quick hack to address that. I think we've already
>> agreed that mutable per-instance iommu_ops holding private data aren't
>> particularly pleasant and will (hopefully) go away in the next iteration[1],
>> at which point this all changes anyway.
>
> Do you expect drivers to modify that *priv pointer after the ops
> structure is registered? I'd be very surprised if that was the use
> case. It's fine for the driver to register a non-const version, but
> once it is registered, the infrastructure can treat it as const from
> then on.
Possibly not - certainly my current port of the ARM SMMU which makes use
of *priv is only ever reading it - although we did also wave around
reasons for mutable ops like dynamically changing the pgsize_bitmap and
possibly even swizzling individual ops for runtime reconfiguration. On
consideration though, I'd agree that things like that are mad enough to
stay well within individual drivers if they did ever happen, and
certainly shouldn't apply to this bit of the infrastructure at any rate.
Here's a respin the other way - making the get/set infrastructure fully
const and fixing up the callsite in of_iommu_configure instead to avoid
the warning. Trying to chase const-correctness beyond that quickly got
too invasive and out of scope for this fix - I'm just keen to get the
merge-blocker out of the way.
Regards,
Robin.
--->8---
From 9eba5081aaf4fa8ed5158675a6e622be11a64ae2 Mon Sep 17 00:00:00 2001
Message-Id:
<9eba5081aaf4fa8ed5158675a6e622be11a64ae2.1417719305.git.robin.murphy@arm.com>
From: Robin Murphy <robin.murphy@arm.com>
Date: Thu, 4 Dec 2014 11:53:13 +0000
Subject: [PATCH v3] iommu: store DT-probed IOMMU data privately
Since the data pointer in the DT node is public and may be overwritten
by conflicting code, move the DT-probed IOMMU ops to a private list
where they will be safe.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/of_iommu.c | 40 +++++++++++++++++++++++++++++++++++++++-
include/linux/of_iommu.h | 12 ++----------
2 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 73236d3..39f581f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -94,6 +94,44 @@ int of_get_dma_window(struct device_node *dn, const
char *prefix, int index,
}
EXPORT_SYMBOL_GPL(of_get_dma_window);
+struct of_iommu_node {
+ struct list_head list;
+ struct device_node *np;
+ const struct iommu_ops *ops;
+};
+static LIST_HEAD(of_iommu_list);
+static DEFINE_SPINLOCK(of_iommu_lock);
+
+void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
+{
+ struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
+
+ if (WARN_ON(!iommu))
+ return;
+
+ INIT_LIST_HEAD(&iommu->list);
+ iommu->np = np;
+ iommu->ops = ops;
+ spin_lock(&of_iommu_lock);
+ list_add_tail(&iommu->list, &of_iommu_list);
+ spin_unlock(&of_iommu_lock);
+}
+
+const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
+{
+ struct of_iommu_node *node;
+ const struct iommu_ops *ops = NULL;
+
+ spin_lock(&of_iommu_lock);
+ list_for_each_entry(node, &of_iommu_list, list)
+ if (node->np == np) {
+ ops = node->ops;
+ break;
+ }
+ spin_unlock(&of_iommu_lock);
+ return ops;
+}
+
struct iommu_ops *of_iommu_configure(struct device *dev)
{
struct of_phandle_args iommu_spec;
@@ -110,7 +148,7 @@ struct iommu_ops *of_iommu_configure(struct device *dev)
"#iommu-cells", idx,
&iommu_spec)) {
np = iommu_spec.np;
- ops = of_iommu_get_ops(np);
+ ops = (struct iommu_ops *)of_iommu_get_ops(np);
if (!ops || !ops->of_xlate || ops->of_xlate(dev, &iommu_spec))
goto err_put_node;
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index d03abbb..83f6d0b 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -31,16 +31,8 @@ static inline struct iommu_ops
*of_iommu_configure(struct device *dev)
#endif /* CONFIG_OF_IOMMU */
-static inline void of_iommu_set_ops(struct device_node *np,
- const struct iommu_ops *ops)
-{
- np->data = (struct iommu_ops *)ops;
-}
-
-static inline struct iommu_ops *of_iommu_get_ops(struct device_node *np)
-{
- return np->data;
-}
+void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
+const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
extern struct of_device_id __iommu_of_table;
--
1.9.1
next prev parent reply other threads:[~2014-12-04 19:42 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 16:57 [PATCH v6 0/8] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-12-01 16:57 ` [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-12-01 23:54 ` Rob Herring
2014-12-02 9:23 ` Marek Szyprowski
2014-12-02 9:36 ` Arnd Bergmann
2014-12-02 9:43 ` Will Deacon
2014-12-02 12:05 ` Thierry Reding
2014-12-02 10:30 ` Pantelis Antoniou
2014-12-02 14:16 ` Grant Likely
2014-12-03 19:57 ` Arnd Bergmann
2014-12-04 9:49 ` Will Deacon
2014-12-04 10:10 ` Arnd Bergmann
2014-12-04 10:21 ` Will Deacon
2014-12-04 11:19 ` Arnd Bergmann
2014-12-04 11:25 ` Grant Likely
2014-12-04 11:52 ` Will Deacon
2014-12-04 12:43 ` Grant Likely
2014-12-04 12:26 ` Robin Murphy
2014-12-04 12:42 ` Grant Likely
2014-12-04 13:43 ` Robin Murphy
2014-12-04 13:58 ` Grant Likely
2014-12-04 14:49 ` Thierry Reding
2014-12-04 17:42 ` Robin Murphy
2014-12-04 17:58 ` Grant Likely
2014-12-04 19:42 ` Robin Murphy [this message]
2014-12-05 12:10 ` Will Deacon
2014-12-05 12:21 ` Arnd Bergmann
2014-12-05 12:35 ` Robin Murphy
2014-12-05 13:06 ` Grant Likely
2014-12-05 13:18 ` Thierry Reding
2014-12-05 13:21 ` Grant Likely
2014-12-05 13:31 ` Thierry Reding
2014-12-05 13:49 ` Marek Szyprowski
2014-12-04 12:51 ` Arnd Bergmann
2014-12-01 16:57 ` [PATCH v6 2/8] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-12-01 22:58 ` Rob Herring
2014-12-02 9:16 ` Arnd Bergmann
2014-12-01 16:57 ` [PATCH v6 3/8] iommu: add new iommu_ops callback for adding an OF device Will Deacon
2014-12-01 16:57 ` [PATCH v6 4/8] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-12-01 16:57 ` [PATCH v6 5/8] iommu: fix initialization without 'add_device' callback Will Deacon
2014-12-01 16:57 ` [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-12-01 23:06 ` Rob Herring
2014-12-10 14:52 ` Rob Clark
2014-12-10 15:08 ` Will Deacon
2014-12-10 15:54 ` Robin Murphy
2014-12-10 15:56 ` Laurent Pinchart
2014-12-14 15:49 ` Laurent Pinchart
2014-12-14 15:59 ` Laurent Pinchart
2014-12-15 17:10 ` Will Deacon
2014-12-15 16:40 ` Will Deacon
2014-12-15 17:16 ` Laurent Pinchart
2014-12-15 18:09 ` Will Deacon
2014-12-16 12:08 ` Arnd Bergmann
2014-12-17 12:09 ` Will Deacon
2014-12-17 14:15 ` Arnd Bergmann
2014-12-17 14:45 ` Will Deacon
2014-12-17 15:35 ` Arnd Bergmann
2014-12-17 17:17 ` Will Deacon
2014-12-17 19:48 ` Arnd Bergmann
2014-12-21 10:04 ` Will Deacon
2014-12-22 13:36 ` Arnd Bergmann
2015-01-07 18:57 ` Will Deacon
2015-01-07 19:29 ` Arnd Bergmann
2015-01-08 10:53 ` Will Deacon
2014-12-17 14:27 ` Robin Murphy
2014-12-17 15:01 ` Will Deacon
2014-12-17 15:38 ` Arnd Bergmann
2014-12-17 17:20 ` Will Deacon
2014-12-17 0:05 ` Laurent Pinchart
2014-12-14 15:51 ` Laurent Pinchart
2014-12-15 11:32 ` Will Deacon
2014-12-17 0:19 ` Laurent Pinchart
2014-12-17 11:14 ` Will Deacon
2014-12-01 16:57 ` [PATCH v6 7/8] arm: call iommu_init before of_platform_populate Will Deacon
2014-12-01 16:57 ` [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2015-01-14 9:00 ` Alexandre Courbot
2015-01-14 10:46 ` Will Deacon
2015-01-14 13:51 ` Heiko Stübner
2015-01-14 19:17 ` Will Deacon
2015-01-15 8:30 ` Thierry Reding
2015-01-15 11:13 ` Will Deacon
2015-01-15 2:57 ` Alexandre Courbot
2015-01-15 8:28 ` Thierry Reding
2015-01-15 11:12 ` Will Deacon
2015-01-15 23:18 ` Laurent Pinchart
2015-01-18 6:54 ` Alexandre Courbot
2015-01-18 11:18 ` Laurent Pinchart
2015-01-19 11:12 ` Will Deacon
2015-01-19 11:34 ` Laurent Pinchart
2015-01-19 12:31 ` Thierry Reding
2015-01-20 15:14 ` Laurent Pinchart
2015-01-20 15:19 ` Will Deacon
2015-01-20 15:21 ` Will Deacon
2015-01-20 15:35 ` Laurent Pinchart
2015-01-19 12:43 ` Thierry Reding
2015-01-19 12:50 ` Will Deacon
2015-01-19 13:36 ` Thierry Reding
2015-01-20 13:50 ` Laurent Pinchart
2015-01-19 16:13 ` Arnd Bergmann
2015-01-20 16:41 ` Laurent Pinchart
2015-01-19 12:36 ` Thierry Reding
2015-01-19 15:52 ` Arnd Bergmann
2015-01-19 16:21 ` Thierry Reding
2015-01-19 17:02 ` Arnd Bergmann
2015-01-20 13:47 ` Laurent Pinchart
2015-01-19 12:49 ` Thierry Reding
2015-01-20 14:05 ` Laurent Pinchart
2014-12-05 7:12 ` [PATCH v6 0/8] Introduce automatic DMA configuration for IOMMU masters Olof Johansson
2014-12-05 12:11 ` Will Deacon
2014-12-15 0:24 ` [PATCH/RFC] iommu/ipmmu-vmsa: Use DT-based instantiation Laurent Pinchart
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=5480B924.2010205@arm.com \
--to=robin.murphy@arm.com \
--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).