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
next prev parent reply other threads:[~2016-09-29 20:53 UTC|newest]
Thread overview: 35+ 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 ` [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type Lorenzo Pieralisi
2016-09-29 14:15 ` Lorenzo Pieralisi
2016-09-29 20:59 ` Rafael J. Wysocki [this message]
2016-09-30 9:07 ` Lorenzo Pieralisi
2016-09-30 15:48 ` Rafael J. Wysocki
2016-10-13 16:32 ` Lorenzo Pieralisi
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 ` [PATCH v5 03/14] drivers: acpi: iort: introduce linker section for IORT entries probing 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 ` [PATCH v5 05/14] drivers: iommu: make iommu_fwspec OF agnostic Lorenzo Pieralisi
2016-09-13 13:38 ` Robin Murphy
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-13 14:41 ` Robin Murphy
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-13 7:46 ` nwatters
2016-09-13 8:15 ` Hanjun Guo
2016-09-13 8:24 ` Lorenzo Pieralisi
2016-09-13 8:48 ` Hanjun Guo
2016-09-13 15:25 ` Robin Murphy
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 ` [PATCH v5 09/14] drivers: iommu: arm-smmu-v3: add IORT configuration Lorenzo Pieralisi
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 ` [PATCH v5 11/14] drivers: iommu: arm-smmu: add IORT configuration 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-13 8:26 ` Hanjun Guo
2016-09-09 14:23 ` [PATCH v5 13/14] drivers: acpi: iort: add single mapping function Lorenzo Pieralisi
2016-09-09 14:23 ` [PATCH v5 14/14] drivers: acpi: iort: introduce iort_iommu_configure Lorenzo Pieralisi
2016-09-13 8:14 ` Nate Watterson
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@rjwysocki.net \
--cc=dennis.chen@arm.com \
--cc=eric.auger@redhat.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=lorenzo.pieralisi@arm.com \
--cc=marc.zyngier@arm.com \
--cc=nwatters@codeaurora.org \
--cc=okaya@codeaurora.org \
--cc=prem.mallappa@broadcom.com \
--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
all inboxes | Powered by JetHome®