[{"id":1764696,"web_url":"http://patchwork.ozlabs.org/comment/1764696/","msgid":"<b0f7495b-3b51-a75f-2a29-bbcd86eacb53@arm.com>","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":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@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=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xp0QG5F7Qz9s8J\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu,  7 Sep 2017 22:39:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754982AbdIGMjS (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\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 <rfc822;linux-gpio@vger.kernel.org>);\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 <yamada.masahiro@socionext.com>,\n\tThomas Gleixner <tglx@linutronix.de>,\n\tLinus Walleij <linus.walleij@linaro.org>,\n\tlinux-gpio@vger.kernel.org, Rob Herring <robh+dt@kernel.org>","Cc":"Jassi Brar <jaswinder.singh@linaro.org>,\n\tdevicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,\n\tMasami Hiramatsu <mhiramat@kernel.org>,\n\tDavid Daney <david.daney@cavium.com>,\n\tlinux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,\n\tlinux-arm-kernel@lists.infradead.org","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>","From":"Marc Zyngier <marc.zyngier@arm.com>","Organization":"ARM Ltd","Message-ID":"<b0f7495b-3b51-a75f-2a29-bbcd86eacb53@arm.com>","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":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":1765445,"web_url":"http://patchwork.ozlabs.org/comment/1765445/","msgid":"<CAK7LNASFPdcgifCChbeXPzek3Lk_x-q7LG83vv8LK0jWkurE5A@mail.gmail.com>","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 <marc.zyngier@arm.com>:\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":"<linux-gpio-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@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=linux-gpio-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","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 3xpgg06x4Kz9sBZ\n\tfor <incoming@patchwork.ozlabs.org>;\n\tSat,  9 Sep 2017 01:07:56 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755564AbdIHPHj (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\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<rfc822; linux-gpio@vger.kernel.org>); 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":"<b0f7495b-3b51-a75f-2a29-bbcd86eacb53@arm.com>","References":"<1504784522-26841-1-git-send-email-yamada.masahiro@socionext.com>\n\t<b0f7495b-3b51-a75f-2a29-bbcd86eacb53@arm.com>","From":"Masahiro Yamada <yamada.masahiro@socionext.com>","Date":"Sat, 9 Sep 2017 00:06:48 +0900","X-Gmail-Original-Message-ID":"<CAK7LNASFPdcgifCChbeXPzek3Lk_x-q7LG83vv8LK0jWkurE5A@mail.gmail.com>","Message-ID":"<CAK7LNASFPdcgifCChbeXPzek3Lk_x-q7LG83vv8LK0jWkurE5A@mail.gmail.com>","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 <marc.zyngier@arm.com>","Cc":"Thomas Gleixner <tglx@linutronix.de>,\n\tLinus Walleij <linus.walleij@linaro.org>,\n\tlinux-gpio@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,\n\tJassi Brar <jaswinder.singh@linaro.org>,\n\tdevicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,\n\tMasami Hiramatsu <mhiramat@kernel.org>,\n\tDavid Daney <david.daney@cavium.com>,\n\tLinux Kernel Mailing List <linux-kernel@vger.kernel.org>,\n\tMark Rutland <mark.rutland@arm.com>,\n\tlinux-arm-kernel <linux-arm-kernel@lists.infradead.org>","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-gpio.vger.kernel.org>","X-Mailing-List":"linux-gpio@vger.kernel.org"}}]