[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170329123821.GA10988@red-moon>
Date: Wed, 29 Mar 2017 13:38:21 +0100
From: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To: Hanjun Guo <hanjun.guo@...aro.org>
Cc: Hanjun Guo <guohanjun@...wei.com>,
Marc Zyngier <marc.zyngier@....com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Greg KH <gregkh@...uxfoundation.org>,
Tomasz Nowicki <tn@...ihalf.com>, Ma Jun <majun258@...wei.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>,
Sinan Kaya <okaya@...eaurora.org>, huxinwei@...wei.com,
yimin@...wei.com, linuxarm@...wei.com
Subject: Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT
On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
> >Hi Hanjun, Marc,
> >
> >On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> >>From: Hanjun Guo <hanjun.guo@...aro.org>
> >>
> >>For devices connecting to ITS, the devices need to identify themself
> >>through a dev id; this dev id is represented in the IORT table in named
> >>component node [1] for platform devices, so this patch adds code that
> >>scans the IORT table to retrieve the devices' dev id.
> >>
> >>Leveraging the iort_node_map_platform_id() IORT API, add a new function
> >>call, iort_pmsi_get_dev_id() and use it in its_pmsi_prepare() to allow
> >>retrieving dev id in ACPI platforms.
> >>
> >>[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
> >>
> >>Signed-off-by: Hanjun Guo <hanjun.guo@...aro.org>
> >>[lorenzo.pieralisi@....com: rewrote commit log]
> >>Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
> >>Tested-by: Ming Lei <ming.lei@...onical.com>
> >>Tested-by: Wei Xu <xuwei5@...ilicon.com>
> >>Tested-by: Sinan Kaya <okaya@...eaurora.org>
> >>Cc: Marc Zyngier <marc.zyngier@....com>
> >>Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
> >>Cc: Tomasz Nowicki <tn@...ihalf.com>
> >>Cc: Thomas Gleixner <tglx@...utronix.de>
> >>---
> >> drivers/acpi/arm64/iort.c | 24 ++++++++++++++++++++++++
> >> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 ++-
> >> include/linux/acpi_iort.h | 5 +++++
> >> 3 files changed, 31 insertions(+), 1 deletion(-)
> >
> >To simplify merging ACPI/IRQCHIP changes via different trees it
> >would be good to split this patch; I am not sure what's the best
> >way of handling it though given that we would end up in a merge
> >ordering dependency anyway (ie we can create an empty stub
> >for iort_pmsi_get_dev_id() but that would create a dependency
> >between ARM64 and irqchip trees anyway).
>
> The first 12 patches for ACPI platform MSI and later 3 patches
> for mbigen have no "physical" dependency, which means they can
> be merged and compiled independently, they only have functional
> dependency only.
>
> We already had SAS, XGE, USB and even UART drivers depend on
> the mbigen ACPI support, so I don't think the dependency of ACPI
> platform MSI and mbigen patches cares much if those two parts are
> merged in one merge window, even they are merged independently via
> different tree.
>
> >
> >Please let me know what's your preferred way of handling this.
>
> So in my opinion, they can be merged independently via ARM64 and
> irqchip tree with no ordering dependency, is it OK?
I am speaking about merging MBIgen AND ITS patches via IRQCHIP and
ACPI/IORT for ARM64, that's why I replied to this patch. I do not
think that's feasible to split patches in two separate branches
without having a dependency between them.
Sure, the last three patches can go via IRQCHIP but that was not
my question :)
Lorenzo
Powered by blists - more mailing lists