Message-ID: <20170329173243.GA6091@red-moon>
Date:   Wed, 29 Mar 2017 18:32:43 +0100
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     Hanjun Guo <hanjun.guo@...aro.org>,
        Hanjun Guo <guohanjun@...wei.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 05:13:54PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
> > On 29/03/17 14:00, Hanjun Guo wrote:
> > > On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
> > >> 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 :)
> > > 
> > > Sorry, I misunderstood that :(
> > > 
> > > Since it's not feasible to split patches, the best way I got is that
> > > we get Marc's ack then merge it.
> > 
> > I believe there is a way to make this work without too much hassle. I
> > suggest we drop the ITS change from this patch entirely, and I instead
> > queue this patch:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
> > 
> > That way, no dependency between the two trees. Lorenzo takes all the
> > patches flagged "ACPI", I take all those flagged "irqchip" or "msi", and
> > everything should be perfectly standalone.
> > 
> > Thoughts?
> 
> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
> this patch and post the resulting branch for everyone to have a final
> test.

git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/arm64-acpi-4.12

Please have a look and let me know if that's ok, I planned to send
a PR to Catalin by the end of the week (first 7 patches up to
7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
device")).

Lorenzo

Powered by blists - more mailing lists