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
| ||
|
Date: Wed, 29 Mar 2017 15:52:47 +0100 From: Marc Zyngier <marc.zyngier@....com> To: Hanjun Guo <hanjun.guo@...aro.org>, Lorenzo Pieralisi <lorenzo.pieralisi@....com> Cc: 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 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? M. -- Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists