From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 991DAC43331 for ; Thu, 26 Mar 2020 14:37:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 72655206F8 for ; Thu, 26 Mar 2020 14:37:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Hj+GXptt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727901AbgCZOhY (ORCPT ); Thu, 26 Mar 2020 10:37:24 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:33179 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726270AbgCZOhY (ORCPT ); Thu, 26 Mar 2020 10:37:24 -0400 Received: by mail-pf1-f196.google.com with SMTP id j1so2880714pfe.0; Thu, 26 Mar 2020 07:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xcJ9A36qE7fmwILM0GIjQcoBryZ8cQtpU3R/gSX0bfw=; b=Hj+GXpttQEF8xznQ2rVTuxma2i7jZmuN8GRAQn6sIWhgC4o4xDnW7wFusMuV8o2LbI bay9pVfypJf/YhGlOzXqqT5xjCRnkIuIUkIZnegDauwEobqVXXbuuS6POybxMyvZl4be ScLmbSsGBuJNWfiM60rxOUXURna7W/yXDmnthc8oqsqvzSiMWXGv5fUcrpvpz4bC+Oev oLhZEwB8u4qNCz/t8D0bfjrMv3fhzNvzjiAwry9NZO8dtYlB/srOL0h6f9GJB6O/d1jZ 3OQ77yfP4NQ6Z7AlwktCS3ZTyeQpDKHnMBqewIgpL00cuSh78Ut0k9iYl0hOdolwR6P2 xZdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xcJ9A36qE7fmwILM0GIjQcoBryZ8cQtpU3R/gSX0bfw=; b=d88pJOOfcCfvIuQNqp/3JuPV7vJgkxEzbvtJ9fiWMi9bPBYybTN47l2P3+/pgMrysG zjTMdhCDb/NT12iwadTOzoOYqwYQud4fipuyViRIfxYcDawBTEkrWsWlnEeQS2631glb MbG63iaTt4VU38zwI2FUxasN/fTYW1S6uL7elyIYrrkRN3vW/3/xNhT4yulqdvgQMPjb PNpP/aK1dqqCE7lgr7+yj6zC+ztuV49ZYtY614iabZjqxcbo75q9zYRnICYpBql94FH5 erVjcb1Pouh+L2rcDGUJvf4RoXQyppUZLSxUdpiO2+X8Yqeru82RmG/rXWcPKNOQX0k6 XGtw== X-Gm-Message-State: ANhLgQ2lfDYYciacU0YJ+6y+kB6FOCeBhlSGA8/2PakTCiWnhBvfF1ca ROBa9h41SKXd9K9tlm6n8GiOAHdmIlcfHALUxwM= X-Google-Smtp-Source: ADFU+vsONeD2TN2CDHUgnVhWVwIcnrhd9OmNhte1Zfml9aKMC9gE+W9zgd27TYvKJYDgdxOIM0foGkFZx1J2fO3yIo0= X-Received: by 2002:aa7:8149:: with SMTP id d9mr9058526pfn.170.1585233442792; Thu, 26 Mar 2020 07:37:22 -0700 (PDT) MIME-Version: 1.0 References: <1585205326-25326-1-git-send-email-srinath.mannam@broadcom.com> <1585205326-25326-3-git-send-email-srinath.mannam@broadcom.com> In-Reply-To: <1585205326-25326-3-git-send-email-srinath.mannam@broadcom.com> From: Andy Shevchenko Date: Thu, 26 Mar 2020 16:37:15 +0200 Message-ID: Subject: Re: [PATCH v5 2/6] PCI: iproc: Add INTx support with better modeling To: Srinath Mannam Cc: Lorenzo Pieralisi , Bjorn Helgaas , Florian Fainelli , Ray Jui , Rob Herring , Andrew Murray , Mark Rutland , Arnd Bergmann , bcm-kernel-feedback-list , linux-pci@vger.kernel.org, devicetree , linux-arm Mailing List , Linux Kernel Mailing List , Ray Jui Content-Type: text/plain; charset="UTF-8" Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Mar 26, 2020 at 8:49 AM Srinath Mannam wrote: > > From: Ray Jui > > Add PCIe legacy interrupt INTx support to the iProc PCIe driver by > modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC, > INTD share the same interrupt line connected to the GIC in the system, > while the status of each INTx can be obtained through the INTX CSR > register. ... > + val &= ~(BIT(irqd_to_hwirq(d))); Too many parentheses. ... > + val |= (BIT(irqd_to_hwirq(d))); Ditto. ... > + /* go through INTx A, B, C, D until all interrupts are handled */ > + do { > + status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR); > + for_each_set_bit(bit, &status, PCI_NUM_INTX) { > + virq = irq_find_mapping(pcie->irq_domain, bit); > + if (virq) > + generic_handle_irq(virq); > + else > + dev_err(dev, "unexpected INTx%u\n", bit); Any guarantee it will be no storm of undesired messages here? > + } > + } while ((status & SYS_RC_INTX_MASK) != 0); ' != 0' part is not needed. If there an interrupt storm the handler will never end, right? Is it the idea by design? ... > + node = of_get_compatible_child(dev->of_node, "brcm,iproc-intc"); > + if (node) > + pcie->irq = of_irq_get(node, 0); > + > + if (!node || pcie->irq <= 0) > + return 0; Perhaps node = of_get_compatible_child(dev->of_node, "brcm,iproc-intc"); if (!node) return 0; pcie->irq = of_irq_get(node, 0); if (pcie->irq <= 0) return 0; ? -- With Best Regards, Andy Shevchenko