[{"id":1761002,"web_url":"http://patchwork.ozlabs.org/comment/1761002/","msgid":"<20170831133951.GA8154@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-31T13:39:52","subject":"Re: [PATCH v6 0/3] PCI hotplug feature","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Thu, Aug 31, 2017 at 10:20:26AM +0530, Oza Pawandeep wrote:\n> These patches bring in PCI hotplug support for iproc family chipsets.\n> \n> It includes DT binding documentation and, the implementation in\n> iproc pcie RC driver.\n> \n> Changes since v5:\n> [RESEND]\n\nNot sure what the point of resending this as v6 was, since v5 was\nposted 6 minutes earlier and you don't mention any changes in v6?\n\n> Changes since v4:\n> Rebased to pci-next\n> Added; Acked-by: Rob Herring \n> \n> Changes since v3:\n> Resend. just to be in sync previous in-flight patches.\n> \n> Changes since v2:\n> Addressed Rob Herring's comments.\n> Changed subject to \"dt-bindings: PCI:...\"\n> Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'\n> Rebased the patches on top of Lorenzo's patches.\n> \n> Oza Pawandeep (3):\n> dt-bindings: PCI: Add PCI hotplug property\n> dt-bindings: PCI iproc: Implement optional property prsnt-gpios\n> PCI: iproc: Implement PCI hotplug support\n> \n> .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 14 ++\n> Documentation/devicetree/bindings/pci/pci.txt | 15 ++\n> drivers/pci/host/pcie-iproc-platform.c | 3 +\n> drivers/pci/host/pcie-iproc.c | 166 ++++++++++++++++++---\n> drivers/pci/host/pcie-iproc.h | 7 +\n> 5 files changed, 187 insertions(+), 18 deletions(-)\n> \n> -- \n> 1.9.1\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=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjk5830CVz9sPt\n\tfor ;\n\tThu, 31 Aug 2017 23:39:56 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751323AbdHaNjy (ORCPT\n\t);\n\tThu, 31 Aug 2017 09:39:54 -0400","from mail.kernel.org ([198.145.29.99]:47782 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751317AbdHaNjy (ORCPT );\n\tThu, 31 Aug 2017 09:39:54 -0400","from localhost (173-25-1-159.client.mchsi.com [173.25.1.159])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 567762133E;\n\tThu, 31 Aug 2017 13:39:53 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 567762133E","Date":"Thu, 31 Aug 2017 08:39:52 -0500","From":"Bjorn Helgaas ","To":"Oza Pawandeep ","Cc":"Bjorn Helgaas , Rob Herring ,\n\tMark Rutland , Ray Jui ,\n\tScott Branden ,\n\tJon Mason , \n\tbcm-kernel-feedback-list@broadcom.com,\n\tAndy Gospodarek ,\n\tlinux-pci@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tOza Pawandeep ","Subject":"Re: [PATCH v6 0/3] PCI hotplug feature","Message-ID":"<20170831133951.GA8154@bhelgaas-glaptop.roam.corp.google.com>","References":"<1504155029-24729-1-git-send-email-oza.oza@broadcom.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1504155029-24729-1-git-send-email-oza.oza@broadcom.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1761191,"web_url":"http://patchwork.ozlabs.org/comment/1761191/","msgid":"","list_archive_url":null,"date":"2017-08-31T16:59:01","subject":"Re: [PATCH v6 0/3] PCI hotplug feature","submitter":{"id":72267,"url":"http://patchwork.ozlabs.org/api/people/72267/","name":"Oza Pawandeep","email":"oza.pawandeep@gmail.com"},"content":"On Thu, Aug 31, 2017 at 7:09 PM, Bjorn Helgaas wrote:\n> On Thu, Aug 31, 2017 at 10:20:26AM +0530, Oza Pawandeep wrote:\n>> These patches bring in PCI hotplug support for iproc family chipsets.\n>>\n>> It includes DT binding documentation and, the implementation in\n>> iproc pcie RC driver.\n>>\n>> Changes since v5:\n>> [RESEND]\n>\n> Not sure what the point of resending this as v6 was, since v5 was\n> posted 6 minutes earlier and you don't mention any changes in v6?\n\nMy apologies,\nIt looked to me that v5 went out twice, might be confusing.\n\nHence sent out v6.\n\nRegards,\nOza.\n>\n>> Changes since v4:\n>> Rebased to pci-next\n>> Added; Acked-by: Rob Herring \n>>\n>> Changes since v3:\n>> Resend. just to be in sync previous in-flight patches.\n>>\n>> Changes since v2:\n>> Addressed Rob Herring's comments.\n>> Changed subject to \"dt-bindings: PCI:...\"\n>> Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'\n>> Rebased the patches on top of Lorenzo's patches.\n>>\n>> Oza Pawandeep (3):\n>> dt-bindings: PCI: Add PCI hotplug property\n>> dt-bindings: PCI iproc: Implement optional property prsnt-gpios\n>> PCI: iproc: Implement PCI hotplug support\n>>\n>> .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 14 ++\n>> Documentation/devicetree/bindings/pci/pci.txt | 15 ++\n>> drivers/pci/host/pcie-iproc-platform.c | 3 +\n>> drivers/pci/host/pcie-iproc.c | 166 ++++++++++++++++++---\n>> drivers/pci/host/pcie-iproc.h | 7 +\n>> 5 files changed, 187 insertions(+), 18 deletions(-)\n>>\n>> --\n>> 1.9.1\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\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"AkvpP9g9\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjpVx3472z9sD5\n\tfor ;\n\tFri, 1 Sep 2017 02:59:05 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751877AbdHaQ7D (ORCPT\n\t);\n\tThu, 31 Aug 2017 12:59:03 -0400","from mail-oi0-f66.google.com ([209.85.218.66]:35259 \"EHLO\n\tmail-oi0-f66.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751834AbdHaQ7C (ORCPT\n\t); Thu, 31 Aug 2017 12:59:02 -0400","by mail-oi0-f66.google.com with SMTP id k77so184986oib.2;\n\tThu, 31 Aug 2017 09:59:02 -0700 (PDT)","by 10.157.4.9 with HTTP; Thu, 31 Aug 2017 09:59:01 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=FP8DEVqgPX9+x59A7+mkYhS0fCUmlz5gsZdUEbfsX20=;\n\tb=AkvpP9g9KyeyiBXkdOny+9bRub3Hd8Hvq/GBuRhepzpmwWhgd0vENfy0pPXwhXnPqg\n\t8UiZWtIw587zC4uWXPCB3J6hMomJ7STNr2ZbA88zXVgBivfRJJI9xMnw8haqkfmKgF3v\n\tQlXc+jeqEbjCiZmS6BnNAibY34BnmHf0gEf0yOdq73wQ48bWlvB5I4hLbeXYl+K0TXNG\n\t++gny7Cg3fF2a2ysTFXy9WoVjKcwFAj6ftmy64khXZcPoqhzhOgXcS6Pyv0xhlYNerDc\n\tV7afDNhuP2Ntq1BlyFjho1SIPqLUVNWQjXQ4HqtSfTPVkYko7fF5V21+yXEUflx/rRDw\n\tXRhw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=FP8DEVqgPX9+x59A7+mkYhS0fCUmlz5gsZdUEbfsX20=;\n\tb=DmayW4iRPUem/QoJUD7+/ibr6RicJU0laHKTMRWZe5JU2yTdoMs+11/c6SSBZhhMlS\n\ttsaJNmlSbTuQ8ihLyoWMnIy1XawmhjBGX4L7FDTx3awknFl2rXdxakhMYdsNW6NXPx1R\n\tK+5AJwOniDIXtuQDWXuWHiSYyysNHNXWbG/o6A465SiXmCja9OoX1jsieGGTS2ihVRcw\n\tdqlaTLdqwPq7EfUX+pIaf0XeXc9d+qzBZyP170D9Hn8xP5PnRDVJicMl0lKCW1n3owYL\n\tC+Di98IdE3K+3ERjVetsWcIHJW/3K6h3XhtUyHsOxX1nh8+RUfeqi7HM1HkygM68+N6v\n\tKnJQ==","X-Gm-Message-State":"AHYfb5hs4L4BBLEZzbh2E0gxq3tsesG9PDsHhpqEn0V8arspVnVIwf4e\n\tKDKcCySJmxemCSfD3IvETTg0tR70QA==","X-Google-Smtp-Source":"ADKCNb5K8EeXR+bG9VEs8epCEhDTa5F6+oQUwk1Od1RIdSV1tN0/M6bO/NweWT0Hvg1UHPvJvU1dbD+9su6/3JCZiKY=","X-Received":"by 10.202.208.70 with SMTP id h67mr7034417oig.153.1504198741800; \n\tThu, 31 Aug 2017 09:59:01 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170831133951.GA8154@bhelgaas-glaptop.roam.corp.google.com>","References":"<1504155029-24729-1-git-send-email-oza.oza@broadcom.com>\n\t<20170831133951.GA8154@bhelgaas-glaptop.roam.corp.google.com>","From":"Oza Pawandeep ","Date":"Thu, 31 Aug 2017 22:29:01 +0530","Message-ID":"","Subject":"Re: [PATCH v6 0/3] PCI hotplug feature","To":"Bjorn Helgaas ","Cc":"Oza Pawandeep , Bjorn Helgaas ,\n\tRob Herring , Mark Rutland ,\n\tRay Jui , Scott Branden ,\n\tJon Mason ,\n\tbcm-kernel-feedback-list@broadcom.com, \n\tAndy Gospodarek ,\n\tlinux-pci@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org","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":1781467,"web_url":"http://patchwork.ozlabs.org/comment/1781467/","msgid":"<20171006113700.GA25517@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-10-06T11:37:00","subject":"Re: [PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Thu, Aug 31, 2017 at 10:20:29AM +0530, Oza Pawandeep wrote:\n> This patch implements PCI hotplug support for iproc family chipsets.\n> \n> iproc based SOC (e.g. Stingray) does not have hotplug controller\n> integrated.\n> Hence, standard PCI hotplug framework hooks can-not be used.\n> e.g. controlled power up/down of slot.\n> \n> The mechanism, for e.g. Stingray has adopted for PCI hotplug is as follows:\n> PCI present lines are input to GPIOs depending on the type of\n> connector (x2, x4, x8).\n> \n> GPIO array needs to be present if hotplug is supported.\n> HW implementation is SOC/Board specific, and also it depends on how\n> add-in card is designed\n> (e.g. how many present pins are implemented).\n> \n> If x8 card is connected, then it might be possible that all the\n> 3 present pins could go low, or at least one pin goes low.\n> If x4 card is connected, then it might be possible that 2 present\n> pins go low, or at least one pin goes low.\n> \n> The implementation essentially takes care of following:\n> > Initializing hotplug irq thread.\n> > Detecting the endpoint device based on link state.\n> > Handling PERST and detecting the plugged devices.\n> > Ordered Hot plug-out, where User is expected\n> to write 1 to /sys/bus/pci/devices//remove\n> > Handling spurious interrupt\n> > Handling multiple interrupts and makes sure that card is\n> enumerated only once.\n\nI haven't forgotten this, but I am dragging my feet a little bit.\nThere is a standard way for hardware to support PCIe hotplug, and it's\nhard enough to get the software for that right. I really, really\ndon't want to see a bunch of one-off implementations that sort of look\nlike standard hotplug but not really.\n\nI have a few trivial comments below but haven't really reviewed the\nwhole thing.\n\n> Signed-off-by: Oza Pawandeep \n> Reviewed-by: Ray Jui \n> \n> diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c\n> index a5073a9..6287a43 100644\n> --- a/drivers/pci/host/pcie-iproc-platform.c\n> +++ b/drivers/pci/host/pcie-iproc-platform.c\n> @@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev)\n> \t\tpcie->need_ob_cfg = true;\n> \t}\n> \n> +\tif (of_property_read_bool(np, \"slot-pluggable\"))\n> +\t\tpcie->enable_hotplug = true;\n> +\n> \t/* PHY use is optional */\n> \tpcie->phy = devm_phy_get(dev, \"pcie-phy\");\n> \tif (IS_ERR(pcie->phy)) {\n> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c\n> index 8bd5e54..2b4d830 100644\n> --- a/drivers/pci/host/pcie-iproc.c\n> +++ b/drivers/pci/host/pcie-iproc.c\n> @@ -28,6 +28,7 @@\n> #include \n> #include \n> #include \n> +#include \n> \n> #include \"pcie-iproc.h\"\n> \n> @@ -65,6 +66,17 @@\n> #define PCIE_DL_ACTIVE_SHIFT 2\n> #define PCIE_DL_ACTIVE BIT(PCIE_DL_ACTIVE_SHIFT)\n> \n> +#define CFG_RC_LTSSM 0x1cf8\n> +#define CFG_RC_PHY_CTL 0x1804\n> +#define CFG_RC_LTSSM_TIMEOUT 1000\n> +#define CFG_RC_LTSSM_STATE_MASK 0xff\n> +#define CFG_RC_LTSSM_STATE_L1 0x1\n> +\n> +#define CFG_RC_CLR_LTSSM_HIST_SHIFT 29\n> +#define CFG_RC_CLR_LTSSM_HIST_MASK BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)\n> +#define CFG_RC_CLR_RECOV_HIST_SHIFT 31\n> +#define CFG_RC_CLR_RECOV_HIST_MASK BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)\n> +\n> #define APB_ERR_EN_SHIFT 0\n> #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)\n> \n> @@ -1354,13 +1366,107 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)\n> \treturn 0;\n> }\n> \n> +static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)\n\n*_check_*() is a terrible name for a function because it doesn't give\nany hint about what a \"true\" return value means.\n\nThis looks sort of like dw_pcie_wait_for_link() and\nadvk_pcie_wait_for_link(). Please use a name more like them and\nstructure the code more like them.\n\n> +{\n> +\tstruct pci_bus *bus = pcie->root_bus;\n> +\tu32 val, timeout = CFG_RC_LTSSM_TIMEOUT;\n> +\n> +\t/* Clear LTSSM history. */\n> +\tpci_bus_read_config_dword(pcie->root_bus, 0,\n> +\t\t\t\t CFG_RC_PHY_CTL, &val);\n> +\tpci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,\n> +\t\t\t\t val | CFG_RC_CLR_RECOV_HIST_MASK |\n> +\t\t\t\t CFG_RC_CLR_LTSSM_HIST_MASK);\n> +\t/* write back the origional value. */\n\ns/origional/original/\n\n> +\tpci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);\n> +\n> +\tdo {\n> +\t\tpci_bus_read_config_dword(pcie->root_bus, 0,\n> +\t\t\t\t\t CFG_RC_LTSSM, &val);\n> +\t\t/* check link state to see if link moved to L1 state. */\n> +\t\tif ((val & CFG_RC_LTSSM_STATE_MASK) ==\n> +\t\t CFG_RC_LTSSM_STATE_L1)\n> +\t\t\treturn true;\n> +\t\ttimeout--;\n> +\t\tusleep_range(500, 1000);\n> +\t} while (timeout);\n> +\n> +\treturn false;\n> +}\n> +\n> +static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)\n> +{\n> +\tstruct iproc_pcie *pcie = data;\n\n struct device *dev = pcie->dev;\n\nThen you don't have to repeat \"pcie->dev\" below.\n\n> +\tstruct pci_bus *bus = pcie->root_bus, *child;\n> +\tbool link_status;\n> +\n> +\tiproc_pcie_perst_ctrl(pcie, true);\n> +\tiproc_pcie_perst_ctrl(pcie, false);\n> +\n> +\tlink_status = iproc_pci_hp_check_ltssm(pcie);\n> +\n> +\tif (link_status &&\n> +\t !iproc_pcie_check_link(pcie) &&\n\niproc_pcie_check_link() already exists, but is still a poor name.\n\nPlease add some preliminary patches to rename and restructure it along\nthe lines of the other *_link_up() functions, e.g.,\nadvk_pcie_link_up(), nwl_pcie_link_up(), spear13xx_pcie_link_up(),\netc.\n\niproc_pcie_check_link() does a bunch of other stuff that should be\nmoved to other functions. Some of it looks similar to the\n*_establish_link() functions in other drivers.\n\n> +\t !pcie->ep_is_present) {\n> +\t\tpci_rescan_bus(bus);\n> +\t\tlist_for_each_entry(child, &bus->children, node)\n> +\t\t\tpcie_bus_configure_settings(child);\n> +\t\tpcie->ep_is_present = true;\n> +\t\tdev_info(pcie->dev,\n> +\t\t\t \"PCI Hotplug: \\n\");\n> +\t} else if (link_status && pcie->ep_is_present)\n> +\t\t/*\n> +\t\t * ep_is_present makes sure, enumuration done only once.\n\ns/enumuration/enumeration/\n\n> +\t\t * So it can handle spurious intrrupts, and also if we\n\ns/intrrupts/interrupts/\n\n> +\t\t * get multiple interrupts for all the implemented pins,\n> +\t\t * we handle it only once.\n> +\t\t */\n> +\t\tdev_info(pcie->dev,\n> +\t\t\t \"PCI Hotplug: \\n\");\n> +\telse {\n> +\t\tiproc_pcie_perst_ctrl(pcie, true);\n> +\t\tpcie->ep_is_present = false;\n> +\t\tdev_info(pcie->dev,\n> +\t\t\t \"PCI Hotplug: \\n\");\n> +\t}\n> +\treturn IRQ_HANDLED;\n> +}\n> +\n> +static int iproc_pci_hp_gpio_irq_get(struct iproc_pcie *pcie)\n> +{\n> +\tstruct gpio_descs *hp_gpiod;\n> +\tstruct device *dev = pcie->dev;\n> +\tint i;\n> +\n> +\thp_gpiod = devm_gpiod_get_array(dev, \"prsnt\", GPIOD_IN);\n> +\tif (PTR_ERR(hp_gpiod) == -EPROBE_DEFER)\n> +\t\treturn -EPROBE_DEFER;\n> +\n> +\tif (!IS_ERR(hp_gpiod) && (hp_gpiod->ndescs > 0)) {\n> +\t\tfor (i = 0; i < hp_gpiod->ndescs; ++i) {\n> +\t\t\tgpiod_direction_input(hp_gpiod->desc[i]);\n> +\t\t\tif (request_threaded_irq(gpiod_to_irq\n> +\t\t\t\t\t\t (hp_gpiod->desc[i]),\n> +\t\t\t\t\t\t NULL, iproc_pci_hotplug_thread,\n> +\t\t\t\t\t\t IRQF_TRIGGER_FALLING,\n> +\t\t\t\t\t\t \"PCI-hotplug\", pcie))\n> +\t\t\t\tdev_err(dev,\n> +\t\t\t\t\t\"PCI hotplug prsnt: request irq failed\\n\");\n> +\t\t\t}\n> +\t}\n> +\tpcie->ep_is_present = false;\n> +\n> +\treturn 0;\n> +}\n> +\n> int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n> {\n> \tstruct device *dev;\n> \tint ret;\n> \tvoid *sysdata;\n> -\tstruct pci_bus *child;\n> +\tstruct pci_bus *bus, *child;\n> \tstruct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);\n> +\tbool link_not_active;\n> \n> \tdev = pcie->dev;\n> \n> @@ -1386,6 +1492,12 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n> \t\tgoto err_exit_phy;\n> \t}\n> \n> +\tif (pcie->enable_hotplug) {\n> +\t\tret = iproc_pci_hp_gpio_irq_get(pcie);\n> +\t\tif (ret < 0)\n> +\t\t\treturn ret;\n> +\t}\n> +\n> \tiproc_pcie_perst_ctrl(pcie, true);\n> \tiproc_pcie_perst_ctrl(pcie, false);\n> \n> @@ -1408,8 +1520,16 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n> \tsysdata = pcie;\n> #endif\n> \n> -\tret = iproc_pcie_check_link(pcie);\n> -\tif (ret) {\n> +\tlink_not_active = iproc_pcie_check_link(pcie);\n> +\tif (link_not_active && pcie->enable_hotplug) {\n> +\t\t/*\n> +\t\t * When link is not active and PCI hotplug\n> +\t\t * is supported, do not turn off phy, let probe\n> +\t\t * go ahead.\n> +\t\t */\n> +\t\tdev_err(dev, \"no PCIe EP device detected\\n\");\n> +\t\tiproc_pcie_perst_ctrl(pcie, true);\n> +\t} else if (link_not_active) {\n> \t\tdev_err(dev, \"no PCIe EP device detected\\n\");\n> \t\tgoto err_power_off_phy;\n> \t}\n> @@ -1420,24 +1540,34 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n> \t\tif (iproc_pcie_msi_enable(pcie))\n> \t\t\tdev_info(dev, \"not using iProc MSI\\n\");\n> \n> -\tlist_splice_init(res, &host->windows);\n> -\thost->busnr = 0;\n> -\thost->dev.parent = dev;\n> -\thost->ops = &iproc_pcie_ops;\n> -\thost->sysdata = sysdata;\n> -\thost->map_irq = pcie->map_irq;\n> -\thost->swizzle_irq = pci_common_swizzle;\n> +\tif (!link_not_active) {\n\nDouble negation. If you pick a better name, e.g., \"link_active\", this\nwill read much better. But I don't understand why you want to check\nwhether the link is active here anyway. pci_scan_root_bus_bridge()\nshould work fine even if there's no device present below the bridge.\nWon't the root port be there always, even if there's no downstream\ndevice?\n\n> +\t\tlist_splice_init(res, &host->windows);\n> +\t\thost->busnr = 0;\n> +\t\thost->dev.parent = dev;\n> +\t\thost->ops = &iproc_pcie_ops;\n> +\t\thost->sysdata = sysdata;\n> +\t\thost->map_irq = pcie->map_irq;\n> +\t\thost->swizzle_irq = pci_common_swizzle;\n> +\n> +\t\tret = pci_scan_root_bus_bridge(host);\n> +\t\tif (ret < 0) {\n> +\t\t\tdev_err(dev, \"failed to scan host: %d\\n\", ret);\n> +\t\t\tgoto err_power_off_phy;\n> +\t\t}\n> \n> -\tret = pci_scan_root_bus_bridge(host);\n> -\tif (ret < 0) {\n> -\t\tdev_err(dev, \"failed to scan host: %d\\n\", ret);\n> -\t\tgoto err_power_off_phy;\n> +\t\tpci_assign_unassigned_bus_resources(host->bus);\n> +\t\tpcie->root_bus = host->bus;\n> +\t} else {\n> +\t\tbus = pci_create_root_bus(dev, 0,\n> +\t\t\t\t\t &iproc_pcie_ops, sysdata, res);\n> +\t\tif (!bus) {\n> +\t\t\tdev_err(dev, \"unable to create PCI root bus\\n\");\n> +\t\t\tret = -ENOMEM;\n> +\t\t\tgoto err_power_off_phy;\n> +\t\t}\n> +\t\tpcie->root_bus = bus;\n> \t}\n> \n> -\tpci_assign_unassigned_bus_resources(host->bus);\n> -\n> -\tpcie->root_bus = host->bus;\n> -\n> \tlist_for_each_entry(child, &host->bus->children, node)\n> \t\tpcie_bus_configure_settings(child);\n> \n> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h\n> index a6b55ce..e5d0cd4 100644\n> --- a/drivers/pci/host/pcie-iproc.h\n> +++ b/drivers/pci/host/pcie-iproc.h\n> @@ -77,6 +77,10 @@ struct iproc_pcie_ib {\n> * @ib: inbound mapping related parameters\n> * @ib_map: outbound mapping region related parameters\n> *\n> + * @enable_hotplug: indicates PCI hotplug feature is enabled\n> + * @ep_is_present: when PCIe hotplug is enabled, this flag is used to\n> + * indicate whether or not the endpoint device is present\n> + *\n> * @need_msi_steer: indicates additional configuration of the iProc PCIe\n> * controller is required to steer MSI writes to external interrupt controller\n> * @msi: MSI data\n> @@ -104,6 +108,9 @@ struct iproc_pcie {\n> \tstruct iproc_pcie_ib ib;\n> \tconst struct iproc_pcie_ib_map *ib_map;\n> \n> +\tbool enable_hotplug;\n> +\tbool ep_is_present;\n\nAre you suggesting that only an endpoint can be hotplugged? You can't\nhotplug a switch?\n\n> \tbool need_msi_steer;\n> \tstruct iproc_msi *msi;\n> };\n> -- \n> 1.9.1\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=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y7nfp61P8z9t41\n\tfor ;\n\tFri, 6 Oct 2017 22:37:06 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751917AbdJFLhF (ORCPT\n\t);\n\tFri, 6 Oct 2017 07:37:05 -0400","from mail.kernel.org ([198.145.29.99]:54936 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751557AbdJFLhE (ORCPT );\n\tFri, 6 Oct 2017 07:37:04 -0400","from localhost (unknown [69.71.4.159])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 4294521907;\n\tFri, 6 Oct 2017 11:37:03 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 4294521907","Date":"Fri, 6 Oct 2017 06:37:00 -0500","From":"Bjorn Helgaas ","To":"Oza Pawandeep ","Cc":"Bjorn Helgaas , Rob Herring ,\n\tMark Rutland , Ray Jui ,\n\tScott Branden ,\n\tJon Mason , \n\tbcm-kernel-feedback-list@broadcom.com,\n\tAndy Gospodarek ,\n\tlinux-pci@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tOza Pawandeep ","Subject":"Re: [PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support","Message-ID":"<20171006113700.GA25517@bhelgaas-glaptop.roam.corp.google.com>","References":"<1504155029-24729-1-git-send-email-oza.oza@broadcom.com>\n\t<1504155029-24729-4-git-send-email-oza.oza@broadcom.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1504155029-24729-4-git-send-email-oza.oza@broadcom.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1781695,"web_url":"http://patchwork.ozlabs.org/comment/1781695/","msgid":"","list_archive_url":null,"date":"2017-10-06T14:33:52","subject":"Re: [PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support","submitter":{"id":72267,"url":"http://patchwork.ozlabs.org/api/people/72267/","name":"Oza Pawandeep","email":"oza.pawandeep@gmail.com"},"content":"On Fri, Oct 6, 2017 at 5:07 PM, Bjorn Helgaas wrote:\n> On Thu, Aug 31, 2017 at 10:20:29AM +0530, Oza Pawandeep wrote:\n>> This patch implements PCI hotplug support for iproc family chipsets.\n>>\n>> iproc based SOC (e.g. Stingray) does not have hotplug controller\n>> integrated.\n>> Hence, standard PCI hotplug framework hooks can-not be used.\n>> e.g. controlled power up/down of slot.\n>>\n>> The mechanism, for e.g. Stingray has adopted for PCI hotplug is as follows:\n>> PCI present lines are input to GPIOs depending on the type of\n>> connector (x2, x4, x8).\n>>\n>> GPIO array needs to be present if hotplug is supported.\n>> HW implementation is SOC/Board specific, and also it depends on how\n>> add-in card is designed\n>> (e.g. how many present pins are implemented).\n>>\n>> If x8 card is connected, then it might be possible that all the\n>> 3 present pins could go low, or at least one pin goes low.\n>> If x4 card is connected, then it might be possible that 2 present\n>> pins go low, or at least one pin goes low.\n>>\n>> The implementation essentially takes care of following:\n>> > Initializing hotplug irq thread.\n>> > Detecting the endpoint device based on link state.\n>> > Handling PERST and detecting the plugged devices.\n>> > Ordered Hot plug-out, where User is expected\n>> to write 1 to /sys/bus/pci/devices//remove\n>> > Handling spurious interrupt\n>> > Handling multiple interrupts and makes sure that card is\n>> enumerated only once.\n>\n> I haven't forgotten this, but I am dragging my feet a little bit.\n> There is a standard way for hardware to support PCIe hotplug, and it's\n> hard enough to get the software for that right. I really, really\n> don't want to see a bunch of one-off implementations that sort of look\n> like standard hotplug but not really.\n>\n> I have a few trivial comments below but haven't really reviewed the\n> whole thing.\n>\n>> Signed-off-by: Oza Pawandeep \n>> Reviewed-by: Ray Jui \n>>\n>> diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c\n>> index a5073a9..6287a43 100644\n>> --- a/drivers/pci/host/pcie-iproc-platform.c\n>> +++ b/drivers/pci/host/pcie-iproc-platform.c\n>> @@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev)\n>> pcie->need_ob_cfg = true;\n>> }\n>>\n>> + if (of_property_read_bool(np, \"slot-pluggable\"))\n>> + pcie->enable_hotplug = true;\n>> +\n>> /* PHY use is optional */\n>> pcie->phy = devm_phy_get(dev, \"pcie-phy\");\n>> if (IS_ERR(pcie->phy)) {\n>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c\n>> index 8bd5e54..2b4d830 100644\n>> --- a/drivers/pci/host/pcie-iproc.c\n>> +++ b/drivers/pci/host/pcie-iproc.c\n>> @@ -28,6 +28,7 @@\n>> #include \n>> #include \n>> #include \n>> +#include \n>>\n>> #include \"pcie-iproc.h\"\n>>\n>> @@ -65,6 +66,17 @@\n>> #define PCIE_DL_ACTIVE_SHIFT 2\n>> #define PCIE_DL_ACTIVE BIT(PCIE_DL_ACTIVE_SHIFT)\n>>\n>> +#define CFG_RC_LTSSM 0x1cf8\n>> +#define CFG_RC_PHY_CTL 0x1804\n>> +#define CFG_RC_LTSSM_TIMEOUT 1000\n>> +#define CFG_RC_LTSSM_STATE_MASK 0xff\n>> +#define CFG_RC_LTSSM_STATE_L1 0x1\n>> +\n>> +#define CFG_RC_CLR_LTSSM_HIST_SHIFT 29\n>> +#define CFG_RC_CLR_LTSSM_HIST_MASK BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)\n>> +#define CFG_RC_CLR_RECOV_HIST_SHIFT 31\n>> +#define CFG_RC_CLR_RECOV_HIST_MASK BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)\n>> +\n>> #define APB_ERR_EN_SHIFT 0\n>> #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)\n>>\n>> @@ -1354,13 +1366,107 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)\n>> return 0;\n>> }\n>>\n>> +static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)\n>\n> *_check_*() is a terrible name for a function because it doesn't give\n> any hint about what a \"true\" return value means.\n>\n> This looks sort of like dw_pcie_wait_for_link() and\n> advk_pcie_wait_for_link(). Please use a name more like them and\n> structure the code more like them.\n>\n>> +{\n>> + struct pci_bus *bus = pcie->root_bus;\n>> + u32 val, timeout = CFG_RC_LTSSM_TIMEOUT;\n>> +\n>> + /* Clear LTSSM history. */\n>> + pci_bus_read_config_dword(pcie->root_bus, 0,\n>> + CFG_RC_PHY_CTL, &val);\n>> + pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,\n>> + val | CFG_RC_CLR_RECOV_HIST_MASK |\n>> + CFG_RC_CLR_LTSSM_HIST_MASK);\n>> + /* write back the origional value. */\n>\n> s/origional/original/\n>\n>> + pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);\n>> +\n>> + do {\n>> + pci_bus_read_config_dword(pcie->root_bus, 0,\n>> + CFG_RC_LTSSM, &val);\n>> + /* check link state to see if link moved to L1 state. */\n>> + if ((val & CFG_RC_LTSSM_STATE_MASK) ==\n>> + CFG_RC_LTSSM_STATE_L1)\n>> + return true;\n>> + timeout--;\n>> + usleep_range(500, 1000);\n>> + } while (timeout);\n>> +\n>> + return false;\n>> +}\n>> +\n>> +static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)\n>> +{\n>> + struct iproc_pcie *pcie = data;\n>\n> struct device *dev = pcie->dev;\n>\n> Then you don't have to repeat \"pcie->dev\" below.\n>\n>> + struct pci_bus *bus = pcie->root_bus, *child;\n>> + bool link_status;\n>> +\n>> + iproc_pcie_perst_ctrl(pcie, true);\n>> + iproc_pcie_perst_ctrl(pcie, false);\n>> +\n>> + link_status = iproc_pci_hp_check_ltssm(pcie);\n>> +\n>> + if (link_status &&\n>> + !iproc_pcie_check_link(pcie) &&\n>\n> iproc_pcie_check_link() already exists, but is still a poor name.\n>\n> Please add some preliminary patches to rename and restructure it along\n> the lines of the other *_link_up() functions, e.g.,\n> advk_pcie_link_up(), nwl_pcie_link_up(), spear13xx_pcie_link_up(),\n> etc.\n>\n> iproc_pcie_check_link() does a bunch of other stuff that should be\n> moved to other functions. Some of it looks similar to the\n> *_establish_link() functions in other drivers.\n>\n>> + !pcie->ep_is_present) {\n>> + pci_rescan_bus(bus);\n>> + list_for_each_entry(child, &bus->children, node)\n>> + pcie_bus_configure_settings(child);\n>> + pcie->ep_is_present = true;\n>> + dev_info(pcie->dev,\n>> + \"PCI Hotplug: \\n\");\n>> + } else if (link_status && pcie->ep_is_present)\n>> + /*\n>> + * ep_is_present makes sure, enumuration done only once.\n>\n> s/enumuration/enumeration/\n>\n>> + * So it can handle spurious intrrupts, and also if we\n>\n> s/intrrupts/interrupts/\n>\n>> + * get multiple interrupts for all the implemented pins,\n>> + * we handle it only once.\n>> + */\n>> + dev_info(pcie->dev,\n>> + \"PCI Hotplug: \\n\");\n>> + else {\n>> + iproc_pcie_perst_ctrl(pcie, true);\n>> + pcie->ep_is_present = false;\n>> + dev_info(pcie->dev,\n>> + \"PCI Hotplug: \\n\");\n>> + }\n>> + return IRQ_HANDLED;\n>> +}\n>> +\n>> +static int iproc_pci_hp_gpio_irq_get(struct iproc_pcie *pcie)\n>> +{\n>> + struct gpio_descs *hp_gpiod;\n>> + struct device *dev = pcie->dev;\n>> + int i;\n>> +\n>> + hp_gpiod = devm_gpiod_get_array(dev, \"prsnt\", GPIOD_IN);\n>> + if (PTR_ERR(hp_gpiod) == -EPROBE_DEFER)\n>> + return -EPROBE_DEFER;\n>> +\n>> + if (!IS_ERR(hp_gpiod) && (hp_gpiod->ndescs > 0)) {\n>> + for (i = 0; i < hp_gpiod->ndescs; ++i) {\n>> + gpiod_direction_input(hp_gpiod->desc[i]);\n>> + if (request_threaded_irq(gpiod_to_irq\n>> + (hp_gpiod->desc[i]),\n>> + NULL, iproc_pci_hotplug_thread,\n>> + IRQF_TRIGGER_FALLING,\n>> + \"PCI-hotplug\", pcie))\n>> + dev_err(dev,\n>> + \"PCI hotplug prsnt: request irq failed\\n\");\n>> + }\n>> + }\n>> + pcie->ep_is_present = false;\n>> +\n>> + return 0;\n>> +}\n>> +\n>> int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n>> {\n>> struct device *dev;\n>> int ret;\n>> void *sysdata;\n>> - struct pci_bus *child;\n>> + struct pci_bus *bus, *child;\n>> struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);\n>> + bool link_not_active;\n>>\n>> dev = pcie->dev;\n>>\n>> @@ -1386,6 +1492,12 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n>> goto err_exit_phy;\n>> }\n>>\n>> + if (pcie->enable_hotplug) {\n>> + ret = iproc_pci_hp_gpio_irq_get(pcie);\n>> + if (ret < 0)\n>> + return ret;\n>> + }\n>> +\n>> iproc_pcie_perst_ctrl(pcie, true);\n>> iproc_pcie_perst_ctrl(pcie, false);\n>>\n>> @@ -1408,8 +1520,16 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n>> sysdata = pcie;\n>> #endif\n>>\n>> - ret = iproc_pcie_check_link(pcie);\n>> - if (ret) {\n>> + link_not_active = iproc_pcie_check_link(pcie);\n>> + if (link_not_active && pcie->enable_hotplug) {\n>> + /*\n>> + * When link is not active and PCI hotplug\n>> + * is supported, do not turn off phy, let probe\n>> + * go ahead.\n>> + */\n>> + dev_err(dev, \"no PCIe EP device detected\\n\");\n>> + iproc_pcie_perst_ctrl(pcie, true);\n>> + } else if (link_not_active) {\n>> dev_err(dev, \"no PCIe EP device detected\\n\");\n>> goto err_power_off_phy;\n>> }\n>> @@ -1420,24 +1540,34 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)\n>> if (iproc_pcie_msi_enable(pcie))\n>> dev_info(dev, \"not using iProc MSI\\n\");\n>>\n>> - list_splice_init(res, &host->windows);\n>> - host->busnr = 0;\n>> - host->dev.parent = dev;\n>> - host->ops = &iproc_pcie_ops;\n>> - host->sysdata = sysdata;\n>> - host->map_irq = pcie->map_irq;\n>> - host->swizzle_irq = pci_common_swizzle;\n>> + if (!link_not_active) {\n>\n> Double negation. If you pick a better name, e.g., \"link_active\", this\n> will read much better. But I don't understand why you want to check\n> whether the link is active here anyway. pci_scan_root_bus_bridge()\n> should work fine even if there's no device present below the bridge.\n> Won't the root port be there always, even if there's no downstream\n> device?\n>\n\nwill change all the names and spellings as you are suggesting.\n\npci_scan_root_bus_bridge crashes when link is not active. when I last\ntested, that is what I observed.\n\nbecause in previous code when we dont support hotplug, we just got to\nerr, and remove root-bus in case link is not active.\nwe dont do scan bus.\n\nif fact so far none of the RC driver implements hotplug so this might\nnot have been exercised.\n\nRay and Vikram: please help to see these comments implemented.\n\n\n>> + list_splice_init(res, &host->windows);\n>> + host->busnr = 0;\n>> + host->dev.parent = dev;\n>> + host->ops = &iproc_pcie_ops;\n>> + host->sysdata = sysdata;\n>> + host->map_irq = pcie->map_irq;\n>> + host->swizzle_irq = pci_common_swizzle;\n>> +\n>> + ret = pci_scan_root_bus_bridge(host);\n>> + if (ret < 0) {\n>> + dev_err(dev, \"failed to scan host: %d\\n\", ret);\n>> + goto err_power_off_phy;\n>> + }\n>>\n>> - ret = pci_scan_root_bus_bridge(host);\n>> - if (ret < 0) {\n>> - dev_err(dev, \"failed to scan host: %d\\n\", ret);\n>> - goto err_power_off_phy;\n>> + pci_assign_unassigned_bus_resources(host->bus);\n>> + pcie->root_bus = host->bus;\n>> + } else {\n>> + bus = pci_create_root_bus(dev, 0,\n>> + &iproc_pcie_ops, sysdata, res);\n>> + if (!bus) {\n>> + dev_err(dev, \"unable to create PCI root bus\\n\");\n>> + ret = -ENOMEM;\n>> + goto err_power_off_phy;\n>> + }\n>> + pcie->root_bus = bus;\n>> }\n>>\n>> - pci_assign_unassigned_bus_resources(host->bus);\n>> -\n>> - pcie->root_bus = host->bus;\n>> -\n>> list_for_each_entry(child, &host->bus->children, node)\n>> pcie_bus_configure_settings(child);\n>>\n>> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h\n>> index a6b55ce..e5d0cd4 100644\n>> --- a/drivers/pci/host/pcie-iproc.h\n>> +++ b/drivers/pci/host/pcie-iproc.h\n>> @@ -77,6 +77,10 @@ struct iproc_pcie_ib {\n>> * @ib: inbound mapping related parameters\n>> * @ib_map: outbound mapping region related parameters\n>> *\n>> + * @enable_hotplug: indicates PCI hotplug feature is enabled\n>> + * @ep_is_present: when PCIe hotplug is enabled, this flag is used to\n>> + * indicate whether or not the endpoint device is present\n>> + *\n>> * @need_msi_steer: indicates additional configuration of the iProc PCIe\n>> * controller is required to steer MSI writes to external interrupt controller\n>> * @msi: MSI data\n>> @@ -104,6 +108,9 @@ struct iproc_pcie {\n>> struct iproc_pcie_ib ib;\n>> const struct iproc_pcie_ib_map *ib_map;\n>>\n>> + bool enable_hotplug;\n>> + bool ep_is_present;\n>\n> Are you suggesting that only an endpoint can be hotplugged? You can't\n> hotplug a switch?\n>\n\nok, we can change the name, PCI switch also can be hot-plugged.\n\n>> bool need_msi_steer;\n>> struct iproc_msi *msi;\n>> };\n>> --\n>> 1.9.1\n>>\n\nRegards,\nOza.\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\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"jaF7RUO3\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y7sZs0szHz9t2m\n\tfor ;\n\tSat, 7 Oct 2017 01:33:57 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751659AbdJFOdz (ORCPT\n\t);\n\tFri, 6 Oct 2017 10:33:55 -0400","from mail-oi0-f65.google.com ([209.85.218.65]:50181 \"EHLO\n\tmail-oi0-f65.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751487AbdJFOdy (ORCPT\n\t); Fri, 6 Oct 2017 10:33:54 -0400","by mail-oi0-f65.google.com with SMTP id q4so12353126oic.7;\n\tFri, 06 Oct 2017 07:33:53 -0700 (PDT)","by 10.157.34.225 with HTTP; Fri, 6 Oct 2017 07:33:52 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=GTuQ+UL89fqH4lcNVexiWcec8EvB0CmlN3PClNJ0QKQ=;\n\tb=jaF7RUO39HGHJMyVvArDgTZywEU3t17SUF4dBX3hdPRJEvQSPoWZleIqfNcWSMICnc\n\tXu+xp9PAJmXB5ZwrrODJkzgUBxfTGq45tMWpdvOdvOIskI3tQnPcZdeSCR+Xha7tM8uz\n\tcVPgPIuDhJ4aN1Sz+zXbsCqQO2eOQZbA7FYx4+dbZCnVRXiWnGVcGWMdQN7UFPBVYl7V\n\tNDQePoRbGwccE4AjLIj+tnMXTgU1b5DBbIF9rdMr22Ynjai9z3ID5inpalpgguq4weh7\n\tZ9H3uX+XB/mam4n1xtrnUthfQ3XlpwmXzxW0nKUY6hpZsKDshfwMxTJxaJ/v1HCKMWBr\n\t7Slw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=GTuQ+UL89fqH4lcNVexiWcec8EvB0CmlN3PClNJ0QKQ=;\n\tb=WTCgmzevVYI192PhYh2V4sTNtKW17M2RHSuFydstMi1aK6wRoBgQfwiH9jGrQ8n8Gr\n\tpQbDWJPVwhjCSFx2ETZ4GXryJ45FH12gzQ/fnWPuYABxq8G7Bh4G7crEAoaQOxfgkwl/\n\tq04X2DtVUGUWR5AUXMiGUsirWaz+VseoN7S7Ho15tFsvyRCh6Mva4g/xWJ7fAWXXuBDz\n\t/ClqQrZBTi/6MFqMDwP8rfOTCWed10l11vwGT7xZqbmHZhFAfKBo0SN58XGs/8In8ILl\n\twW8uP14qjb1w4NygHmAUJ/+qZNGiA220qVLF9Qg7j0/bqpxCLdT3Ln0aia6NKE5bTF4z\n\t/6vg==","X-Gm-Message-State":"AMCzsaXsbCOefAmKeOH0J12SfhkjuenjZqrr7OcFikHgT3d8NaqSQ5A6\n\tL3o3NhiXFSJu98/0XlSAK8aRVBrFfO5clwB5K9s=","X-Google-Smtp-Source":"AOwi7QBg7Ae/ClERIesREhXZAVhnhI1t/pb5vHpCDYtrhNvOHUMUUKH9NDYZbG44Irzw2OptjQWlW1QYodgxRozVuuk=","X-Received":"by 10.202.182.5 with SMTP id g5mr1030717oif.184.1507300432833;\n\tFri, 06 Oct 2017 07:33:52 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171006113700.GA25517@bhelgaas-glaptop.roam.corp.google.com>","References":"<1504155029-24729-1-git-send-email-oza.oza@broadcom.com>\n\t<1504155029-24729-4-git-send-email-oza.oza@broadcom.com>\n\t<20171006113700.GA25517@bhelgaas-glaptop.roam.corp.google.com>","From":"Oza Pawandeep ","Date":"Fri, 6 Oct 2017 20:03:52 +0530","Message-ID":"","Subject":"Re: [PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support","To":"Bjorn Helgaas ","Cc":"Oza Pawandeep , Bjorn Helgaas ,\n\tRob Herring , Mark Rutland ,\n\tRay Jui , Scott Branden ,\n\tJon Mason ,\n\tbcm-kernel-feedback-list@broadcom.com, \n\tAndy Gospodarek ,\n\tlinux-pci@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tVikram Prakash ","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":1781761,"web_url":"http://patchwork.ozlabs.org/comment/1781761/","msgid":"<20171006160206.GB25517@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-10-06T16:02:06","subject":"Re: [PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Fri, Oct 06, 2017 at 08:03:52PM +0530, Oza Pawandeep wrote:\n> On Fri, Oct 6, 2017 at 5:07 PM, Bjorn Helgaas wrote:\n> > On Thu, Aug 31, 2017 at 10:20:29AM +0530, Oza Pawandeep wrote:\n> >> This patch implements PCI hotplug support for iproc family chipsets.\n> >>\n> >> iproc based SOC (e.g. Stingray) does not have hotplug controller\n> >> integrated.\n> >> Hence, standard PCI hotplug framework hooks can-not be used.\n> >> e.g. controlled power up/down of slot.\n> >>\n> >> The mechanism, for e.g. Stingray has adopted for PCI hotplug is as follows:\n> >> PCI present lines are input to GPIOs depending on the type of\n> >> connector (x2, x4, x8).\n> >>\n> >> GPIO array needs to be present if hotplug is supported.\n> >> HW implementation is SOC/Board specific, and also it depends on how\n> >> add-in card is designed\n> >> (e.g. how many present pins are implemented).\n> >>\n> >> If x8 card is connected, then it might be possible that all the\n> >> 3 present pins could go low, or at least one pin goes low.\n> >> If x4 card is connected, then it might be possible that 2 present\n> >> pins go low, or at least one pin goes low.\n> >>\n> >> The implementation essentially takes care of following:\n> >> > Initializing hotplug irq thread.\n> >> > Detecting the endpoint device based on link state.\n> >> > Handling PERST and detecting the plugged devices.\n> >> > Ordered Hot plug-out, where User is expected\n> >> to write 1 to /sys/bus/pci/devices//remove\n> >> > Handling spurious interrupt\n> >> > Handling multiple interrupts and makes sure that card is\n> >> enumerated only once.\n> >\n> > I haven't forgotten this, but I am dragging my feet a little bit.\n> > There is a standard way for hardware to support PCIe hotplug, and it's\n> > hard enough to get the software for that right. I really, really\n> > don't want to see a bunch of one-off implementations that sort of look\n> > like standard hotplug but not really.\n> >\n> > I have a few trivial comments below but haven't really reviewed the\n> > whole thing.\n> ...\n\n> >> - list_splice_init(res, &host->windows);\n> >> - host->busnr = 0;\n> >> - host->dev.parent = dev;\n> >> - host->ops = &iproc_pcie_ops;\n> >> - host->sysdata = sysdata;\n> >> - host->map_irq = pcie->map_irq;\n> >> - host->swizzle_irq = pci_common_swizzle;\n> >> + if (!link_not_active) {\n> >\n> > Double negation. If you pick a better name, e.g., \"link_active\", this\n> > will read much better. But I don't understand why you want to check\n> > whether the link is active here anyway. pci_scan_root_bus_bridge()\n> > should work fine even if there's no device present below the bridge.\n> > Won't the root port be there always, even if there's no downstream\n> > device?\n> ...\n> \n> pci_scan_root_bus_bridge crashes when link is not active. when I last\n> tested, that is what I observed.\n\nI think that would mean a bug in your config accessors. The PCI core\nenumeration itself doesn't depend on the link being up. But I don't\nsee anything obvious in your accessors that looks like an issue.\n\nIf you post details about the crash, maybe we can help figure it out.\n\n> because in previous code when we dont support hotplug, we just got to\n> err, and remove root-bus in case link is not active.\n> we dont do scan bus.\n> \n> if fact so far none of the RC driver implements hotplug so this might\n> not have been exercised.\n\nIf the RC implements PCIe hotplug correctly, the RC driver shouldn't\nneed to do anything special to support hotplug. It should just work.\nThat's why I'm so reluctant to merge stuff like this. Your hardware\nfolks are making work for themselves by designing a new scheme, and\nthat makes work for software folks to support it. None of that should\nbe necessary.\n\n> ...\n> >> @@ -104,6 +108,9 @@ struct iproc_pcie {\n> >> struct iproc_pcie_ib ib;\n> >> const struct iproc_pcie_ib_map *ib_map;\n> >>\n> >> + bool enable_hotplug;\n> >> + bool ep_is_present;\n> >\n> > Are you suggesting that only an endpoint can be hotplugged? You can't\n> > hotplug a switch?\n> >\n> \n> ok, we can change the name, PCI switch also can be hot-plugged.\n\nI'm dubious about the need for such a variable in the first place.\nIt's always going to be unreliable because you might test it after a\ndevice has been hotplugged but before the variable has been updated.\n\nBjorn\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=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y7vXs6T7bz9t41\n\tfor ;\n\tSat, 7 Oct 2017 03:02:21 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751515AbdJFQCU (ORCPT\n\t);\n\tFri, 6 Oct 2017 12:02:20 -0400","from mail.kernel.org ([198.145.29.99]:49794 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751487AbdJFQCT (ORCPT );\n\tFri, 6 Oct 2017 12:02:19 -0400","from localhost (173-24-246-249.client.mchsi.com [173.24.246.249])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 1EF9F217C5;\n\tFri, 6 Oct 2017 16:02:16 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 1EF9F217C5","Date":"Fri, 6 Oct 2017 11:02:06 -0500","From":"Bjorn Helgaas ","To":"Oza Pawandeep ","Cc":"Oza Pawandeep , Bjorn Helgaas ,\n\tRob Herring , Mark Rutland ,\n\tRay Jui , Scott Branden ,\n\tJon Mason ,\n\tbcm-kernel-feedback-list@broadcom.com, \n\tAndy Gospodarek ,\n\tlinux-pci@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tVikram Prakash ","Subject":"Re: [PATCH v6 3/3] PCI: iproc: Implement PCI hotplug support","Message-ID":"<20171006160206.GB25517@bhelgaas-glaptop.roam.corp.google.com>","References":"<1504155029-24729-1-git-send-email-oza.oza@broadcom.com>\n\t<1504155029-24729-4-git-send-email-oza.oza@broadcom.com>\n\t<20171006113700.GA25517@bhelgaas-glaptop.roam.corp.google.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]