mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hiroshi Doyu <hdoyu@nvidia.com>
To: "joro@8bytes.org" <joro@8bytes.org>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	Stephen Warren <swarren@nvidia.com>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"robherring2@gmail.com" <robherring2@gmail.com>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv6 05/13] iommu/core: add ops->{bound,unbind}_driver()
Date: Wed, 4 Dec 2013 09:40:27 +0200	[thread overview]
Message-ID: <20131204094027.dad1288aec14551ec42f3743@nvidia.com> (raw)
In-Reply-To: <20131125154937.d6dbe9aedc16aab335d92f99@nvidia.com>

On Mon, 25 Nov 2013 14:49:37 +0100
Hiroshi Doyu <hdoyu@nvidia.com> wrote:

> Hi Joerg,
> 
> Do you have some time to review this patch along with the following ones?
> 
>   [PATCHv6 02/13] iommu/of: introduce a global iommu device list
>   http://lists.linuxfoundation.org/pipermail/iommu/2013-November/007050.html
> 
>   [PATCHv6 03/13] iommu/of: check if dependee iommu is ready or not
>   http://lists.linuxfoundation.org/pipermail/iommu/2013-November/007051.html

Any chance to get some feedback on them?

> With those patches, now I'm trying to populate iommu master devices
> after an IOMMU device is populated. Originally [PATCHv6 02/13] was
> proposed by Thierry. I'm a bit afraid of adding new IOMMU API as
> this, but I think that this new {bound,unbind}_driver() is the right
> timiing that depeding devices are populated instead of add_device()
> since, even after add_device, a device won't be populated. I'm not so
> sure how this affects on the existing IOMMUs.
> 
> It would be nice if you give some feedback on this.
> 
> On Thu, 21 Nov 2013 14:40:41 +0100
> Hiroshi Doyu <hdoyu@nvidia.com> wrote:
> 
> > ops->{bound,unbind}_driver() functions are called at
> > BUS_NOTIFY_{BOUND,UNBIND}_DRIVER respectively.
> > 
> > This is necessary to control the device population order. IOMMU master
> > devices depend on an IOMMU device instanciation. IOMMU master devices
> > can be registered to an IOMMU only after it's successfully
> > populated. This IOMMU registration is done via
> > ops->bound_driver(). Currently this population can be deferred if
> > depending IOMMU device hasn't yet been populated in driver core. This
> > cannot be done via ops->add_device() since after add_device() device's
> > population/instanciation can be still deferred via probe().
> > 
> > Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
> > ---
> > v6:
> > New for v6.
> > ---
> >  drivers/iommu/iommu.c | 13 +++++++++++--
> >  include/linux/iommu.h |  4 ++++
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index e5555fc..5469d36 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -540,14 +540,23 @@ static int iommu_bus_notifier(struct notifier_block *nb,
> >  	 * ADD/DEL call into iommu driver ops if provided, which may
> >  	 * result in ADD/DEL notifiers to group->notifier
> >  	 */
> > -	if (action == BUS_NOTIFY_ADD_DEVICE) {
> > +	switch (action) {
> > +	case BUS_NOTIFY_ADD_DEVICE:
> >  		if (ops->add_device)
> >  			return ops->add_device(dev);
> > -	} else if (action == BUS_NOTIFY_DEL_DEVICE) {
> > +	case BUS_NOTIFY_DEL_DEVICE:
> >  		if (ops->remove_device && dev->iommu_group) {
> >  			ops->remove_device(dev);
> >  			return 0;
> >  		}
> > +	case BUS_NOTIFY_BOUND_DRIVER:
> > +		if (ops->bound_driver)
> > +			ops->bound_driver(dev);
> > +		break;
> > +	case BUS_NOTIFY_UNBIND_DRIVER:
> > +		if (ops->unbind_driver)
> > +			ops->unbind_driver(dev);
> > +		break;
> >  	}
> >  
> >  	/*
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index a444c79..a0e92be 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -96,6 +96,8 @@ enum iommu_attr {
> >   * @domain_has_cap: domain capabilities query
> >   * @add_device: add device to iommu grouping
> >   * @remove_device: remove device from iommu grouping
> > + * @bound_driver: called at BUS_NOTIFY_BOUND_DRIVER
> > + * @unbind_driver: called at BUS_NOTIFY_UNBIND_DRIVER
> >   * @domain_get_attr: Query domain attributes
> >   * @domain_set_attr: Change domain attributes
> >   * @pgsize_bitmap: bitmap of supported page sizes
> > @@ -114,6 +116,8 @@ struct iommu_ops {
> >  			      unsigned long cap);
> >  	int (*add_device)(struct device *dev);
> >  	void (*remove_device)(struct device *dev);
> > +	int (*bound_driver)(struct device *dev);
> > +	void (*unbind_driver)(struct device *dev);
> >  	int (*device_group)(struct device *dev, unsigned int *groupid);
> >  	int (*domain_get_attr)(struct iommu_domain *domain,
> >  			       enum iommu_attr attr, void *data);
> > -- 
> > 1.8.1.5
> > 
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2013-12-04  7:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-21 13:40 [PATCHv6 00/13] Unifying SMMU driver among Tegra SoCs Hiroshi Doyu
     [not found] ` < 1385041249-7705-2-git-send-email-hdoyu@nvidia.com>
2013-11-21 13:40 ` [PATCHv6 01/13] of: introduce of_property_for_earch_phandle_with_args() Hiroshi Doyu
2013-11-21 17:17   ` [PATCHv6+ " Hiroshi Doyu
2013-11-21 18:57     ` Stephen Warren
2013-11-28 12:58       ` [RFC][PATCHv6++ " Hiroshi Doyu
2013-11-29 11:46         ` [RFC][PATCHv6+++ " Hiroshi Doyu
2013-12-01 19:00           ` Stephen Warren
2013-12-02 11:02             ` Hiroshi Doyu
2013-12-02 14:39               ` Rob Herring
2013-12-03  6:46                 ` Hiroshi Doyu
2013-12-03 20:14               ` Stephen Warren
2013-12-11 13:28       ` [PATCHv6+ " Grant Likely
2013-12-11 13:33         ` Hiroshi Doyu
2013-12-12 11:34           ` Grant Likely
2013-12-12 12:14             ` Hiroshi Doyu
2013-12-14 15:51               ` Hiroshi Doyu
2013-12-16 17:14                 ` Stephen Warren
2013-12-11 13:27     ` Grant Likely
2013-11-21 13:40 ` [PATCHv6 02/13] iommu/of: introduce a global iommu device list Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 03/13] iommu/of: check if dependee iommu is ready or not Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 04/13] driver/core: populate devices in order for IOMMUs Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 05/13] iommu/core: add ops->{bound,unbind}_driver() Hiroshi Doyu
2013-11-25 13:49   ` Hiroshi Doyu
2013-12-04  7:40     ` Hiroshi Doyu [this message]
2013-12-04 10:01       ` Will Deacon
2013-11-21 13:40 ` [PATCHv6 06/13] ARM: tegra: create a DT header defining SWGROUP ID Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 07/13] iommu/tegra: smmu: register device to iommu dynamically Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 08/13] iommu/tegra: smmu: calculate ASID register offset by ID Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 09/13] iommu/tegra: smmu: get swgroups from DT "iommus=" Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 10/13] iommu/tegra: smmu: allow duplicate ASID wirte Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 11/13] iommu/tegra: smmu: Rename hwgrp -> swgroups Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 12/13] iommu/tegra: smmu: add SMMU to an global iommu list Hiroshi Doyu
2013-11-21 13:40 ` [PATCHv6 13/13] [FOR TEST] ARM: dt: tegra30: add "iommus" binding Hiroshi Doyu

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=20131204094027.dad1288aec14551ec42f3743@nvidia.com \
    --to=hdoyu@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=robherring2@gmail.com \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.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

Powered by JetHome