linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 17:12:23 +0100	[thread overview]
Message-ID: <20160725161223.GA28870@red-moon> (raw)
In-Reply-To: <856415fc-b9bf-ca44-cc70-85d454574e53@arm.com>

On Mon, Jul 25, 2016 at 04:51:00PM +0100, Robin Murphy wrote:
> On 25/07/16 16:41, Lorenzo Pieralisi wrote:
> [...]
> >>> 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).
> 
> OK, given Rob's comment as well, I guess breaking that dependency is to
> everyone's benefit. Since it's quite closely related, how about if we
> follow the arch_setup_dma_ops() pattern with an
> arch_{get,set}_iommu_fwspec(dev) type thing?

Yes we can do that too as an intermediate step, that solves the
problem (and it makes this patch much simpler), it is cleaner
than doing it with a(nother) Kconfig entry.

Thanks,
Lorenzo

> Robin.
> 
> > 
> > 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;
> >>>  
> >>>
> >>
> > 
> 

  reply	other threads:[~2016-07-25 16:12 UTC|newest]

Thread overview: 27+ 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 ` [RFC PATCH v3 01/13] drivers: iommu: add FWNODE_IOMMU fwnode type 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 ` [RFC PATCH v3 03/13] drivers: acpi: iort: add support for IOMMU fwnode registration 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 ` [RFC PATCH v3 05/13] drivers: iommu: make iommu_fwspec OF agnostic Lorenzo Pieralisi
2016-07-25 15:09   ` Robin Murphy
2016-07-25 15:21     ` Rob Herring
2016-07-25 15:56       ` Lorenzo Pieralisi
2016-07-25 15:41     ` Lorenzo Pieralisi
2016-07-25 15:51       ` Robin Murphy
2016-07-25 16:12         ` Lorenzo Pieralisi [this message]
2016-08-11 11:26         ` 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 ` [RFC PATCH v3 07/13] drivers: acpi: iort: add node match function 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 ` [RFC PATCH v3 09/13] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions 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 ` [RFC PATCH v3 11/13] drivers: iommu: arm-smmu-v3: add IORT platform device creation 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 ` [RFC PATCH v3 13/13] drivers: acpi: iort: introduce iort_iommu_configure Lorenzo Pieralisi
2016-08-03 14:19   ` nwatters
2016-08-08 16:16     ` Lorenzo Pieralisi
2016-08-11  8:44     ` Lorenzo Pieralisi
2016-07-25  5:53 ` [RFC PATCH v3 00/13] ACPI IORT ARM SMMU v3 support Dennis Chen
2016-07-25  8:36   ` Lorenzo Pieralisi
2016-07-26  1:16     ` Dennis Chen

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=20160725161223.GA28870@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 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).