Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp5934045rwb; Tue, 9 Aug 2022 06:37:05 -0700 (PDT) X-Google-Smtp-Source: AA6agR5Y5Be1QN245Dgs6HgD7RkgPTtCAMiGItp5c8ji4sR2aabzkUvSa63zrg+dUPhWH1gRhGmP X-Received: by 2002:a17:902:f30c:b0:16d:a79c:4aed with SMTP id c12-20020a170902f30c00b0016da79c4aedmr23135215ple.23.1660052224830; Tue, 09 Aug 2022 06:37:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660052224; cv=none; d=google.com; s=arc-20160816; b=FjRY88SZ8QMdAz/TMBhJUcwT+nEJWHkg4TAjFSrAv2FlvT3ANPE412Gd6EMpSOM88r D4g/idI42yd+Zps01Q3g5F6MV+u9hYhP4Ev86BaUFNrq6L6EWX3YCdm9HDDL4JTOQOXh 1Lalg9yBnoMQ+ULWU93ybASxMOeTVgGF0mWBbrxDBtdmyUilxwAR8SuLZuZRLl6QiRcI e4NuYWWfGK1M0YxLfjOReRY7zyLagyOlc3DnuudS8iZ5dpqCJ+pKcL6brTwMoIVKaPVQ 2la1aS2yWyjZPfhPz2QfIvyHolSvtJCkjGRSOCb4VidJcutgJMxHfAthTw5pvLjvRicG 16CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=iB1ewUYpKoVTJL+hOV6cdlpMktAqDeL0116S3jbhsag=; b=GLGQpL7H6ZCNuC1VW0wF4T61j31XKF2khv+M7RO/NJAU9DmNsz0H3xGhyeqnfQ1blj yg38hgmhvIULnq+QrebivMvDmJGqNFEQqVQ/tgO4wsUlFrMbpkwOoeRToY36a6KwD0i/ 85wpwqcCz4vBYeRPZ5A8roTpO/XRl7DFY5TM3vTU2cKB1HH01mDEK5IHu+CxAamIfcNB cZfEl5gFkaOBBdEZV4rBmBzepsIXu7uaxEHZ6ogd/qjzBKfK6hc+j/FQStfXqdkKFCwu Y+f469xmspCM8mT40Nke4+anW9yjt8dDzOUFsRHJLVzEGs3HWDpO2FNSlzuwluczgrZR IRdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mJO8g7rH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f15-20020a170902ce8f00b0016da4f41949si14748321plg.550.2022.08.09.06.36.50; Tue, 09 Aug 2022 06:37:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mJO8g7rH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S243275AbiHIMxa (ORCPT + 99 others); Tue, 9 Aug 2022 08:53:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237532AbiHIMx1 (ORCPT ); Tue, 9 Aug 2022 08:53:27 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BEC786384; Tue, 9 Aug 2022 05:53:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7EB7DB811E1; Tue, 9 Aug 2022 12:53:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30CD5C433D6; Tue, 9 Aug 2022 12:53:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660049604; bh=LLqG7+H14IiitLd96VdM9H7iLrjRXtZ3HcvgVfZR0Vc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mJO8g7rHDTdQKg0wezno75dagw+hr4oNbhz4R9+5LNmLqLo4os38nvxomTbxZo4zl ZMlFop2cKLUY/TcCbDdEPVq9rju+5iNPOzeHpfqQKbuA32RiCeilaSd9xH0P9xUm+9 w1G1/yjlCdA4WLUiiojV4u+Qkvu1sotmbkCKdl3kRn6jgzpJ4cF21Vdh8VOrcMlknj YsN65NNFfPERDiVF1uQVa/iu3G3y4VlrW1xO8AR3OuvqKviEE7dB7a+ipCNTpCKq6Z tWKGzkx1LgJRh0pYLwhHGV7RIFcASKEDOSGHlh2bdCjkST/eJ1f5t0v5mx9b2l06h9 5qOhOAARYXuVQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oLOjZ-001ukl-T0; Tue, 09 Aug 2022 13:53:22 +0100 Date: Tue, 09 Aug 2022 13:53:21 +0100 Message-ID: <87y1vxvari.wl-maz@kernel.org> From: Marc Zyngier To: Huacai Chen Cc: Huacai Chen , Thomas Gleixner , linux-arch , LKML , Xuerui Wang , Xuefeng Li , Jiaxun Yang Subject: Re: [PATCH] LoongArch: Don't disable EIOINTC master core In-Reply-To: References: <20220809074522.2444672-1-chenhuacai@loongson.cn> <874jylx0ad.wl-maz@kernel.org> <871qtpwwem.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: chenhuacai@kernel.org, chenhuacai@loongson.cn, tglx@linutronix.de, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@xen0n.name, lixuefeng@loongson.cn, jiaxun.yang@flygoat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 09 Aug 2022 11:39:15 +0100, Huacai Chen wrote: > > Hi, Marc, > > On Tue, Aug 9, 2022 at 6:20 PM Marc Zyngier wrote: > > > > On Tue, 09 Aug 2022 10:19:31 +0100, > > Huacai Chen wrote: > > > > > > Hi, Marc, > > > > > > On Tue, Aug 9, 2022 at 4:56 PM Marc Zyngier wrote: > > > > > > > > On Tue, 09 Aug 2022 08:45:22 +0100, > > > > Huacai Chen wrote: > > > > > > > > > > This patch fix a CPU hotplug issue. The EIOINTC master core (the first > > > > > core of an EIOINTC node) should not be disabled at runtime, since it has > > > > > the responsibility of dispatching I/O interrupts. > > > > > > > > > > Signed-off-by: Huacai Chen > > > > > --- > > > > > arch/loongarch/kernel/smp.c | 9 +++++++++ > > > > > drivers/irqchip/irq-loongson-eiointc.c | 5 +++++ > > > > > 2 files changed, 14 insertions(+) > > > > > > > > > > diff --git a/arch/loongarch/kernel/smp.c b/arch/loongarch/kernel/smp.c > > > > > index 09743103d9b3..54901716f8de 100644 > > > > > --- a/arch/loongarch/kernel/smp.c > > > > > +++ b/arch/loongarch/kernel/smp.c > > > > > @@ -242,9 +242,18 @@ void loongson3_smp_finish(void) > > > > > > > > > > static bool io_master(int cpu) > > > > > { > > > > > + int i, node, master; > > > > > + > > > > > if (cpu == 0) > > > > > return true; > > > > > > > > > > + for (i = 1; i < loongson_sysconf.nr_io_pics; i++) { > > > > > + node = eiointc_get_node(i); > > > > > + master = cpu_number_map(node * CORES_PER_EIO_NODE); > > > > > + if (cpu == master) > > > > > + return true; > > > > > + } > > > > > + > > > > > return false; > > > > > } > > > > > > > > > > diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c > > > > > index 170dbc96c7d3..6c99a2ff95f5 100644 > > > > > --- a/drivers/irqchip/irq-loongson-eiointc.c > > > > > +++ b/drivers/irqchip/irq-loongson-eiointc.c > > > > > @@ -56,6 +56,11 @@ static void eiointc_enable(void) > > > > > iocsr_write64(misc, LOONGARCH_IOCSR_MISC_FUNC); > > > > > } > > > > > > > > > > +int eiointc_get_node(int id) > > > > > +{ > > > > > + return eiointc_priv[id]->node; > > > > > +} > > > > > + > > > > > static int cpu_to_eio_node(int cpu) > > > > > { > > > > > return cpu_logical_map(cpu) / CORES_PER_EIO_NODE; > > > > > > > > > > > > I don't understand why it has to be this complex and make any use of > > > > the node number. > > > > > > > > As I understand it, CPU-0 in any EIOINTC block is a master. So all you > > > > need to find out is whether the CPU number is a multiple of > > > > CORES_PER_EIO_NODE. > > > CPU-0 in any EIOINTC block may be a master, but not absolutely be a > > > master to dispatch I/O interrupts. If there is no bridge under a > > > EIOINTC, then this EIOINTC doesn't handle I/O interrupts, and it can > > > be disabled at runtime. > > > > But that's not what your code is checking, is it? You're only > > reporting the node number, irrespective of whether there is anything > > behind the EIOINTC. > The return value of eiointc_get_node() means "this eio-node has a > downstream bridge, so the master core of this eio-node cannot be > disabled". :) So what is exactly the meaning of this node? All the EIOINTCs do have one (it is coming from ACPI, and taken at face value), so the node really is only a proxy for the CPU numbers that are attached to it, isn't it? Can you have cores without an EIOINTC? Now, if this is relevant to the arch code, I'd rather you keep track of this directly in the arch code, because it looks really odd to peek at an irqchip data structure for something that the core code should have the first place. It also strikes me that this patch has *zero* effect, as nothing ever sets loongson_sysconf.nr_io_pics. Try this: diff --git a/arch/loongarch/include/asm/bootinfo.h b/arch/loongarch/include/asm/bootinfo.h index 9b8d49d9e61b..13e5e5e21ffd 100644 --- a/arch/loongarch/include/asm/bootinfo.h +++ b/arch/loongarch/include/asm/bootinfo.h @@ -28,7 +28,7 @@ struct loongson_board_info { struct loongson_system_configuration { int nr_cpus; int nr_nodes; - int nr_io_pics; +// int nr_io_pics; int boot_cpu_id; int cores_per_node; int cores_per_package; and see that the kernel still compiles. M. -- Without deviation from the norm, progress is not possible.