lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58DBA010.1020002@linaro.org>
Date:   Wed, 29 Mar 2017 19:52:48 +0800
From:   Hanjun Guo <hanjun.guo@...aro.org>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Hanjun Guo <guohanjun@...wei.com>,
        Marc Zyngier <marc.zyngier@....com>
CC:     "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

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?

Thanks
Hanjun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ