From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 01/15] drivers: iommu: add FWNODE_IOMMU fwnode type
Date: Tue, 23 Aug 2016 14:49:38 +0100 [thread overview]
Message-ID: <20160823134938.GA9953@red-moon> (raw)
In-Reply-To: <1471274620-20754-2-git-send-email-lorenzo.pieralisi@arm.com>
Hi Rafael,
On Mon, Aug 15, 2016 at 04:23:26PM +0100, Lorenzo Pieralisi wrote:
> On systems booting with a device tree, every struct device is
> associated with a struct device_node, that represents its DT
> representation. The device node can be used in generic kernel
> contexts (eg IRQ translation, IOMMU streamid mapping), to
> retrieve the properties associated with the device and carry
> out kernel operation accordingly. Owing to the 1:1 relationship
> between the device and its device_node, the device_node can also
> be used as a look-up token for the device (eg looking up a device
> through its device_node), to retrieve the device in kernel paths
> where the device_node is available.
>
> On systems booting with ACPI, the same abstraction provided by
> the device_node is required to provide look-up functionality.
>
> Therefore, mirroring the approach implemented in the IRQ domain
> kernel layer, this patch adds an additional fwnode type FWNODE_IOMMU.
>
> This patch also implements a glue kernel layer that allows to
> allocate/free FWNODE_IOMMU fwnode_handle structures and associate
> them with IOMMU devices.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> include/linux/fwnode.h | 1 +
> include/linux/iommu.h | 25 +++++++++++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
> index 8516717..6e10050 100644
> --- a/include/linux/fwnode.h
> +++ b/include/linux/fwnode.h
> @@ -19,6 +19,7 @@ enum fwnode_type {
> FWNODE_ACPI_DATA,
> FWNODE_PDATA,
> FWNODE_IRQCHIP,
> + FWNODE_IOMMU,
> };
Are you ok with this fwnode usage ? It is quite key to the rest
of this series and I would need to know in order to make progress
on it please.
Platform devices created out of IORT tables are not ACPI devices
(I could create fake ones as we do for FADT power button, I do not
see any particular reason to prefer that approach over this one) and
in order to identify the device through a fwnode_handle (that, as for
IRQCHIP is nothing but a token used for look-up) that's what I came
up with.
Any feedback on the rest of the series is very welcome and needed
too, thanks.
Lorenzo
> struct fwnode_handle {
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index a35fb8b..6f703cb 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -38,6 +38,7 @@ struct bus_type;
> struct device;
> struct iommu_domain;
> struct notifier_block;
> +struct fwnode_handle;
>
> /* iommu fault flags */
> #define IOMMU_FAULT_READ 0x0
> @@ -543,4 +544,28 @@ static inline void iommu_device_unlink(struct device *dev, struct device *link)
>
> #endif /* CONFIG_IOMMU_API */
>
> +/* IOMMU fwnode handling */
> +static inline bool is_fwnode_iommu(struct fwnode_handle *fwnode)
> +{
> + return fwnode && fwnode->type == FWNODE_IOMMU;
> +}
> +
> +static inline struct fwnode_handle *iommu_alloc_fwnode(void)
> +{
> + struct fwnode_handle *fwnode;
> +
> + fwnode = kzalloc(sizeof(struct fwnode_handle), GFP_ATOMIC);
> + fwnode->type = FWNODE_IOMMU;
> +
> + return fwnode;
> +}
> +
> +static inline void iommu_free_fwnode(struct fwnode_handle *fwnode)
> +{
> + if (WARN_ON(!is_fwnode_iommu(fwnode)))
> + return;
> +
> + kfree(fwnode);
> +}
> +
> #endif /* __LINUX_IOMMU_H */
> --
> 2.6.4
>
next prev parent reply other threads:[~2016-08-23 13:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 15:23 [PATCH v4 00/15] ACPI IORT ARM SMMU v3 support Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 01/15] drivers: iommu: add FWNODE_IOMMU fwnode type Lorenzo Pieralisi
2016-08-23 13:49 ` Lorenzo Pieralisi [this message]
2016-09-05 11:11 ` Hanjun Guo
2016-08-15 15:23 ` [PATCH v4 02/15] drivers: iommu: implement arch_{set/get}_iommu_fwspec API Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 03/15] drivers: acpi: iort: introduce linker section for IORT entries probing Lorenzo Pieralisi
2016-09-05 11:42 ` Hanjun Guo
2016-08-15 15:23 ` [PATCH v4 04/15] drivers: acpi: iort: add support for IOMMU fwnode registration Lorenzo Pieralisi
2016-09-05 13:00 ` Hanjun Guo
2016-08-15 15:23 ` [PATCH v4 05/15] drivers: platform: add fwnode base platform devices retrieval Lorenzo Pieralisi
2016-09-05 13:19 ` Hanjun Guo
2016-09-05 14:57 ` Lorenzo Pieralisi
2016-09-06 12:08 ` Hanjun Guo
2016-08-15 15:23 ` [PATCH v4 06/15] drivers: iommu: make iommu_fwspec OF agnostic Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 07/15] drivers: acpi: implement acpi_dma_configure Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 08/15] drivers: acpi: iort: add node match function Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 09/15] drivers: acpi: iort: add support for ARM SMMU platform devices creation Lorenzo Pieralisi
2016-08-18 10:50 ` Dennis Chen
2016-08-18 10:55 ` Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 10/15] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 11/15] drivers: iommu: arm-smmu-v3: enable ACPI driver initialization Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 12/15] drivers: iommu: arm-smmu-v3: add IORT configuration Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 13/15] drivers: acpi: iort: replace rid map type with type mask Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 14/15] drivers: acpi: iort: add single mapping function Lorenzo Pieralisi
2016-08-15 15:23 ` [PATCH v4 15/15] drivers: acpi: iort: introduce iort_iommu_configure Lorenzo Pieralisi
2016-09-05 9:41 ` [PATCH v4 00/15] ACPI IORT ARM SMMU v3 support Hanjun Guo
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=20160823134938.GA9953@red-moon \
--to=lorenzo.pieralisi@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).