Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756110AbdC2NAY (ORCPT ); Wed, 29 Mar 2017 09:00:24 -0400 Received: from mail-pg0-f43.google.com ([74.125.83.43]:33088 "EHLO mail-pg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756067AbdC2NAV (ORCPT ); Wed, 29 Mar 2017 09:00:21 -0400 Message-ID: <58DBAFD6.7070300@linaro.org> Date: Wed, 29 Mar 2017 21:00:06 +0800 From: Hanjun Guo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lorenzo Pieralisi CC: Hanjun Guo , Marc Zyngier , "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Greg KH , Tomasz Nowicki , Ma Jun , Kefeng Wang , Sinan Kaya , huxinwei@huawei.com, yimin@huawei.com, linuxarm@huawei.com Subject: Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT References: <1488890410-15503-1-git-send-email-guohanjun@huawei.com> <1488890410-15503-11-git-send-email-guohanjun@huawei.com> <20170329101400.GA10807@red-moon> <58DBA010.1020002@linaro.org> <20170329123821.GA10988@red-moon> In-Reply-To: <20170329123821.GA10988@red-moon> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3289 Lines: 78 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 >>>> >>>> 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 >>>> [lorenzo.pieralisi@arm.com: rewrote commit log] >>>> Signed-off-by: Lorenzo Pieralisi >>>> Tested-by: Ming Lei >>>> Tested-by: Wei Xu >>>> Tested-by: Sinan Kaya >>>> Cc: Marc Zyngier >>>> Cc: Lorenzo Pieralisi >>>> Cc: Tomasz Nowicki >>>> Cc: Thomas Gleixner >>>> --- >>>> 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. Marc, Lorenzo, is this OK? Thanks Hanjun