From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: iommu@lists.linux-foundation.org,
Will Deacon <will.deacon@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Joerg Roedel <joro@8bytes.org>,
Marc Zyngier <marc.zyngier@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Tomasz Nowicki <tn@semihalf.com>, Jon Masters <jcm@redhat.com>,
Sinan Kaya <okaya@codeaurora.org>,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v3 05/13] drivers: iommu: make iommu_fwspec OF agnostic
Date: Mon, 25 Jul 2016 16:41:03 +0100 [thread overview]
Message-ID: <20160725154103.GA28507@red-moon> (raw)
In-Reply-To: <1499f802-5f98-b0c0-d3aa-dabcac81e84e@arm.com>
On Mon, Jul 25, 2016 at 04:09:55PM +0100, Robin Murphy wrote:
> Hi Lorenzo,
>
> On 20/07/16 12:23, Lorenzo Pieralisi wrote:
> > The iommu_fwspec structure, used to hold per device iommu configuration
> > data is not OF specific and therefore can be moved to a generic
> > and OF independent compilation unit.
> >
> > In particular, the iommu_fwspec handling hinges on the device_node
> > pointer to identify the IOMMU device associated with the iommu_fwspec
> > structure, that is easily converted to a more generic fwnode_handle
> > pointer that can cater for OF and non-OF (ie ACPI) systems.
> >
> > Create the files and related Kconfig entry to decouple iommu_fwspec
> > structure from the OF iommu kernel layer.
> >
> > Given that the current iommu_fwspec implementation relies on
> > the arch specific struct device.archdata.iommu field in its
> > implementation, by making the code standalone and independent
> > of the OF layer this patch makes sure that the iommu_fwspec
> > kernel code can be selected only on arches implementing the
> > struct device.archdata.iommu field by adding an explicit
> > arch dependency in its config entry.
> >
> > Current drivers using the iommu_fwspec for streamid translation
> > are converted to the new iommu_fwspec API by simply converting
> > the device_node to its fwnode_handle pointer.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Hanjun Guo <hanjun.guo@linaro.org>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Joerg Roedel <joro@8bytes.org>
> > ---
> > drivers/iommu/Kconfig | 4 ++
> > drivers/iommu/Makefile | 1 +
> > drivers/iommu/arm-smmu-v3.c | 13 +++--
> > drivers/iommu/iommu-fwspec.c | 114 +++++++++++++++++++++++++++++++++++++++++++
> > drivers/iommu/of_iommu.c | 52 --------------------
> > include/linux/iommu-fwspec.h | 60 +++++++++++++++++++++++
> > include/linux/of_iommu.h | 24 +++------
> > 7 files changed, 196 insertions(+), 72 deletions(-)
> > create mode 100644 drivers/iommu/iommu-fwspec.c
> > create mode 100644 include/linux/iommu-fwspec.h
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index d1c66af..2b26bfb 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -67,6 +67,10 @@ config OF_IOMMU
> > def_bool y
> > depends on OF && IOMMU_API
> >
> > +config IOMMU_FWSPEC
> > + def_bool y
> > + depends on ARM64 && IOMMU_API
>
> I think that could be at least (ARM || ARM64).
Yes agreed.
> > # IOMMU-agnostic DMA-mapping layer
> > config IOMMU_DMA
> > bool
>
> [...]
>
> > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> > index 308791f..2362232 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -15,13 +15,8 @@ extern void of_iommu_init(void);
> > extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> > struct device_node *master_np);
> >
> > -struct iommu_fwspec {
> > - const struct iommu_ops *iommu_ops;
> > - struct device_node *iommu_np;
> > - void *iommu_priv;
> > - unsigned int num_ids;
> > - u32 ids[];
> > -};
> > +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);
>
> Is there some reason we need to retain the existing definitions of
> these? I was assuming we'd be able to move the entire implementation
> over to the fwspec code and leave behind nothing more than trivial
> wrappers, e.g.:
>
> #define of_iommu_get_ops(np) iommu_fwspec_get_ops(&(np)->fwnode_handle)
Yep, that's exactly what I did but then I was bitten by config
dependencies. If we implement of_iommu_get/set_ops() as wrappers,
we have to compile iommu_fwspec_get/set_ops() on arches that may
not have struct dev_archdata.iommu, unless we introduce yet another
config symbol to avoid compiling that code (see eg iommu_fwspec_init(),
we can't compile it on eg x86 even though we do need of_iommu_get_ops()
on it - so iommu_fwspec_get_ops(), that lives in the same compilation
unit as eg iommu_fwspec_init()).
So short answer is: there is no reason apart from dev_archdata.iommu
being arch specific, if we were able to move iommu_fwspec to generic
code (ie struct device, somehow) I would certainly get rid of this
stupid code duplication (or as I said I can add a config entry for
that, more ideas are welcome).
Thanks,
Lorenzo
>
> Robin.
>
> > #else
> >
> > @@ -39,17 +34,14 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> > return NULL;
> > }
> >
> > -struct iommu_fwspec;
> > -
> > -#endif /* CONFIG_OF_IOMMU */
> > +static inline void of_iommu_set_ops(struct device_node *np,
> > + const struct iommu_ops *ops)
> > +{ }
> >
> > -int iommu_fwspec_init(struct device *dev, struct device_node *iommu_np);
> > -void iommu_fwspec_free(struct device *dev);
> > -int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> > -struct iommu_fwspec *dev_iommu_fwspec(struct device *dev);
> > +static inline const struct iommu_ops *
> > +of_iommu_get_ops(struct device_node *np) { return NULL; }
> >
> > -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);
> > +#endif /* CONFIG_OF_IOMMU */
> >
> > extern struct of_device_id __iommu_of_table;
> >
> >
>
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 05/13] drivers: iommu: make iommu_fwspec OF agnostic
Date: Mon, 25 Jul 2016 16:41:03 +0100 [thread overview]
Message-ID: <20160725154103.GA28507@red-moon> (raw)
In-Reply-To: <1499f802-5f98-b0c0-d3aa-dabcac81e84e@arm.com>
On Mon, Jul 25, 2016 at 04:09:55PM +0100, Robin Murphy wrote:
> Hi Lorenzo,
>
> On 20/07/16 12:23, Lorenzo Pieralisi wrote:
> > The iommu_fwspec structure, used to hold per device iommu configuration
> > data is not OF specific and therefore can be moved to a generic
> > and OF independent compilation unit.
> >
> > In particular, the iommu_fwspec handling hinges on the device_node
> > pointer to identify the IOMMU device associated with the iommu_fwspec
> > structure, that is easily converted to a more generic fwnode_handle
> > pointer that can cater for OF and non-OF (ie ACPI) systems.
> >
> > Create the files and related Kconfig entry to decouple iommu_fwspec
> > structure from the OF iommu kernel layer.
> >
> > Given that the current iommu_fwspec implementation relies on
> > the arch specific struct device.archdata.iommu field in its
> > implementation, by making the code standalone and independent
> > of the OF layer this patch makes sure that the iommu_fwspec
> > kernel code can be selected only on arches implementing the
> > struct device.archdata.iommu field by adding an explicit
> > arch dependency in its config entry.
> >
> > Current drivers using the iommu_fwspec for streamid translation
> > are converted to the new iommu_fwspec API by simply converting
> > the device_node to its fwnode_handle pointer.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Hanjun Guo <hanjun.guo@linaro.org>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Joerg Roedel <joro@8bytes.org>
> > ---
> > drivers/iommu/Kconfig | 4 ++
> > drivers/iommu/Makefile | 1 +
> > drivers/iommu/arm-smmu-v3.c | 13 +++--
> > drivers/iommu/iommu-fwspec.c | 114 +++++++++++++++++++++++++++++++++++++++++++
> > drivers/iommu/of_iommu.c | 52 --------------------
> > include/linux/iommu-fwspec.h | 60 +++++++++++++++++++++++
> > include/linux/of_iommu.h | 24 +++------
> > 7 files changed, 196 insertions(+), 72 deletions(-)
> > create mode 100644 drivers/iommu/iommu-fwspec.c
> > create mode 100644 include/linux/iommu-fwspec.h
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index d1c66af..2b26bfb 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -67,6 +67,10 @@ config OF_IOMMU
> > def_bool y
> > depends on OF && IOMMU_API
> >
> > +config IOMMU_FWSPEC
> > + def_bool y
> > + depends on ARM64 && IOMMU_API
>
> I think that could be at least (ARM || ARM64).
Yes agreed.
> > # IOMMU-agnostic DMA-mapping layer
> > config IOMMU_DMA
> > bool
>
> [...]
>
> > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> > index 308791f..2362232 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -15,13 +15,8 @@ extern void of_iommu_init(void);
> > extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> > struct device_node *master_np);
> >
> > -struct iommu_fwspec {
> > - const struct iommu_ops *iommu_ops;
> > - struct device_node *iommu_np;
> > - void *iommu_priv;
> > - unsigned int num_ids;
> > - u32 ids[];
> > -};
> > +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);
>
> Is there some reason we need to retain the existing definitions of
> these? I was assuming we'd be able to move the entire implementation
> over to the fwspec code and leave behind nothing more than trivial
> wrappers, e.g.:
>
> #define of_iommu_get_ops(np) iommu_fwspec_get_ops(&(np)->fwnode_handle)
Yep, that's exactly what I did but then I was bitten by config
dependencies. If we implement of_iommu_get/set_ops() as wrappers,
we have to compile iommu_fwspec_get/set_ops() on arches that may
not have struct dev_archdata.iommu, unless we introduce yet another
config symbol to avoid compiling that code (see eg iommu_fwspec_init(),
we can't compile it on eg x86 even though we do need of_iommu_get_ops()
on it - so iommu_fwspec_get_ops(), that lives in the same compilation
unit as eg iommu_fwspec_init()).
So short answer is: there is no reason apart from dev_archdata.iommu
being arch specific, if we were able to move iommu_fwspec to generic
code (ie struct device, somehow) I would certainly get rid of this
stupid code duplication (or as I said I can add a config entry for
that, more ideas are welcome).
Thanks,
Lorenzo
>
> Robin.
>
> > #else
> >
> > @@ -39,17 +34,14 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> > return NULL;
> > }
> >
> > -struct iommu_fwspec;
> > -
> > -#endif /* CONFIG_OF_IOMMU */
> > +static inline void of_iommu_set_ops(struct device_node *np,
> > + const struct iommu_ops *ops)
> > +{ }
> >
> > -int iommu_fwspec_init(struct device *dev, struct device_node *iommu_np);
> > -void iommu_fwspec_free(struct device *dev);
> > -int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> > -struct iommu_fwspec *dev_iommu_fwspec(struct device *dev);
> > +static inline const struct iommu_ops *
> > +of_iommu_get_ops(struct device_node *np) { return NULL; }
> >
> > -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);
> > +#endif /* CONFIG_OF_IOMMU */
> >
> > extern struct of_device_id __iommu_of_table;
> >
> >
>
next prev parent reply other threads:[~2016-07-25 15:41 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 11:23 [RFC PATCH v3 00/13] ACPI IORT ARM SMMU v3 support Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 03/13] drivers: acpi: iort: add support for IOMMU fwnode registration Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 06/13] drivers: acpi: implement acpi_dma_configure Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
[not found] ` <1469013815-24380-1-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2016-07-20 11:23 ` [RFC PATCH v3 01/13] drivers: iommu: add FWNODE_IOMMU fwnode type Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 02/13] drivers: acpi: iort: introduce linker section for IORT entries probing Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 04/13] drivers: platform: add fwnode base platform devices retrieval Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 05/13] drivers: iommu: make iommu_fwspec OF agnostic Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-25 15:09 ` Robin Murphy
2016-07-25 15:09 ` Robin Murphy
[not found] ` <1499f802-5f98-b0c0-d3aa-dabcac81e84e-5wv7dgnIgG8@public.gmane.org>
2016-07-25 15:21 ` Rob Herring
2016-07-25 15:21 ` Rob Herring
2016-07-25 15:21 ` Rob Herring
2016-07-25 15:56 ` Lorenzo Pieralisi
2016-07-25 15:56 ` Lorenzo Pieralisi
2016-07-25 15:41 ` Lorenzo Pieralisi [this message]
2016-07-25 15:41 ` Lorenzo Pieralisi
2016-07-25 15:51 ` Robin Murphy
2016-07-25 15:51 ` Robin Murphy
2016-07-25 16:12 ` Lorenzo Pieralisi
2016-07-25 16:12 ` Lorenzo Pieralisi
2016-08-11 11:26 ` Lorenzo Pieralisi
2016-08-11 11:26 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 07/13] drivers: acpi: iort: add node match function Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 08/13] drivers: acpi: iort: add support for ARM SMMU platform devices creation Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 10/13] drivers: iommu: arm-smmu-v3: enable ACPI driver initialization Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 11/13] drivers: iommu: arm-smmu-v3: add IORT platform device creation Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 12/13] drivers: acpi: iort: replace rid map type with type mask Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-25 5:53 ` [RFC PATCH v3 00/13] ACPI IORT ARM SMMU v3 support Dennis Chen
2016-07-25 5:53 ` Dennis Chen
2016-07-25 5:53 ` Dennis Chen
[not found] ` <20160725055330.GA21004-5wv7dgnIgG8@public.gmane.org>
2016-07-25 8:36 ` Lorenzo Pieralisi
2016-07-25 8:36 ` Lorenzo Pieralisi
2016-07-25 8:36 ` Lorenzo Pieralisi
2016-07-26 1:16 ` Dennis Chen
2016-07-26 1:16 ` Dennis Chen
2016-07-26 1:16 ` Dennis Chen
2016-07-20 11:23 ` [RFC PATCH v3 09/13] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
2016-07-20 11:23 ` [RFC PATCH v3 13/13] drivers: acpi: iort: introduce iort_iommu_configure Lorenzo Pieralisi
2016-07-20 11:23 ` Lorenzo Pieralisi
[not found] ` <1469013815-24380-14-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2016-08-03 14:19 ` nwatters-sgV2jX0FEOL9JmXXK+q4OQ
2016-08-03 14:19 ` nwatters at codeaurora.org
2016-08-03 14:19 ` nwatters
[not found] ` <016fb1080595ef61ec7a91da15ef2430-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-08-08 16:16 ` Lorenzo Pieralisi
2016-08-08 16:16 ` Lorenzo Pieralisi
2016-08-08 16:16 ` Lorenzo Pieralisi
2016-08-11 8:44 ` Lorenzo Pieralisi
2016-08-11 8:44 ` Lorenzo Pieralisi
2016-08-11 8:44 ` Lorenzo Pieralisi
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=20160725154103.GA28507@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=hanjun.guo@linaro.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jcm@redhat.com \
--cc=joro@8bytes.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=okaya@codeaurora.org \
--cc=rjw@rjwysocki.net \
--cc=robin.murphy@arm.com \
--cc=tn@semihalf.com \
--cc=will.deacon@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.