Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp194686pxu; Thu, 7 Jan 2021 02:19:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJxSgrOzVALHmG7XKBX3PeRk2dW80LTTZ8BX9mUJ4nUGyAUHJPV9aGRiKTrJMNJLS3V3kQJn X-Received: by 2002:a50:d5d5:: with SMTP id g21mr1222647edj.41.1610014784045; Thu, 07 Jan 2021 02:19:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610014784; cv=none; d=google.com; s=arc-20160816; b=b9g3hk/BhsyCuR9GBiwNwpsq7OoeneiinyF0lrV8UbEdALfny+PUdfIwsQQGsqzpuh BmbK7J4mgD47RUxMrX/qwz3mYO6yp+zynua05+OyQlDUM+XvZ8Nb1esENLDTH3kJSgjJ bE6cih12gxgiEjEgwlYtylfRSQgCcjOHXjY7JKnB5xgI8vdDnhgwhboOOtH6thZzeize 76AQrhdHlR8zVJr1gMcUO20rG86Rwgf157TcQqXS/zM15sR75z44Fm89lXPj/kuyPl3H lz9/qON2lP7ekXSFcglsANQDmZMtrTSaSQ5UyEYISsZV5sncr4IZ8MggUU+FJwWr5VmY 5y3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version; bh=RC6dhcGRdbtsP0o143w0Z6JrBdwCwiE7kjq7KUgWQmY=; b=sZAYQtnp1ecG7555aU9iotGL3ALCAkSo7vg3sYpP1KfzrKbinmd+LO3Spl3VhnCMyM mLrgqTf6Jxz4DRHRJQm3aZfz5DN6PSZEMYXlEx7MYdEoWuWD/yOSPpAlIZmQccLZxiDZ XsG9ZbH4CZJApvAPtNsS73hJ+uvT1exv+/Oxz9G+T9Vy0q+8EsFP3oGnbVf4my47n4QU UxQbXfnZDIXOR6xl1AYtFni3Uv1D8B8pgPnR8mZ9d77oN9U2+/mYts9++4HVW52ikktE 4DUP46nEeGHEqjglrAbVaAys0Wp3ufzyeEcXcvkinV+L6c71Y0dcI2jvL9Qr6j9z7wgG 0Qgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m26si2174153ejn.304.2021.01.07.02.19.19; Thu, 07 Jan 2021 02:19:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727459AbhAGKSV (ORCPT + 99 others); Thu, 7 Jan 2021 05:18:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:54198 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbhAGKSV (ORCPT ); Thu, 7 Jan 2021 05:18:21 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 36E2023138; Thu, 7 Jan 2021 10:17:40 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kxSML-005oKv-V9; Thu, 07 Jan 2021 10:17:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Jan 2021 10:17:37 +0000 From: Marc Zyngier To: ChiaWei Wang Cc: robh+dt@kernel.org, joel@jms.id.au, andrew@aj.id.au, tglx@linutronix.de, p.zabel@pengutronix.de, linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, BMC-SW Subject: Re: [PATCH 4/6] irqchip/aspeed: Add Aspeed eSPI interrupt controller In-Reply-To: References: <20210106055939.19386-1-chiawei_wang@aspeedtech.com> <20210106055939.19386-5-chiawei_wang@aspeedtech.com> <123bc25c72b3b17c0c4154d8bd8ce3b0@kernel.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: chiawei_wang@aspeedtech.com, robh+dt@kernel.org, joel@jms.id.au, andrew@aj.id.au, tglx@linutronix.de, p.zabel@pengutronix.de, linux-aspeed@lists.ozlabs.org, openbmc@lists.ozlabs.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, BMC-SW@aspeedtech.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-01-07 02:59, ChiaWei Wang wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Zyngier >> Sent: Wednesday, January 6, 2021 6:59 PM >> To: ChiaWei Wang >> Subject: Re: [PATCH 4/6] irqchip/aspeed: Add Aspeed eSPI interrupt >> controller >> >> On 2021-01-06 05:59, Chia-Wei, Wang wrote: >> > The eSPI interrupt controller acts as a SW IRQ number decoder to >> > correctly control/dispatch interrupts of the eSPI peripheral, virtual >> > wire, out-of-band, and flash channels. >> > >> > Signed-off-by: Chia-Wei, Wang >> > --- >> > drivers/irqchip/Makefile | 2 +- >> > drivers/irqchip/irq-aspeed-espi-ic.c | 251 ++++++++++++++++++++++++ >> > include/soc/aspeed/espi.h | 279 >> +++++++++++++++++++++++++++ >> > 3 files changed, 531 insertions(+), 1 deletion(-) create mode 100644 >> > drivers/irqchip/irq-aspeed-espi-ic.c >> > create mode 100644 include/soc/aspeed/espi.h >> > >> > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index >> > 0ac93bfaec61..56da4a3123f8 100644 >> > --- a/drivers/irqchip/Makefile >> > +++ b/drivers/irqchip/Makefile >> > @@ -86,7 +86,7 @@ obj-$(CONFIG_MVEBU_PIC) += >> irq-mvebu-pic.o >> > obj-$(CONFIG_MVEBU_SEI) += irq-mvebu-sei.o >> > obj-$(CONFIG_LS_EXTIRQ) += irq-ls-extirq.o >> > obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o >> > -obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o >> > irq-aspeed-scu-ic.o >> > +obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o >> > irq-aspeed-scu-ic.o irq-aspeed-espi-ic.o >> > obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o >> > obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o >> > obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o >> > diff --git a/drivers/irqchip/irq-aspeed-espi-ic.c >> > b/drivers/irqchip/irq-aspeed-espi-ic.c >> > new file mode 100644 >> > index 000000000000..8a5cc8fe3f0c >> > --- /dev/null >> > +++ b/drivers/irqchip/irq-aspeed-espi-ic.c >> > @@ -0,0 +1,251 @@ >> > +// SPDX-License-Identifier: GPL-2.0-or-later >> > +/* >> > + * Copyright (c) 2020 Aspeed Technology Inc. >> > + */ >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include #include >> > +#include #include #include >> > + #include #include >> > + >> > +#include >> > +#include >> > + >> > +#define DEVICE_NAME "aspeed-espi-ic" >> > +#define IRQCHIP_NAME "eSPI-IC" >> > + >> > +#define ESPI_IC_IRQ_NUM 7 >> > + >> > +struct aspeed_espi_ic { >> > + struct regmap *map; >> > + int irq; >> > + int gpio_irq; >> > + struct irq_domain *irq_domain; >> > +}; >> > + >> > +static void aspeed_espi_ic_gpio_isr(struct irq_desc *desc) { >> > + unsigned int irq; >> > + struct aspeed_espi_ic *espi_ic = irq_desc_get_handler_data(desc); >> > + struct irq_chip *chip = irq_desc_get_chip(desc); >> > + >> > + chained_irq_enter(chip, desc); >> > + >> > + irq = irq_find_mapping(espi_ic->irq_domain, >> > + ASPEED_ESPI_IC_CTRL_RESET); >> > + generic_handle_irq(irq); >> > + >> > + irq = irq_find_mapping(espi_ic->irq_domain, >> > + ASPEED_ESPI_IC_CHAN_RESET); >> > + generic_handle_irq(irq); >> >> So for each mux interrupt, you generate two endpoints interrupt, >> without even >> checking whether they are pending? That's no good. > > As the eSPI IC driver is chained to Aspeed GPIO IC, the pending is > checked in the gpio-aspeed.c That's not the place to do that. > >> > + >> > + chained_irq_exit(chip, desc); >> > +} >> > + >> > +static void aspeed_espi_ic_isr(struct irq_desc *desc) { >> > + unsigned int sts; >> > + unsigned int irq; >> > + struct aspeed_espi_ic *espi_ic = irq_desc_get_handler_data(desc); >> > + struct irq_chip *chip = irq_desc_get_chip(desc); >> > + >> > + chained_irq_enter(chip, desc); >> > + >> > + regmap_read(espi_ic->map, ESPI_INT_STS, &sts); >> > + >> > + if (sts & ESPI_INT_STS_PERIF_BITS) { >> > + irq = irq_find_mapping(espi_ic->irq_domain, >> > + ASPEED_ESPI_IC_PERIF_EVENT); >> > + generic_handle_irq(irq); >> > + } >> > + >> > + if (sts & ESPI_INT_STS_VW_BITS) { >> > + irq = irq_find_mapping(espi_ic->irq_domain, >> > + ASPEED_ESPI_IC_VW_EVENT); >> > + generic_handle_irq(irq); >> > + } >> > + >> > + if (sts & ESPI_INT_STS_OOB_BITS) { >> > + irq = irq_find_mapping(espi_ic->irq_domain, >> > + ASPEED_ESPI_IC_OOB_EVENT); >> > + generic_handle_irq(irq); >> > + } >> > + >> > + if (sts & ESPI_INT_STS_FLASH_BITS) { >> > + irq = irq_find_mapping(espi_ic->irq_domain, >> > + ASPEED_ESPI_IC_FLASH_EVENT); >> > + generic_handle_irq(irq); >> > + } >> > + >> > + if (sts & ESPI_INT_STS_HW_RST_DEASSERT) { >> > + irq = irq_find_mapping(espi_ic->irq_domain, >> > + ASPEED_ESPI_IC_CTRL_EVENT); >> > + generic_handle_irq(irq); >> > + } >> >> This is horrible. Why can't you just use fls() in a loop? > > The bits in the interrupt status register for a eSPI channel are not > sequentially arranged. > Using fls() may invoke an eSPI channel ISR multiple times. > So I collected the bitmap for each channel, respectively, and call the > ISR at once. And that's equally wrong. You need to handle interrupts individually, as they are different signal. If you are to implement an interrupt controller, please do it properly. Otherwise, get rid of it and move everything into your pet driver. There is no need to do a half-baked job. As it is, there is no way this code can be merged. M. -- Jazz is not dead. It just smells funny...