[{"id":1764682,"web_url":"http://patchwork.ozlabs.org/comment/1764682/","msgid":"<92500143-814b-b255-bb7b-c36d5eca5457@arm.com>","list_archive_url":null,"date":"2017-09-07T12:04:41","subject":"Re: [PATCH v4 3/6] irqdomain: move IRQ_DOMAIN_NAME_ALLOCATED define\n\tto the original position","submitter":{"id":7353,"url":"http://patchwork.ozlabs.org/api/people/7353/","name":"Marc Zyngier","email":"marc.zyngier@arm.com"},"content":"On 07/09/17 12:41, Masahiro Yamada wrote:\n> Commit 6a6544e520ab (\"genirq/irqdomain: Remove auto-recursive hierarchy\n> support\") not only deleted IRQ_DOMAIN_FLAG_AUTO_RECURSIVE, but also\n> moved IRQ_DOMAIN_NAME_ALLOCATED up.\n> \n> Get it back to the original position to sort the enum by the bit shift.\n> \n> Signed-off-by: Masahiro Yamada \n> ---\n> \n> Changes in v4:\n> - Newly added\n> \n> \n> include/linux/irqdomain.h | 6 +++---\n> 1 file changed, 3 insertions(+), 3 deletions(-)\n> \n> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h\n> index 81e4889..31be32d 100644\n> --- a/include/linux/irqdomain.h\n> +++ b/include/linux/irqdomain.h\n> @@ -180,9 +180,6 @@ enum {\n> \t/* Irq domain is hierarchical */\n> \tIRQ_DOMAIN_FLAG_HIERARCHY\t= (1 << 0),\n> \n> -\t/* Irq domain name was allocated in __irq_domain_add() */\n> -\tIRQ_DOMAIN_NAME_ALLOCATED\t= (1 << 6),\n> -\n> \t/* Irq domain is an IPI domain with virq per cpu */\n> \tIRQ_DOMAIN_FLAG_IPI_PER_CPU\t= (1 << 2),\n> \n> @@ -195,6 +192,9 @@ enum {\n> \t/* Irq domain implements MSI remapping */\n> \tIRQ_DOMAIN_FLAG_MSI_REMAP\t= (1 << 5),\n> \n> +\t/* Irq domain name was allocated in __irq_domain_add() */\n> +\tIRQ_DOMAIN_NAME_ALLOCATED\t= (1 << 6),\n> +\n\nThe right fix would be to leave it where it is, but to actually fix the\nshift, which is what I should have done the first place.\n\n\tM.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnzfP5NKLz9sRV\n\tfor ;\n\tThu, 7 Sep 2017 22:05:01 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755273AbdIGMEr (ORCPT\n\t);\n\tThu, 7 Sep 2017 08:04:47 -0400","from foss.arm.com ([217.140.101.70]:59148 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755153AbdIGMEp (ORCPT );\n\tThu, 7 Sep 2017 08:04:45 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C53881529;\n\tThu, 7 Sep 2017 05:04:44 -0700 (PDT)","from [10.1.206.41] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tEA1E73F578; Thu, 7 Sep 2017 05:04:42 -0700 (PDT)"],"Subject":"Re: [PATCH v4 3/6] irqdomain: move IRQ_DOMAIN_NAME_ALLOCATED define\n\tto the original position","To":"Masahiro Yamada ,\n\tThomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ","Cc":"Jassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney , linux-kernel@vger.kernel.org","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1504784522-26841-4-git-send-email-yamada.masahiro@socionext.com>","From":"Marc Zyngier ","Organization":"ARM Ltd","Message-ID":"<92500143-814b-b255-bb7b-c36d5eca5457@arm.com>","Date":"Thu, 7 Sep 2017 13:04:41 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504784522-26841-4-git-send-email-yamada.masahiro@socionext.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764690,"web_url":"http://patchwork.ozlabs.org/comment/1764690/","msgid":"","list_archive_url":null,"date":"2017-09-07T12:25:03","subject":"Re: [PATCH v4 2/6] irqdomain: clear trigger type in\n\tirq_domain_push_irq()","submitter":{"id":7353,"url":"http://patchwork.ozlabs.org/api/people/7353/","name":"Marc Zyngier","email":"marc.zyngier@arm.com"},"content":"On 07/09/17 12:41, Masahiro Yamada wrote:\n> Prior to the addition of irq_domain_push_irq(), the hierarchy\n> IRQ domain always allocates IRQs from the outer-most domain.\n> Each irqchip usually calls irq_domain_alloc_irqs_parent(),\n> ascending the topology up to the root irqchip.\n> \n> The brand-new function irq_domain_push_irq() allows us to allocate\n> IRQs for parent domain first, then add a child irq_data to the\n> tail of the chain.\n> \n> For the new use-case, if the parent sets a temporary trigger type,\n> it may differ from the type requested to the outer-most irqchip,\n> then irq_create_fwspec_mapping() warns \"type mismatch, failed to map...\"\n> \n> Clear the trigger type when a new irq_data is connected to the chain.\n> \n> Signed-off-by: Masahiro Yamada \n> ---\n> \n> Changes in v4:\n> - Newly added\n> \n> \n> kernel/irq/irqdomain.c | 3 +++\n> 1 file changed, 3 insertions(+)\n> \n> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c\n> index da3e0b6..18d11b9 100644\n> --- a/kernel/irq/irqdomain.c\n> +++ b/kernel/irq/irqdomain.c\n> @@ -1532,6 +1532,9 @@ int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg)\n> \ttail_irq_data->chip = NULL;\n> \ttail_irq_data->chip_data = NULL;\n> \n> +\t/* clear the trigger type to avoid \"type mismatch\" error */\n> +\tirqd_set_trigger_type(tail_irq_data, IRQ_TYPE_NONE);\n> +\n\nThis feels wrong. The initial interrupt hierarchy does have a set\ntrigger, because it has been configured already, and switching it to\nNONE is hiding the fact that you're setting it to another, conflicting\nvalue.\n\nYour new fwspec should have a type that is really compatible with with\nthe underlying interrupt, however \"temporary\". If it is not, you have a\nproblem.\n\nThanks,\n\n\tM.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xp05t693yz9s7C\n\tfor ;\n\tThu, 7 Sep 2017 22:25:22 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932152AbdIGMZI (ORCPT );\n\tThu, 7 Sep 2017 08:25:08 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59238 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932139AbdIGMZH (ORCPT );\n\tThu, 7 Sep 2017 08:25:07 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4C2D113D5;\n\tThu, 7 Sep 2017 05:25:07 -0700 (PDT)","from [10.1.206.41] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t6D9873F578; Thu, 7 Sep 2017 05:25:05 -0700 (PDT)"],"Subject":"Re: [PATCH v4 2/6] irqdomain: clear trigger type in\n\tirq_domain_push_irq()","To":"Masahiro Yamada ,\n\tThomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ","Cc":"Jassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney , linux-kernel@vger.kernel.org","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1504784522-26841-3-git-send-email-yamada.masahiro@socionext.com>","From":"Marc Zyngier ","Organization":"ARM Ltd","Message-ID":"","Date":"Thu, 7 Sep 2017 13:25:03 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504784522-26841-3-git-send-email-yamada.masahiro@socionext.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764695,"web_url":"http://patchwork.ozlabs.org/comment/1764695/","msgid":"","list_archive_url":null,"date":"2017-09-07T12:39:11","subject":"Re: [PATCH v4 0/6] irqdomain, gpio: expand irq_domain_push_irq() for\n\tDT use and use it for GPIO","submitter":{"id":7353,"url":"http://patchwork.ozlabs.org/api/people/7353/","name":"Marc Zyngier","email":"marc.zyngier@arm.com"},"content":"On 07/09/17 12:41, Masahiro Yamada wrote:\n> \n> This series adds a GPIO controller for UniPhier SoC family.\n> It also works as an irqchip in hierarchy domain manner.\n> \n> My problem is mapping of IRQ from this controller to the parent\n> irqchip is not contiguous.\n> \n> IRQ line of GPIO ---> Parent interrupt\n> 0 ---> 48\n> 1 ---> 49\n> ...\n> 15 ---> 63\n> 16 ---> 154\n> 17 ---> 155\n> ...\n> 20 ---> 158\n> 21 ---> 217\n> 22 ---> 218\n> ...\n> \n> So, I need to have an array of parent hwirqs somehow.\n> \n> Probably, most of people will try to use \"interrupts\" DT property,\n> but I noticed a potential problem for hierarchy IRQ domain.\n> If \"interrupts\" property exists in the device node, IRQ resource\n> may be statically allocated when platform devices are populated\n> from DT. I asked this question some time ago:\n> https://lkml.org/lkml/2017/7/6/758\n> \n> After I tackled this, I decided to put the array in the driver,\n> but I could not get a positive response for this.\n> The discussion mostly happened in v1 thread:\n> http://patchwork.ozlabs.org/patch/797145/\n> \n> Recently, the new API irq_domain_push_irq() was merged in the\n> mainline. I thought this might be useful to solve the hierarchy\n> domain issue. Hence, here is a trial.\n> \n> I found patch 2 is needed to avoid \"type mismatch\" error.\n> \n> One more thing, I am worried about a race condition.\n> \n> I think there is a possibility where a device tries to get IRQ\n> after irq_domain_create_hierarchy(), but before irq_domain_push_irq().\n> \n> \tpriv->domain = irq_domain_create_hierarchy(...)\n> \tif (!priv->domain)\n> \t\treturn -ENOMEM;\n> \n> [ *** What if a irq consumer device request the irq here? *** ]\n\nWe've explicitly forbidden such a use case. There is a (not exactly fool\nproof) check in irq_domain_push_irq(), but it is pretty easy to bypass\nit. \"Don't do it\" is the conclusion we reached with David Daney.\n\nIf you don't want these interrupts to be requested, you might as well\nflag them as IRQ_NOREQUEST, and unflag them when the hierarchy is ready.\n\nWould that work for you?\n\nThanks,\n\n\tM.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xp0Q04n2lz9s9Y\n\tfor ;\n\tThu, 7 Sep 2017 22:39:20 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755353AbdIGMjS (ORCPT\n\t);\n\tThu, 7 Sep 2017 08:39:18 -0400","from foss.arm.com ([217.140.101.70]:59310 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755286AbdIGMjP (ORCPT );\n\tThu, 7 Sep 2017 08:39:15 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5D01713D5;\n\tThu, 7 Sep 2017 05:39:15 -0700 (PDT)","from [10.1.206.41] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t332743F578; Thu, 7 Sep 2017 05:39:13 -0700 (PDT)"],"Subject":"Re: [PATCH v4 0/6] irqdomain, gpio: expand irq_domain_push_irq() for\n\tDT use and use it for GPIO","To":"Masahiro Yamada ,\n\tThomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ","Cc":"Jassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney ,\n\tlinux-kernel@vger.kernel.org, Mark Rutland ,\n\tlinux-arm-kernel@lists.infradead.org","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>","From":"Marc Zyngier ","Organization":"ARM Ltd","Message-ID":"","Date":"Thu, 7 Sep 2017 13:39:11 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764705,"web_url":"http://patchwork.ozlabs.org/comment/1764705/","msgid":"","list_archive_url":null,"date":"2017-09-07T12:47:16","subject":"Re: [PATCH v4 1/6] irqdomain: rename variables in\n\tirq_domain_{push,pop}_irq()","submitter":{"id":7353,"url":"http://patchwork.ozlabs.org/api/people/7353/","name":"Marc Zyngier","email":"marc.zyngier@arm.com"},"content":"On 07/09/17 12:41, Masahiro Yamada wrote:\n> The meaning of \"root\" in irq_domain_{push,pop} is opposite to the\n> documentation. Documentation/IRQ-domain.txt depicts the hierarchy\n> IRQ domain as follows:\n> \n> CPU Vector irq_domain (root irq_domain to manage CPU vectors)\n> ^\n> |\n> Interrupt Remapping irq_domain (manage irq_remapping entries)\n> ^\n> |\n> IOAPIC irq_domain (manage IOAPIC delivery entries/pins)\n> \n> From above, the inner-most domain (nearest to the CPU) is \"root\".\n> \n> The document also says, \"When building irq_domain hierarchy, the\n> irq_domain near to the device is child and the irq_domain near to\n> CPU is parent.\" This is how irq_data->parent_data works. In\n> contrast, these function use a variable \"child_irq_data\" for that.\nThe exact opposite argument could be used for the data structure. The\nirq_desc is the root of the list ordered with parent_data.\n\nYes, this is confusing, but because we're using the same English words\nto describe two different things, we're bound to make one thing more\ndifficult. I'm unconvinced that this change helps anything (it certainly\nconfuses me more than anything else).\n\nThanks,\n\n\tM.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xp0bG4KNlz9t2W\n\tfor ;\n\tThu, 7 Sep 2017 22:47:22 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755290AbdIGMrU (ORCPT\n\t);\n\tThu, 7 Sep 2017 08:47:20 -0400","from foss.arm.com ([217.140.101.70]:59378 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755282AbdIGMrT (ORCPT );\n\tThu, 7 Sep 2017 08:47:19 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3441A13D5;\n\tThu, 7 Sep 2017 05:47:19 -0700 (PDT)","from [10.1.206.41] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t5C3233F578; Thu, 7 Sep 2017 05:47:17 -0700 (PDT)"],"Subject":"Re: [PATCH v4 1/6] irqdomain: rename variables in\n\tirq_domain_{push,pop}_irq()","To":"Masahiro Yamada ,\n\tThomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ","Cc":"Jassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney , linux-kernel@vger.kernel.org","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1504784522-26841-2-git-send-email-yamada.masahiro@socionext.com>","From":"Marc Zyngier ","Organization":"ARM Ltd","Message-ID":"","Date":"Thu, 7 Sep 2017 13:47:16 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504784522-26841-2-git-send-email-yamada.masahiro@socionext.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764857,"web_url":"http://patchwork.ozlabs.org/comment/1764857/","msgid":"","list_archive_url":null,"date":"2017-09-07T17:45:34","subject":"Re: [PATCH v4 1/6] irqdomain: rename variables in\n\tirq_domain_{push,pop}_irq()","submitter":{"id":721,"url":"http://patchwork.ozlabs.org/api/people/721/","name":"David Daney","email":"ddaney@caviumnetworks.com"},"content":"On 09/07/2017 05:47 AM, Marc Zyngier wrote:\n> On 07/09/17 12:41, Masahiro Yamada wrote:\n>> The meaning of \"root\" in irq_domain_{push,pop} is opposite to the\n>> documentation. Documentation/IRQ-domain.txt depicts the hierarchy\n>> IRQ domain as follows:\n>>\n>> CPU Vector irq_domain (root irq_domain to manage CPU vectors)\n>> ^\n>> |\n>> Interrupt Remapping irq_domain (manage irq_remapping entries)\n>> ^\n>> |\n>> IOAPIC irq_domain (manage IOAPIC delivery entries/pins)\n>>\n>> From above, the inner-most domain (nearest to the CPU) is \"root\".\n>>\n>> The document also says, \"When building irq_domain hierarchy, the\n>> irq_domain near to the device is child and the irq_domain near to\n>> CPU is parent.\" This is how irq_data->parent_data works. In\n>> contrast, these function use a variable \"child_irq_data\" for that.\n> The exact opposite argument could be used for the data structure. The\n> irq_desc is the root of the list ordered with parent_data.\n> \n> Yes, this is confusing, but because we're using the same English words\n> to describe two different things, we're bound to make one thing more\n> difficult. I'm unconvinced that this change helps anything (it certainly\n> confuses me more than anything else).\n> \n\nThere may be room for improvement here.\n\nHere is my recollection of how I choose the names:\n\n\"root\" is the thing embedded in the struct irq_desc, if you think about \na typical linked list structure like this, we can refer to the starting \npoint as the \"root\". Sometimes it might be referred to as the \"head\" of \nthe list, but usually not the \"tail\"\n\n\"child\" was used to indicate the thing we get to by traversing the link \nin the list. The fact that ->parent is the name of the next pointer and \nthat it points to something called \"child\" is confusing here.\n\nSo what do I think should be done? This:\n\nEither\n A) s/child_irq_data/parent_irq_data/g As this patch does, but leave \nthe root_irq_data name unchanged.\n\n B) Change the name of the ->parent in struct irq_data to ->next\n\nBut that is just my $0.02\n\nI fear we risk a Bike Shedding type of discussion here.\n\n\nDavid Daney\n\n> Thanks,\n> \n> \tM.\n> \n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"OZwk4XAo\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=David.Daney@cavium.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xp7CX4wD3z9t2R\n\tfor ;\n\tFri, 8 Sep 2017 03:45:44 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754592AbdIGRpm (ORCPT\n\t);\n\tThu, 7 Sep 2017 13:45:42 -0400","from mail-by2nam03on0070.outbound.protection.outlook.com\n\t([104.47.42.70]:28406\n\t\"EHLO NAM03-BY2-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S1754518AbdIGRpk (ORCPT );\n\tThu, 7 Sep 2017 13:45:40 -0400","from ddl.caveonetworks.com (50.233.148.156) by\n\tDM5PR07MB3497.namprd07.prod.outlook.com (10.164.153.28) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.13.10; Thu, 7 Sep 2017 17:45:36 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=trnVrxhylgPaVGwjeUKQP4juzn6eHDHN+ReysVHACNA=;\n\tb=OZwk4XAosHu/5QRHjlOpHguPtR1ef5Zr6guUtCyKO4r6XfCktjUKkp5UxJdYaSoSrvmZq1KtFZm6aq3dSMdyGOMosB/032YabLQyDYv7fVjFlR8z0QpypmM2SXqgvnO3ciq5T2b0OQ7Mvok4LxhtXW/VWVlG2V/71FpS8fJ8jyA=","Subject":"Re: [PATCH v4 1/6] irqdomain: rename variables in\n\tirq_domain_{push,pop}_irq()","To":"Marc Zyngier ,\n\tMasahiro Yamada ,\n\tThomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ","Cc":"Jassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney , linux-kernel@vger.kernel.org","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1504784522-26841-2-git-send-email-yamada.masahiro@socionext.com>\n\t","From":"David Daney ","Message-ID":"","Date":"Thu, 7 Sep 2017 10:45:34 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[50.233.148.156]","X-ClientProxiedBy":"DM5PR07CA0044.namprd07.prod.outlook.com (10.168.109.30) To\n\tDM5PR07MB3497.namprd07.prod.outlook.com (10.164.153.28)","X-MS-PublicTrafficType":"Email","X-MS-Office365-Filtering-Correlation-Id":"8d81b2a2-f32a-4096-29ca-08d4f6183fcd","X-Microsoft-Antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:DM5PR07MB3497; ","X-Microsoft-Exchange-Diagnostics":["1; DM5PR07MB3497;\n\t3:qVo1ANjfcv4IfJ9g7lqhM4dfTl9vvvOQ4OtHOjVeUws1NREDV96WvrJnjdmKrT4gr1OmcTupYCWH/zsWSNpyK31Ou3jKxG0Hs2kj0oWCEfj1wPYhDMJd86WrVrRTLm1EBoCK328134h/S9471T6PQS8wz0lf6EJNUqcuaxWKLqNPnQFaw6wTIew5VGhycQjPL+JTXOwKkJmaqmCfd6VEz0bvIvi0ns/6OeqIwF4YtZQ+rwTmIOqLncPE9sL7eziK;\n\t25:RvD+LbWV2mQlmAZGg628nhbT2kGjkP0pIUWP/+6o8zkykZu3hHOKcS+OAe+Ax+tWH731u9DpBckrUXuoIeJ1Ys2Z+XH2Z6xgfPhm3CsQGfU2VPg5uD9JAHhny+4ZQda0IPWJCWuNo6B2Xnlz+7O+uoYGzSUjOGfD7gZ8iWO/8C9pEZUTf01jnLNNPjAfZYn9oG6qeDgMZbN/6IwGpb+Z9kFHT/ELM91XUe9abUJX1Hl6xpp10KVJ24iNQrd8c5sbKFawpRi4Ml/pluF8zL+4Vpe0/GYFFRUeGicGGoZGVrHRo3OQKJ23w7K9qwkn+QUoAoraEERa3OPXzlBlGsu3wg==;\n\t31:nra3HBwZfqhwIIue4vhyrdiZmjhCrzogO5sWq8+eEksbRPW3PdRKhO29WA9Rv/g2cJ8Wk5+h8CT6j0L18J9cUn9j71spa9XHFSZ075LvuBa5ZVSrtjklxOexo+PEmbPqnVRkn0He1cVBqbepUIrET5eMJYASyLtQ0acQNNnW7UmlvorCOgd20xTsTSFX8jM7Zlbhg/6PNB0zjXOmjObXxH1+DP2htAQatxkMhJx68sg=","1; DM5PR07MB3497;\n\t20:4KJ6gyZD6KSL+oKX2r1GM8d+XpVG6R0nJ7snh+ScStV+pm2ijE6Dh57eM9uUGpBPdWBDvdG8oZopTq0VMrTNENtdgNgHGhe+8yOlawPr4VgqeNdrq0tOAxNrOthDmag9VCdsrbRC+QkyBIe0oC+QF/8mqyxCu63XyePhr6WVcEm+lN5C9UB3QOQWOarD3N+Y7RgMtHQUXs9GJHD8O6A4Oqzjk7ASOncviXot7JEs7JkwoK1hZpBKB3HzF8pr94D4FxMUn5GEDf6t7nHiCUjv4ytjGlGL6cxMIHCgmYRzHgQwpjZbvcIT7Bx3odI7I2M6m+0Zoyfx3B9+tsCIIGPR6lE9vuHdC1Gqkcww0y0aixI9daf9+yknAe8vl/KpfQe3rSPrPUj429Gg11GX2m+CybgHhmfAovK4B9/1iBNkWT61uMnoEFSi/XvZ/n6vlIUgIxOUnJNNdNT0ut9VM+cAEODw9R6ptU/y7qxgw2s9yOrsMOhf4p/74kL05L7uz10xEPR24qdoAJb6ftXV4wjoR5tfIakd9TtTuovPe9NWVUVJTn9tMyKHFoZdWANSDqhReseU7pE6KoNZ2ynHaX3S2jLpEGdH/wkPuA8vBrXQnVA=;\n\t4:OQOlO2BmoGMYHXugDmn5Lt/aGAqvGFzFuvqCfba5uWZDYi8obCnb+ef/hhvKsX0827oOFd8nLPgI72yT2GiWhgaLSbEvoCxQ9+kRXUQUBFSti8wtpEd7Rc8hi4SXf87bmBhI4HEmoVD2O8vmwdvENhM76w4Xox5D5NXKmnki4gtxgBMkwNw4tcH1mW4sxeyijthFo4+BFrGnkmQipzN8cMCUd5pWpcEyYQMw20XtFPmkmeqwhml8qCYavzdLiXJ5","=?utf-8?q?1=3BDM5PR07MB3497=3B23=3AFEy4?=\n\t=?utf-8?q?XTqDwAsf9CXEZWBItxQNwM9yHzRbYVR7FDV5pPGRte8hMICO/pEg5ceD?=\n\t=?utf-8?q?rLfweBZIlwLa9NDtT/rYAR3AYj4dlqWvpQNHDrUkdAtux7moxw72/3n4?=\n\t=?utf-8?q?4AUfKWdB9WVUajJiDRv3g7BIxWAVyq60dXa1l4MrHfg442DNNo6bnm3g?=\n\t=?utf-8?q?10LfghP7m4WvcbkQ/ZX9WrGTeY7or1WkrYKLsDRSjv91IEzykHV7tGvZ?=\n\t=?utf-8?q?f0PJ4ogyxG9ToGekxDbAmAnlufEvJtlcdB14MotcADIj3e34bTM+v/W+?=\n\t=?utf-8?q?lVjBVlpZCk+8cNGb0urE2WPCdy+qtXZZawoLcYoN28bIMGOdcrp95UPv?=\n\t=?utf-8?q?2gbXin8YfJ/61W8xi/O9WO9Nk0lhRpsA6uWmhI8ixzRrVdSMLo/0ZeGo?=\n\t=?utf-8?q?/0xh5ra8eWh+pUdHUSVccTNxaBWx1ppWFPps/r+OtYdF9vgk5G1dN0DJ?=\n\t=?utf-8?q?u0AKqRLydwriGKrsSbtl5njLju3JH8vfgJ+nALwyUfp2DascOT+nKmH2?=\n\t=?utf-8?q?hNtjf5kw9F5jIzAPZ5uGtrLR8s42zeiKSo9urqOjPNrN4BQTfaYFY8F0?=\n\t=?utf-8?q?gpuOunTZ/rth+GwRz0oQSmwfnmK+c3FXkUWjHvtoqZk6dys6FLQ0WEHz?=\n\t=?utf-8?q?pLvddZzf8xys6ALiFOKfa9Lzvs3ATTR6OODAdPS1kkC2Oyu6yMPtvrRw?=\n\t=?utf-8?q?BRsUcGoeIQ9w31MDWRCZxYEPNIsvxf2y9TUuMd7EBQhHhwWnOmzdZSBX?=\n\t=?utf-8?q?yViETVrCLdkEL6qJSyqlT9iJnBCLO20auZq8TYo8F307J76NFgnXGZcC?=\n\t=?utf-8?q?wRIo5BGisUJUNazPMgCkwysTBqAif0H+mpq5s10/Ygz5zIJVe9Uaxw6g?=\n\t=?utf-8?q?m15DuQhn1V+Lv1jnPSW1EGL6Qug7baFsV57oK52PKwHi5QBF9aGDQawe?=\n\t=?utf-8?q?ZSZ63B1oswgf0XJxl0PlNC3LuaD5zKjxedkq2L7+7C7oT6NkKmiORccK?=\n\t=?utf-8?q?OTWYEY/thUeAgWtHdf/cAUHGKiw0BY2OyjIARwWTYHjrOzpqAlQ7nUeJ?=\n\t=?utf-8?q?PTUsjFKIXBmvGAr5+NxAILP+z8SPILdAVMJ0z3D5gj0eqK0/DNuIllnv?=\n\t=?utf-8?q?Is61CA702MpuYFmZOYuYDzVb3k5h2ZY/OqPDs2i9RrKhFsrXtxf7HWj7?=\n\t=?utf-8?q?KjEbbQHpe8s9MO+YXkdmtUqrdOncPRROtSx2aPlaohW8bv4eYufBHGQb?=\n\t=?utf-8?q?N6rF783e/FH6UPR9FMbh3H+zHv8WjnsXqH0XiT1n/cMONycayJi8K0ig?=\n\t=?utf-8?q?Zp5YOOqvdkBKAKYaLVaKUMCFWkspah/+NlqMwrA2mpcS3MKWsVKlHlRc?=\n\t=?utf-8?q?niyVDLs2P/w5Zw3ZFtHnywuFhSZIluoUg5XQDMgiW0tbjnROpF85wW9J?=\n\t=?utf-8?q?7q4dt51XiHTQjn2Wog=3D=3D?=","1; DM5PR07MB3497;\n\t6:BFENXiCRTneGCKlnqyRBazpPebHxhchtiLe0Iwgh92L7jXq/gKve/8CtCKpLuQCwa2aWc5CCv4ICZLAJSxV9zmgv5C5lVK9GIv8XhcuubyWZvi2GSAv1A2P4QElyWxEtQ7yEJhK1eil5o2XLWs5gEbQfG4mNK1Be1QG0CRdMXju9BzpuiTnoTua9goxsxYOB/2qqnIdok7yiPaDffYFX+ZmtogKgDcuZva+iu4/GAPfZ6ypHV7NeXQ+A2FsuZWvaQcBaNMdUvh+Mvur1aPv/9zlEcnqcp9RfxBIurJEQaRDhjexT4n6VnVWLd7OECJX4m3ZldzRyQQ9snFDQlV9CoQ==;\n\t5:S8S/4oSMhwfUdpxqM53I9Y8YySKifPKhKmuZzMScxYrA49V75GzjdEyO3K4ryureZTEjorOv96uQQFHH5gX2TNtJvwVTYqbFdXS4IVDHpn1Im9modosDT+MO0oR7MtyeYj/Q4aOld7vywYdcK3ja1w==;\n\t24:4Vsm4T86BFE/qSl8QIbvjh7ylg9L46MOzgPwqRiiDLcxjLAkJO5HcaZzyF4ZrIkPd6C3sN5+JpDz9w6z92FRdSn/LXvJ22saSjpfsGnJiDE=;\n\t7:BDu5hg0kv85SJ207oJC4sBleXIza3t5WNLJe+1UICdjJMJJjZ0oBliedtKFTbt5OGFLQvSa8nZ+T82+aRNbHQ3s6thIMryUxydYi2rp1xf4t7exR+knqgSNnL9T9uAmy9H+uPRwoQ5rqi/H1lRJJiX6fPrQ4QqtON40V2RiZ2gDRooq/SsxuQ4HgQq7A2DLWdCC/O9ax/R98I9V1le+gZ3mPX7M8lBtYdEI4oUi1ejo="],"X-MS-TrafficTypeDiagnostic":"DM5PR07MB3497:","X-Exchange-Antispam-Report-Test":"UriScan:;","X-Microsoft-Antispam-PRVS":"","X-Exchange-Antispam-Report-CFA-Test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(6041248)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:DM5PR07MB3497; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:DM5PR07MB3497; ","X-Forefront-PRVS":"04238CD941","X-Forefront-Antispam-Report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(189002)(377454003)(199003)(24454002)(230700001)(229853002)(25786009)(5660300001)(83506001)(54356999)(50986999)(76176999)(105586002)(65826007)(106356001)(478600001)(2906002)(189998001)(53416004)(31696002)(3846002)(81166006)(81156014)(101416001)(6506006)(6246003)(4001350100001)(33646002)(68736007)(54906002)(97736004)(8936002)(53936002)(6486002)(6512007)(65956001)(65806001)(66066001)(7416002)(2950100002)(42882006)(53546010)(6116002)(42186005)(69596002)(4326008)(72206003)(7736002)(31686004)(23676002)(36756003)(50466002)(305945005)(8676002)(47776003)(64126003)(142933001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR07MB3497; H:ddl.caveonetworks.com;\n\tFPR:; \n\tSPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; ","Received-SPF":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","SpamDiagnosticOutput":"1:99","SpamDiagnosticMetadata":"NSPM","X-OriginatorOrg":"caviumnetworks.com","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"07 Sep 2017 17:45:36.1140\n\t(UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"DM5PR07MB3497","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765444,"web_url":"http://patchwork.ozlabs.org/comment/1765444/","msgid":"","list_archive_url":null,"date":"2017-09-08T15:05:49","subject":"Re: [PATCH v4 1/6] irqdomain: rename variables in irq_domain_{push, \n\tpop}_irq()","submitter":{"id":65882,"url":"http://patchwork.ozlabs.org/api/people/65882/","name":"Masahiro Yamada","email":"yamada.masahiro@socionext.com"},"content":"Hi Marc, David,\n\n\n2017-09-08 2:45 GMT+09:00 David Daney :\n> On 09/07/2017 05:47 AM, Marc Zyngier wrote:\n>>\n>> On 07/09/17 12:41, Masahiro Yamada wrote:\n>>>\n>>> The meaning of \"root\" in irq_domain_{push,pop} is opposite to the\n>>> documentation. Documentation/IRQ-domain.txt depicts the hierarchy\n>>> IRQ domain as follows:\n>>>\n>>> CPU Vector irq_domain (root irq_domain to manage CPU vectors)\n>>> ^\n>>> |\n>>> Interrupt Remapping irq_domain (manage irq_remapping entries)\n>>> ^\n>>> |\n>>> IOAPIC irq_domain (manage IOAPIC delivery entries/pins)\n>>>\n>>> From above, the inner-most domain (nearest to the CPU) is \"root\".\n>>>\n>>> The document also says, \"When building irq_domain hierarchy, the\n>>> irq_domain near to the device is child and the irq_domain near to\n>>> CPU is parent.\" This is how irq_data->parent_data works. In\n>>> contrast, these function use a variable \"child_irq_data\" for that.\n>>\n>> The exact opposite argument could be used for the data structure. The\n>> irq_desc is the root of the list ordered with parent_data.\n>>\n>> Yes, this is confusing, but because we're using the same English words\n>> to describe two different things, we're bound to make one thing more\n>> difficult. I'm unconvinced that this change helps anything (it certainly\n>> confuses me more than anything else).\n>>\n>\n> There may be room for improvement here.\n>\n> Here is my recollection of how I choose the names:\n>\n> \"root\" is the thing embedded in the struct irq_desc, if you think about a\n> typical linked list structure like this, we can refer to the starting point\n> as the \"root\". Sometimes it might be referred to as the \"head\" of the list,\n> but usually not the \"tail\"\n>\n> \"child\" was used to indicate the thing we get to by traversing the link in\n> the list. The fact that ->parent is the name of the next pointer and that\n> it points to something called \"child\" is confusing here.\n> So what do I think should be done? This:\n>\n> Either\n> A) s/child_irq_data/parent_irq_data/g As this patch does, but leave the\n> root_irq_data name unchanged.\n\n\nSounds better than the current situation.\n\n\n\n\n> B) Change the name of the ->parent in struct irq_data to ->next\n\n\nThis is a bad idea.\n\nirq_data->parent_data corresponds to irq_domain->parent.\nWe should not lose consistency/symmetry.\n\nirq_domain->parent originates in the \"parent\" argument\npassed to irq_domain_create_hierarchy().\nIf we change this, it will introduce horrible confusion.\n\nAs the document says, when we talk about the hierarchy,\n\"the irq_domain near to the device is\nchild and the irq_domain near to CPU is parent\"\nThis is the original concept, and should not be changed.\n\n\nWe can excuse that all the variables in these two helpers\nwere named from the point of linked-list view,\nnot talking about the hierarchy.\n\n\nHowever, what I thought more confusing was the comment block.\n\n/**\n * irq_domain_push_irq() - Push a domain in to the top of a hierarchy.\n\n\nThis comment is talking about the \"hierarchy\" at first glance.\nSo, what is my mind is the picture in Documentation/IRQ-domain.txt\n\nBut, from the term \"top\", this is talking about the linked list here too.\nThe linked list is just implementation detail...\n\n\n\n\n> But that is just my $0.02\n>\n> I fear we risk a Bike Shedding type of discussion here.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=nifty.com header.i=@nifty.com\n\theader.b=\"Ew5lby7W\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpgdf0mf9z9sCZ\n\tfor ;\n\tSat, 9 Sep 2017 01:06:46 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752538AbdIHPGn (ORCPT\n\t);\n\tFri, 8 Sep 2017 11:06:43 -0400","from conssluserg-04.nifty.com ([210.131.2.83]:21453 \"EHLO\n\tconssluserg-04.nifty.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751941AbdIHPGm (ORCPT\n\t); Fri, 8 Sep 2017 11:06:42 -0400","from mail-yw0-f175.google.com (mail-yw0-f175.google.com\n\t[209.85.161.175]) (authenticated)\n\tby conssluserg-04.nifty.com with ESMTP id v88F6UFb028464;\n\tSat, 9 Sep 2017 00:06:30 +0900","by mail-yw0-f175.google.com with SMTP id v72so6069390ywa.3;\n\tFri, 08 Sep 2017 08:06:30 -0700 (PDT)","by 10.37.164.225 with HTTP; Fri, 8 Sep 2017 08:05:49 -0700 (PDT)"],"DKIM-Filter":"OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com v88F6UFb028464","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com;\n\ts=dec2015msa; t=1504883191;\n\tbh=lPjuR2G0pZ6cyBXYOLkJvQ5KzSwP1OVz1jYCoTy2qfo=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=Ew5lby7Wu5rfqhkQtBUUwvjcsokrDpIo9Ktw8MhSD9lg+NUGzx5vX7TVn+LXrXbZs\n\tRMKHy+xOLd909nEdpqeiTqJNVTEMRE7EnzvSVk3eJeyY4hsM2xtDOal8E6h6mRyPb1\n\t0ZZ99a8lqbe+yZTi4h6nWDJOwVhArQ0pyFgC7BZ8g0XX9jHlJXViLXtuSEvHjdTkYM\n\t7WFL+76IPr1J6IRsNpA/Ta7Vm7iCb95j4c8xYraLL0y7osCqpWXRIBlnFa38UFlYgH\n\tJB8EIUpASeUSUnwWsWcAix+X5+E90gj38HXdyejy13sy9+RFgm/G5jkNlFULguJynB\n\t/+HwdaLdddn4Q==","X-Nifty-SrcIP":"[209.85.161.175]","X-Gm-Message-State":"AHPjjUgBc1RZk+qRJYShn+J/F1jZHx9bvnirAfdyfGW5cXMnC4aZBcj3\n\tLdvylXKwhMuyYVCUtS78jXKu2mBLcQ==","X-Google-Smtp-Source":"ADKCNb7w8YMzdKxoycSwKh2CxMXjkqkMuGwjnDrG6UJ0GvC8Ua/D4wi8MgR9+89+0ianra1WRwLdm+nCRnmexDoW0mA=","X-Received":"by 10.37.41.133 with SMTP id p127mr2608040ybp.331.1504883189641; \n\tFri, 08 Sep 2017 08:06:29 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1504784522-26841-2-git-send-email-yamada.masahiro@socionext.com>\n\t\n\t","From":"Masahiro Yamada ","Date":"Sat, 9 Sep 2017 00:05:49 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v4 1/6] irqdomain: rename variables in irq_domain_{push, \n\tpop}_irq()","To":"David Daney ","Cc":"Marc Zyngier , Thomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ,\n\tJassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney ,\n\tLinux Kernel Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765446,"web_url":"http://patchwork.ozlabs.org/comment/1765446/","msgid":"","list_archive_url":null,"date":"2017-09-08T15:06:48","subject":"Re: [PATCH v4 0/6] irqdomain, gpio: expand irq_domain_push_irq() for\n\tDT use and use it for GPIO","submitter":{"id":65882,"url":"http://patchwork.ozlabs.org/api/people/65882/","name":"Masahiro Yamada","email":"yamada.masahiro@socionext.com"},"content":"Hi Marc.\n\n2017-09-07 21:39 GMT+09:00 Marc Zyngier :\n>> I think there is a possibility where a device tries to get IRQ\n>> after irq_domain_create_hierarchy(), but before irq_domain_push_irq().\n>>\n>> priv->domain = irq_domain_create_hierarchy(...)\n>> if (!priv->domain)\n>> return -ENOMEM;\n>>\n>> [ *** What if a irq consumer device request the irq here? *** ]\n>\n> We've explicitly forbidden such a use case. There is a (not exactly fool\n> proof) check in irq_domain_push_irq(), but it is pretty easy to bypass\n> it. \"Don't do it\" is the conclusion we reached with David Daney.\n>\n> If you don't want these interrupts to be requested, you might as well\n> flag them as IRQ_NOREQUEST, and unflag them when the hierarchy is ready.\n>\n> Would that work for you?\n\n\nSorry if my description was unclear.\n\nI do not think IRQ_NOREQUEST is equivalent\nto IRQ_DOMAIN_FLAG_NO_CREATE I am trying to add in 5/6.\n\n\nMy intention is to prevent platform_get_irq()\nfrom allocating a new virq.\n\nI think IRQ_NOREQUEST only affects request_irq().\n\n\n\nHaving said that, this series got negative response\nas a whole.\n\nMy motivation is to get my GPIO driver (6/6) in\nby hook or by crook.\nIf you do not like this series, please feel free to throw it away.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=nifty.com header.i=@nifty.com\n\theader.b=\"T84mdPfY\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpgg304Ksz9sCZ\n\tfor ;\n\tSat, 9 Sep 2017 01:07:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755541AbdIHPHj (ORCPT\n\t);\n\tFri, 8 Sep 2017 11:07:39 -0400","from conssluserg-02.nifty.com ([210.131.2.81]:38182 \"EHLO\n\tconssluserg-02.nifty.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1754969AbdIHPHh (ORCPT\n\t); Fri, 8 Sep 2017 11:07:37 -0400","from mail-yw0-f177.google.com (mail-yw0-f177.google.com\n\t[209.85.161.177]) (authenticated)\n\tby conssluserg-02.nifty.com with ESMTP id v88F7TMS031527;\n\tSat, 9 Sep 2017 00:07:29 +0900","by mail-yw0-f177.google.com with SMTP id v72so6077686ywa.3;\n\tFri, 08 Sep 2017 08:07:29 -0700 (PDT)","by 10.37.164.225 with HTTP; Fri, 8 Sep 2017 08:06:48 -0700 (PDT)"],"DKIM-Filter":"OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com v88F7TMS031527","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com;\n\ts=dec2015msa; t=1504883250;\n\tbh=OvS+2REqlQM7MVXnowjwc0uSlyGLWcHMe6BVzNwIcb8=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=T84mdPfYUL+DYvhhzFgmlBA2SKBpjDED1DvytaxJh4Poc4u73kJdQs7+8ODOXqzE0\n\tyQk0HPYRkjxVjvOMm+Pk+s9XR8ygs5mH97rUvjEXEAdwdMuVE7dL8jm/HUGV3f9ApO\n\tX/PFmVJzZ4juSKMnimSRVHcetI+TVO1P8GXjMT+t6LuJtrvG3pQKbG6ePqFKzSpU+K\n\tona/dpK017nMN3MLTG2bSHSmNO9rYQc6Yk/pnL21uf7t2hGv7+TjZ340PlAeEDmEBC\n\tj8/w1DiSmHReujwoOnPdoKZ4ycIc00jZWUsjBNfKv4Ad6FLd2VGewzWH9zFCcVLpFv\n\tVBfwxB81tVmWA==","X-Nifty-SrcIP":"[209.85.161.177]","X-Gm-Message-State":"AHPjjUjo1DmrYRKuvDQTkDszt6Kc3Gvu5ZyoDxUr6MGkaupn8jvyK222\n\tJwGjvidVsITBuU1C8MMZ+Ck3BVdOdg==","X-Google-Smtp-Source":"ADKCNb6ZaSMfU0uApY5hqPc7hD7a8uJsPE+N8HrV30BHc+nOp5CMQP+qDjsF58Vg9jnS/RN7ppU/fvY54138JFVZ4N8=","X-Received":"by 10.129.123.194 with SMTP id\n\tw185mr2656995ywc.333.1504883248649; \n\tFri, 08 Sep 2017 08:07:28 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t","From":"Masahiro Yamada ","Date":"Sat, 9 Sep 2017 00:06:48 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v4 0/6] irqdomain, gpio: expand irq_domain_push_irq() for\n\tDT use and use it for GPIO","To":"Marc Zyngier ","Cc":"Thomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ,\n\tJassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney ,\n\tLinux Kernel Mailing List ,\n\tMark Rutland ,\n\tlinux-arm-kernel ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765449,"web_url":"http://patchwork.ozlabs.org/comment/1765449/","msgid":"","list_archive_url":null,"date":"2017-09-08T15:09:35","subject":"Re: [PATCH v4 2/6] irqdomain: clear trigger type in\n\tirq_domain_push_irq()","submitter":{"id":65882,"url":"http://patchwork.ozlabs.org/api/people/65882/","name":"Masahiro Yamada","email":"yamada.masahiro@socionext.com"},"content":"Hi Marc,\n\n\n2017-09-07 21:25 GMT+09:00 Marc Zyngier :\n> On 07/09/17 12:41, Masahiro Yamada wrote:\n>> Prior to the addition of irq_domain_push_irq(), the hierarchy\n>> IRQ domain always allocates IRQs from the outer-most domain.\n>> Each irqchip usually calls irq_domain_alloc_irqs_parent(),\n>> ascending the topology up to the root irqchip.\n>>\n>> The brand-new function irq_domain_push_irq() allows us to allocate\n>> IRQs for parent domain first, then add a child irq_data to the\n>> tail of the chain.\n>>\n>> For the new use-case, if the parent sets a temporary trigger type,\n>> it may differ from the type requested to the outer-most irqchip,\n>> then irq_create_fwspec_mapping() warns \"type mismatch, failed to map...\"\n>>\n>> Clear the trigger type when a new irq_data is connected to the chain.\n>>\n>> Signed-off-by: Masahiro Yamada \n>> ---\n>>\n>> Changes in v4:\n>> - Newly added\n>>\n>>\n>> kernel/irq/irqdomain.c | 3 +++\n>> 1 file changed, 3 insertions(+)\n>>\n>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c\n>> index da3e0b6..18d11b9 100644\n>> --- a/kernel/irq/irqdomain.c\n>> +++ b/kernel/irq/irqdomain.c\n>> @@ -1532,6 +1532,9 @@ int irq_domain_push_irq(struct irq_domain *domain, int virq, void *arg)\n>> tail_irq_data->chip = NULL;\n>> tail_irq_data->chip_data = NULL;\n>>\n>> + /* clear the trigger type to avoid \"type mismatch\" error */\n>> + irqd_set_trigger_type(tail_irq_data, IRQ_TYPE_NONE);\n>> +\n>\n> This feels wrong. The initial interrupt hierarchy does have a set\n> trigger, because it has been configured already, and switching it to\n> NONE is hiding the fact that you're setting it to another, conflicting\n> value.\n>\n> Your new fwspec should have a type that is really compatible with with\n> the underlying interrupt, however \"temporary\". If it is not, you have a\n> problem.\n>\n\n\nMy motivation is to describe interrupt connection by\nDT property, like follows:\n\ninterrupts = <48 4>, <49 4>, <50 4>, <51 4>,\n <52 4>, <53 4>, <54 4>, <55 4>,\n <56 4>, <57 4>, <58 4>, <59 4>,\n <60 4>, <61 4>, <62 4>, <63 4>,\n <154 4>, <155 4>, <156 4>, <157 4>,\n <158 4>;\n\n\nThe number of cells is fixed, so I need to\ngive something as the second parameter.\n\nThe \"4\" may not be a real trigger type,\nit is just a temporal value to fill the space.\n\n\nThe device may pass a different trigger type\nwhen it calls gpio_to_irq() && request_irq().\nI cannot know the real trigger type until the device is probed.\n\n\nHaving said that, if this is a bad idea,\nI will consider a different approach for my GPIO driver.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=nifty.com header.i=@nifty.com\n\theader.b=\"c5UgJTyn\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpgkF5ZMrz9sBZ\n\tfor ;\n\tSat, 9 Sep 2017 01:10:45 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754582AbdIHPKb (ORCPT\n\t);\n\tFri, 8 Sep 2017 11:10:31 -0400","from conssluserg-06.nifty.com ([210.131.2.91]:62425 \"EHLO\n\tconssluserg-06.nifty.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753072AbdIHPKa (ORCPT\n\t); Fri, 8 Sep 2017 11:10:30 -0400","from mail-yw0-f170.google.com (mail-yw0-f170.google.com\n\t[209.85.161.170]) (authenticated)\n\tby conssluserg-06.nifty.com with ESMTP id v88FAGmp017699;\n\tSat, 9 Sep 2017 00:10:17 +0900","by mail-yw0-f170.google.com with SMTP id q80so8288861ywg.2;\n\tFri, 08 Sep 2017 08:10:17 -0700 (PDT)","by 10.37.164.225 with HTTP; Fri, 8 Sep 2017 08:09:35 -0700 (PDT)"],"DKIM-Filter":"OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com v88FAGmp017699","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com;\n\ts=dec2015msa; t=1504883417;\n\tbh=OYbONB/N0BHkYsdS/CfTN5pDChvVEn1uftboDK0ZcF8=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=c5UgJTynhbcuA5kZzqRcBvsuDuGjyLHq1ZGhLtU3I/6SaJHlBrKIVGTgbHuk0uMDT\n\t6N2OyPUu61VNWKmHNonnotb52Cggv8Sfs7AJ/B2boO0GnQ6iF6fQ7roHMYa4ELsFit\n\t3JnDhLKUlaSu3IwDhRaThCztU47aKt63O5DgxUOQO+c+iBqPzLe7yXWjDONXt4fo9R\n\t2t3nIT7QswX3ATg7oQeLBkXA+74bKCkBRARL1CvuH2IdwqJ25PiSIZkgnnOdYQ/Ogb\n\tZa7Pv1tsOY86Os1hfWu9pZnrmt3jTcqjFPgRdfMtXBE2swWDZ9Ko1h6xgcX9y/HCF1\n\tKf770oiyt3UIg==","X-Nifty-SrcIP":"[209.85.161.170]","X-Gm-Message-State":"AHPjjUhc+yvi9CR43q2oeFsKt0G/UJ1MRrCK8MHutCFhLjSoYT/uK/FO\n\tcGWicVZFeCkpUHvbdo7Tcd5zI+Pf7g==","X-Google-Smtp-Source":"ADKCNb6bSyv1Gg9cFfd64tRoi3u+MviQSwz4TaNLTbCiOF0kkQA4fP82oEdZzcBA1KhEISZvOmu40LhY+0qrKGmW6Tk=","X-Received":"by 10.37.133.76 with SMTP id f12mr2580167ybn.79.1504883416184;\n\tFri, 08 Sep 2017 08:10:16 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1504784522-26841-3-git-send-email-yamada.masahiro@socionext.com>\n\t","From":"Masahiro Yamada ","Date":"Sat, 9 Sep 2017 00:09:35 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v4 2/6] irqdomain: clear trigger type in\n\tirq_domain_push_irq()","To":"Marc Zyngier ","Cc":"Thomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ,\n\tJassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney ,\n\tLinux Kernel Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765450,"web_url":"http://patchwork.ozlabs.org/comment/1765450/","msgid":"","list_archive_url":null,"date":"2017-09-08T15:10:36","subject":"Re: [PATCH v4 3/6] irqdomain: move IRQ_DOMAIN_NAME_ALLOCATED define\n\tto the original position","submitter":{"id":65882,"url":"http://patchwork.ozlabs.org/api/people/65882/","name":"Masahiro Yamada","email":"yamada.masahiro@socionext.com"},"content":"2017-09-07 21:04 GMT+09:00 Marc Zyngier :\n> On 07/09/17 12:41, Masahiro Yamada wrote:\n>> Commit 6a6544e520ab (\"genirq/irqdomain: Remove auto-recursive hierarchy\n>> support\") not only deleted IRQ_DOMAIN_FLAG_AUTO_RECURSIVE, but also\n>> moved IRQ_DOMAIN_NAME_ALLOCATED up.\n>>\n>> Get it back to the original position to sort the enum by the bit shift.\n>>\n>> Signed-off-by: Masahiro Yamada \n>> ---\n>>\n>> Changes in v4:\n>> - Newly added\n>>\n>>\n>> include/linux/irqdomain.h | 6 +++---\n>> 1 file changed, 3 insertions(+), 3 deletions(-)\n>>\n>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h\n>> index 81e4889..31be32d 100644\n>> --- a/include/linux/irqdomain.h\n>> +++ b/include/linux/irqdomain.h\n>> @@ -180,9 +180,6 @@ enum {\n>> /* Irq domain is hierarchical */\n>> IRQ_DOMAIN_FLAG_HIERARCHY = (1 << 0),\n>>\n>> - /* Irq domain name was allocated in __irq_domain_add() */\n>> - IRQ_DOMAIN_NAME_ALLOCATED = (1 << 6),\n>> -\n>> /* Irq domain is an IPI domain with virq per cpu */\n>> IRQ_DOMAIN_FLAG_IPI_PER_CPU = (1 << 2),\n>>\n>> @@ -195,6 +192,9 @@ enum {\n>> /* Irq domain implements MSI remapping */\n>> IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),\n>>\n>> + /* Irq domain name was allocated in __irq_domain_add() */\n>> + IRQ_DOMAIN_NAME_ALLOCATED = (1 << 6),\n>> +\n>\n> The right fix would be to leave it where it is, but to actually fix the\n> shift, which is what I should have done the first place.\n\n\nYou are definitely right.\n\nAt first, I missed the fact that (1 << 6) was already used,\nthen I assigned the same value to my new flag.\n\nSo, I tried to fix the list before adding my new one.\n\n\nWithout 5/6, I do not have a good reason to\npush this cosmetic patch only.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=nifty.com header.i=@nifty.com\n\theader.b=\"kPu9Ge4r\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpgl93x6Vz9sCZ\n\tfor ;\n\tSat, 9 Sep 2017 01:11:33 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1756486AbdIHPLb (ORCPT\n\t);\n\tFri, 8 Sep 2017 11:11:31 -0400","from conssluserg-06.nifty.com ([210.131.2.91]:63234 \"EHLO\n\tconssluserg-06.nifty.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1756469AbdIHPLa (ORCPT\n\t); Fri, 8 Sep 2017 11:11:30 -0400","from mail-yw0-f172.google.com (mail-yw0-f172.google.com\n\t[209.85.161.172]) (authenticated)\n\tby conssluserg-06.nifty.com with ESMTP id v88FBHU1018069;\n\tSat, 9 Sep 2017 00:11:17 +0900","by mail-yw0-f172.google.com with SMTP id s62so8329233ywg.0;\n\tFri, 08 Sep 2017 08:11:17 -0700 (PDT)","by 10.37.164.225 with HTTP; Fri, 8 Sep 2017 08:10:36 -0700 (PDT)"],"DKIM-Filter":"OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com v88FBHU1018069","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com;\n\ts=dec2015msa; t=1504883478;\n\tbh=smEkTAHZgttVdH6rWdOFkVw+dv334g/SHM86rwWfrws=;\n\th=In-Reply-To:References:From:Date:Subject:To:Cc:From;\n\tb=kPu9Ge4ra97UASHLMZ63aM1mOmlrPbSuXRyS9C7SFfsXIiZqC5/+AIxWZLiSgyQT7\n\t5cW78oCS7dHSnaQmdTPPvQYdh88/3W3AROnPgliQMlDEu4Qkxxh6j+1XAt+n4uXebY\n\t4w1fdqNhYBVH7HpwpMNhmm7kBUkkn1R9JSYa22poJ8cECnSBIXhQUOJ0JThStqqRrs\n\tjJDbBVyJ9fAoh/iZd+F2J4n0vEAymrinplen9Le2FmGcA3Uz1j4SnNTmK2J8D2GOZ6\n\t/ju2yl1GUIRuUIakN0WfUHRo74ijBLElMfxd1COMTqlZhyOq5qyFsUt3FsO+cPruoR\n\tKb+akjebN5LSA==","X-Nifty-SrcIP":"[209.85.161.172]","X-Gm-Message-State":"AHPjjUhzutZiRYwmFg+6HCcKvOlYeYXwGy9Lg2H5787d3pMWxULumwLm\n\t/ltzyhTlSChd3/1MsexQqF2VA6Lb6Q==","X-Google-Smtp-Source":"ADKCNb7woqtIKImEZUX/LE6V9U4b8Ahusflh4QpBv2/ldhv0BOhRgRVoTeaYWPoNdb1zK0JKBmdFQyzSySwkMeariTQ=","X-Received":"by 10.129.121.4 with SMTP id u4mr2871647ywc.71.1504883476759;\n\tFri, 08 Sep 2017 08:11:16 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<92500143-814b-b255-bb7b-c36d5eca5457@arm.com>","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<1504784522-26841-4-git-send-email-yamada.masahiro@socionext.com>\n\t<92500143-814b-b255-bb7b-c36d5eca5457@arm.com>","From":"Masahiro Yamada ","Date":"Sat, 9 Sep 2017 00:10:36 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v4 3/6] irqdomain: move IRQ_DOMAIN_NAME_ALLOCATED define\n\tto the original position","To":"Marc Zyngier ","Cc":"Thomas Gleixner ,\n\tLinus Walleij ,\n\tlinux-gpio@vger.kernel.org, Rob Herring ,\n\tJassi Brar ,\n\tdevicetree@vger.kernel.org, Jason Cooper ,\n\tMasami Hiramatsu ,\n\tDavid Daney ,\n\tLinux Kernel Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]