All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
	Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Jon Masters <jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Dennis Chen <dennis.chen-5wv7dgnIgG8@public.gmane.org>,
	Prem Mallappa
	<prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type
Date: Thu, 29 Sep 2016 22:59:40 +0200	[thread overview]
Message-ID: <3178073.UTpgCTN6if@vostro.rjw.lan> (raw)
In-Reply-To: <20160929141520.GA29244@red-moon>

On Thursday, September 29, 2016 03:15:20 PM Lorenzo Pieralisi wrote:
> Hi Rafael,
> 
> On Fri, Sep 09, 2016 at 03:23:30PM +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-5wv7dgnIgG8@public.gmane.org>
> > Reviewed-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> > Cc: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
> > ---
> >  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,
> 
> This patch provides groundwork for this series and it is key for
> the rest of it, basically the point here is that we need a fwnode
> to differentiate platform devices created out of static ACPI tables
> entries (ie IORT), that represent IOMMU components.
> 
> The corresponding device is not an ACPI device (I could fabricate one as
> it is done for other static tables entries eg FADT power button, but I
> do not necessarily see the reason for doing that given that all we need
> the fwnode for is a token identifier), so FWNODE_ACPI does not apply
> here.
> 
> Please let me know if it is reasonable how I sorted this out (it
> is basically identical to IRQCHIP, just another enum entry), the
> remainder of the code depends on this.

I'm not familiar with the use case, so I don't see anything unreasonable
in it.

If you're asking about whether or not I mind adding more fwnode types in
principle, then no, I don't. :-) 

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: iommu@lists.linux-foundation.org, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will.deacon@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Tomasz Nowicki <tn@semihalf.com>,
	Hanjun Guo <hanjun.guo@linaro.org>, Jon Masters <jcm@redhat.com>,
	Eric Auger <eric.auger@redhat.com>,
	Sinan Kaya <okaya@codeaurora.org>,
	Nate Watterson <nwatters@codeaurora.org>,
	Prem Mallappa <prem.mallappa@broadcom.com>,
	Dennis Chen <dennis.chen@arm.com>,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type
Date: Thu, 29 Sep 2016 22:59:40 +0200	[thread overview]
Message-ID: <3178073.UTpgCTN6if@vostro.rjw.lan> (raw)
In-Reply-To: <20160929141520.GA29244@red-moon>

On Thursday, September 29, 2016 03:15:20 PM Lorenzo Pieralisi wrote:
> Hi Rafael,
> 
> On Fri, Sep 09, 2016 at 03:23:30PM +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>
> > Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> > 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,
> 
> This patch provides groundwork for this series and it is key for
> the rest of it, basically the point here is that we need a fwnode
> to differentiate platform devices created out of static ACPI tables
> entries (ie IORT), that represent IOMMU components.
> 
> The corresponding device is not an ACPI device (I could fabricate one as
> it is done for other static tables entries eg FADT power button, but I
> do not necessarily see the reason for doing that given that all we need
> the fwnode for is a token identifier), so FWNODE_ACPI does not apply
> here.
> 
> Please let me know if it is reasonable how I sorted this out (it
> is basically identical to IRQCHIP, just another enum entry), the
> remainder of the code depends on this.

I'm not familiar with the use case, so I don't see anything unreasonable
in it.

If you're asking about whether or not I mind adding more fwnode types in
principle, then no, I don't. :-) 

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: rjw@rjwysocki.net (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type
Date: Thu, 29 Sep 2016 22:59:40 +0200	[thread overview]
Message-ID: <3178073.UTpgCTN6if@vostro.rjw.lan> (raw)
In-Reply-To: <20160929141520.GA29244@red-moon>

On Thursday, September 29, 2016 03:15:20 PM Lorenzo Pieralisi wrote:
> Hi Rafael,
> 
> On Fri, Sep 09, 2016 at 03:23:30PM +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>
> > Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> > 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,
> 
> This patch provides groundwork for this series and it is key for
> the rest of it, basically the point here is that we need a fwnode
> to differentiate platform devices created out of static ACPI tables
> entries (ie IORT), that represent IOMMU components.
> 
> The corresponding device is not an ACPI device (I could fabricate one as
> it is done for other static tables entries eg FADT power button, but I
> do not necessarily see the reason for doing that given that all we need
> the fwnode for is a token identifier), so FWNODE_ACPI does not apply
> here.
> 
> Please let me know if it is reasonable how I sorted this out (it
> is basically identical to IRQCHIP, just another enum entry), the
> remainder of the code depends on this.

I'm not familiar with the use case, so I don't see anything unreasonable
in it.

If you're asking about whether or not I mind adding more fwnode types in
principle, then no, I don't. :-) 

Thanks,
Rafael

  reply	other threads:[~2016-09-29 20:59 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 14:23 [PATCH v5 00/14] ACPI IORT ARM SMMU support Lorenzo Pieralisi
2016-09-09 14:23 ` Lorenzo Pieralisi
2016-09-09 14:23 ` Lorenzo Pieralisi
2016-09-09 14:23 ` [PATCH v5 13/14] drivers: acpi: iort: add single mapping function Lorenzo Pieralisi
2016-09-09 14:23   ` Lorenzo Pieralisi
     [not found] ` <20160909142343.13314-1-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2016-09-09 14:23   ` [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
     [not found]     ` <20160909142343.13314-2-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2016-09-29 14:15       ` Lorenzo Pieralisi
2016-09-29 14:15         ` Lorenzo Pieralisi
2016-09-29 14:15         ` Lorenzo Pieralisi
2016-09-29 20:59         ` Rafael J. Wysocki [this message]
2016-09-29 20:59           ` Rafael J. Wysocki
2016-09-29 20:59           ` Rafael J. Wysocki
     [not found]           ` <3178073.UTpgCTN6if-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2016-09-30  9:07             ` Lorenzo Pieralisi
2016-09-30  9:07               ` Lorenzo Pieralisi
2016-09-30  9:07               ` Lorenzo Pieralisi
2016-09-30 15:48               ` Rafael J. Wysocki
2016-09-30 15:48                 ` Rafael J. Wysocki
2016-09-30 15:48                 ` Rafael J. Wysocki
2016-09-30 15:48                 ` Rafael J. Wysocki
     [not found]                 ` <CAJZ5v0hK2Ryo32u4S9K=78-Oot13vvVNB+p6N2YC1UMqYW9g7A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-13 16:32                   ` Lorenzo Pieralisi
2016-10-13 16:32                     ` Lorenzo Pieralisi
2016-10-13 16:32                     ` Lorenzo Pieralisi
2016-10-13 16:32                     ` Lorenzo Pieralisi
2016-10-13 20:53                     ` Rafael J. Wysocki
2016-10-13 20:53                       ` Rafael J. Wysocki
2016-10-13 20:53                       ` Rafael J. Wysocki
2016-10-13 20:53                       ` Rafael J. Wysocki
2016-09-09 14:23   ` [PATCH v5 02/14] drivers: iommu: implement arch_{set/get}_iommu_fwspec API Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 03/14] drivers: acpi: iort: introduce linker section for IORT entries probing Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 04/14] drivers: acpi: iort: add support for IOMMU fwnode registration Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 05/14] drivers: iommu: make iommu_fwspec OF agnostic Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
     [not found]     ` <20160909142343.13314-6-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2016-09-13 13:38       ` Robin Murphy
2016-09-13 13:38         ` Robin Murphy
2016-09-13 13:38         ` Robin Murphy
     [not found]         ` <4e8110c4-edf3-15db-206c-b83794f138a0-5wv7dgnIgG8@public.gmane.org>
2016-09-13 13:55           ` Lorenzo Pieralisi
2016-09-13 13:55             ` Lorenzo Pieralisi
2016-09-13 13:55             ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 06/14] drivers: acpi: implement acpi_dma_configure Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-13 14:41     ` Robin Murphy
2016-09-13 14:41       ` Robin Murphy
2016-09-13 16:00       ` Lorenzo Pieralisi
2016-09-13 16:00         ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 07/14] drivers: acpi: iort: add support for ARM SMMU platform devices creation Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-13  7:46     ` nwatters
2016-09-13  7:46       ` nwatters at codeaurora.org
2016-09-13  8:15       ` Hanjun Guo
2016-09-13  8:15         ` Hanjun Guo
     [not found]         ` <fb4acfd5-b7fd-636f-53f3-13dc6fb8b713-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-09-13  8:24           ` Lorenzo Pieralisi
2016-09-13  8:24             ` Lorenzo Pieralisi
2016-09-13  8:24             ` Lorenzo Pieralisi
2016-09-13  8:48             ` Hanjun Guo
2016-09-13  8:48               ` Hanjun Guo
2016-09-13  8:48               ` Hanjun Guo
2016-09-13 15:25     ` Robin Murphy
2016-09-13 15:25       ` Robin Murphy
2016-09-13 16:29       ` Lorenzo Pieralisi
2016-09-13 16:29         ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 08/14] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 09/14] drivers: iommu: arm-smmu-v3: add IORT configuration Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-13 17:30     ` Robin Murphy
2016-09-13 17:30       ` Robin Murphy
2016-09-09 14:23   ` [PATCH v5 10/14] drivers: iommu: arm-smmu: split probe functions into DT/generic portions Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 11/14] drivers: iommu: arm-smmu: add IORT configuration Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23   ` [PATCH v5 12/14] drivers: acpi: iort: replace rid map type with type mask Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
     [not found]     ` <20160909142343.13314-13-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2016-09-13  8:26       ` Hanjun Guo
2016-09-13  8:26         ` Hanjun Guo
2016-09-13  8:26         ` Hanjun Guo
2016-09-09 14:23   ` [PATCH v5 14/14] drivers: acpi: iort: introduce iort_iommu_configure Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
2016-09-09 14:23     ` Lorenzo Pieralisi
     [not found]     ` <20160909142343.13314-15-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2016-09-13  8:14       ` Nate Watterson
2016-09-13  8:14         ` Nate Watterson
2016-09-13  8:14         ` Nate Watterson
2016-09-13  8:18         ` Hanjun Guo
2016-09-13  8:18           ` 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=3178073.UTpgCTN6if@vostro.rjw.lan \
    --to=rjw-lthd3rsa81gm4rdzfppkha@public.gmane.org \
    --cc=dennis.chen-5wv7dgnIgG8@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
    --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=prem.mallappa-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
    --cc=tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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 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.