Message ID | 20240127161753.114685-3-apatel@ventanamicro.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-41276-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2395:b0:106:343:edcb with SMTP id gw21csp565980dyb; Sat, 27 Jan 2024 08:21:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IHLPF62b7Ft5UeiAesw33B11IHw93gTDTbPQco47PpDFHpBkautxl0OulsKkqGRy5H8hyJg X-Received: by 2002:a05:6a00:9389:b0:6da:cbee:9d9c with SMTP id ka9-20020a056a00938900b006dacbee9d9cmr1076740pfb.29.1706372518566; Sat, 27 Jan 2024 08:21:58 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706372518; cv=pass; d=google.com; s=arc-20160816; b=qQCkniUg6TFyHZtYVo0FhHR8nKqhTG5x+ujDQhUkbk7mrOIF9PlDuN3L+6ekC7K2tW rBH4xK4LICtsFB4A01p1wJjx1UEi7V/jpewaJDkB3HmOeqFKaRbaldAbTESV1RMtGBBR WRWEfkdsOSB/NOGBdOtP+3xDi437MOQEYhY+Zs+81JAcZW1pctAEzepYh9GZ3rJ4MXjC 2RupDIbBFFMiZk0VBz21EDizHT1mD/awYAMKJc17EymcrsdKIu2H00NNEUItJ1QlShA6 Apq1prrX1a2GGwdeTVrv8Ct48LNNKAf3PbDKVrgBxtJBgxzwN0zuw9QuDnCIEn0PcxD8 0VWQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=Gio4VcisYA6evHi9fLFTB/NsIADoYywgfT0MwGlZzIc=; fh=706cnY5t7hpwBXQypCTGH3HYLPe+/lcVAB5kbpxvl24=; b=SuFouHW241mLegvfroaaFnnl4FxfNCnpayrlvr1SySPaYW8+pswvusBUXt4x6R6Uuw p1mNUoBGcMavEEAtFN2UsbIGlH4mxuLgDlyZpWFTGkJ8SIvxf9RYIuPLe4HYhsIg2iU/ OjihTeY6IOkkNWVhR1qP6EvJJA+knFhf1MZKxPCxH0pGuk4NmnAroHf/sUxCyeLYQkyk +5QEq2wfxbUqT22FvnJInzZZMVPPE7pFdIo0590nZvlZo1cWU/Xr6gqgfgkkvchNQU57 J6blyBnsLPaG5V7oJJwJdGSLw/zrfAYJEhDhYPdXnup/DTZMkLF0tBM9iClFpDeHPYwd m3Uw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=OLFUkwd5; arc=pass (i=1 spf=pass spfdomain=ventanamicro.com dkim=pass dkdomain=ventanamicro.com); spf=pass (google.com: domain of linux-kernel+bounces-41276-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-41276-ouuuleilei=gmail.com@vger.kernel.org" Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id m185-20020a633fc2000000b005d5434a5732si2932130pga.456.2024.01.27.08.21.58 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jan 2024 08:21:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-41276-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=OLFUkwd5; arc=pass (i=1 spf=pass spfdomain=ventanamicro.com dkim=pass dkdomain=ventanamicro.com); spf=pass (google.com: domain of linux-kernel+bounces-41276-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-41276-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id F27C4B224E8 for <ouuuleilei@gmail.com>; Sat, 27 Jan 2024 16:19:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6675C2DF9F; Sat, 27 Jan 2024 16:18:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="OLFUkwd5" Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 70DBD2D052 for <linux-kernel@vger.kernel.org>; Sat, 27 Jan 2024 16:18:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706372310; cv=none; b=eRQKsDywwhHzTxE4F/mtGZ/YcjoRNvjT6xRM1sx/7kvSRyGhmGapYfx2uzG7zvwt1QV4uqw6donVIxnUiQod4efObhQ2vZPvYRx+T0jOsFHfNlmQCtvZm/FuuDvLHgE3LQlT5Uf9Y4gkRugT+AQjv1zgujGzFE17NLF+pkAUPlU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706372310; c=relaxed/simple; bh=eJFuo3cIfXEq1mEON0RCgiaWMZ23JLuACI8xiBlZ4CY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=SA69LUEkeQJtBCp4F+k+SiWt7J+nOEREmkLKO3cPaoPn8pfjfmSgRTtF94jXKHyb6pwAUFyGKrPBydyG98Wji8t9+6OYpYY4nTNzz4ZBawBSrDu1QTI/GYcO94hIQRmYT1s/Ie43gU32aHcwOT3bmXEmVq0qqTw0Ngmz1L6SMSE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=OLFUkwd5; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1d730b6943bso7060275ad.2 for <linux-kernel@vger.kernel.org>; Sat, 27 Jan 2024 08:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1706372309; x=1706977109; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Gio4VcisYA6evHi9fLFTB/NsIADoYywgfT0MwGlZzIc=; b=OLFUkwd5v6tkfaultzA8WwqEMA3GwD6QeZUFT8YUzgO1ZY7XS34jIRPfoDVfXTNek/ tAbd/n4kTnjhZWXHVw7nAwPgyIogameaQYLn3NbPO9QglqvkTMKlYbYppRXu6rD0CHKr XnDiIsa8jfQShhMkcweTg4NpTuN2l8Okz+urrnttE2ec3AlUwgckyCAUE/f83DvOvHCO tQhqBepp4RRU+BNHmWoUuI9/4xahnS7CE9qScsmtg94DSWXSXLWdSFMPiTJV7tPgJDPL ymE1PTE/g7q6SAgeMXLCUsyWje4GgZXKNYG47nq4N0z6SdbvCD0WLK/uacCnRMMK5x0B FdjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706372309; x=1706977109; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Gio4VcisYA6evHi9fLFTB/NsIADoYywgfT0MwGlZzIc=; b=p2JrS1iX7NyRXxzoLW71210fyeg3ZjpTgniRnMcp1N1AUd/f2xEA16hlvdh88/1tAR qOw1jV5UpqoYzD2aH8E9UvDl62HDB8vRjif/YXQcLU4MQzzM1lIK8vwsBlCGP+oufO/Q 7ao2bJEntD2rAyyUbvjesSDuHPLMHne1JDfhkD57C84vjgwxe3+9GYZHdkL8d4XfKCLg wexEuqSYcFYdF+0fobRW6WrWlYB3XGjG81O9eoEn4epa8jy15cAVCeEwshpsoESWKIbH LKL3AI7McATWoaau6quKeVewc4CP6Kez7TKQExP4gHLECU5B+amj/W1DNjDVnffxJrdh 2wCQ== X-Gm-Message-State: AOJu0Yy+8QEcmRHwhsjolh3XzaTklTwi0PDqzEDeh78ADkaEX/Qvlr5v abNU86QzO1gdUAubQvfg02k3Do4WYvkWKiu/xYHAL/QHIdCsvm7RyHK0NExX4hU= X-Received: by 2002:a17:903:1c3:b0:1d4:326c:1c89 with SMTP id e3-20020a17090301c300b001d4326c1c89mr1195988plh.10.1706372308671; Sat, 27 Jan 2024 08:18:28 -0800 (PST) Received: from anup-ubuntu-vm.localdomain ([171.76.86.17]) by smtp.gmail.com with ESMTPSA id d11-20020a17090ac24b00b00290f8c708d0sm5091620pjx.57.2024.01.27.08.18.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jan 2024 08:18:28 -0800 (PST) From: Anup Patel <apatel@ventanamicro.com> To: Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Thomas Gleixner <tglx@linutronix.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Frank Rowand <frowand.list@gmail.com>, Conor Dooley <conor+dt@kernel.org> Cc: Marc Zyngier <maz@kernel.org>, =?utf-8?b?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>, Atish Patra <atishp@atishpatra.org>, Andrew Jones <ajones@ventanamicro.com>, Sunil V L <sunilvl@ventanamicro.com>, Saravana Kannan <saravanak@google.com>, Anup Patel <anup@brainfault.org>, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Anup Patel <apatel@ventanamicro.com> Subject: [PATCH v12 02/25] genirq/irqdomain: Remove the param count restriction from select() Date: Sat, 27 Jan 2024 21:47:30 +0530 Message-Id: <20240127161753.114685-3-apatel@ventanamicro.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240127161753.114685-1-apatel@ventanamicro.com> References: <20240127161753.114685-1-apatel@ventanamicro.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789261270358928439 X-GMAIL-MSGID: 1789261270358928439 |
Series |
Linux RISC-V AIA Support
|
|
Commit Message
Anup Patel
Jan. 27, 2024, 4:17 p.m. UTC
From: Thomas Gleixner <tglx@linutronix.de> Now that the GIC-v3 callback can handle invocation with a fwspec parameter count of 0 lift the restriction in the core code and invoke select() unconditionally when the domain provides it. Preparatory change for per device MSI domains. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Anup Patel <apatel@ventanamicro.com> --- kernel/irq/irqdomain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 27/01/2024 16:17, Anup Patel wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > Now that the GIC-v3 callback can handle invocation with a fwspec parameter > count of 0 lift the restriction in the core code and invoke select() > unconditionally when the domain provides it. > > Preparatory change for per device MSI domains. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > --- Hi Thomas/Anup Currently when booting the kernel against next-master(next-20240222) with Arm64 on Qualcomm boards RB5/DB845C, the kernel is resulting in boot failures for our CI. I can send the full logs if required. Most other boards seem to be fine. A bisect (full log below) identified this patch as introducing the failure. Bisected it on the tag "next-20240220" at repo "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". This works fine on Linux v6.8-rc5 Sample log from failure against run on RB5: ------ 07:03:06.985934 <6>[ 1.727034] Trying to probe devices needed for running init ... 07:03:16.905972 <6>[ 11.624040] platform 998000.serial: deferred probe pending: platform: wait for supplier /soc@0/pinctrl@f100000/qup-uart6-default-state 07:03:16.906250 <6>[ 11.636743] platform 1c08000.pcie: deferred probe pending: platform: wait for supplier /soc@0/pinctrl@f100000/pcie1-default-state 07:03:16.906400 <6>[ 11.648976] platform a90000.serial: deferred probe pending: (reason unknown) 07:03:16.945462 <6>[ 11.656490] platform 1c10000.pcie: deferred probe pending: platform: wait for supplier /soc@0/pinctrl@f100000/pcie2-default-state 07:03:16.950476 <6>[ 11.668723] platform c440000.spmi: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.950635 <6>[ 11.679800] platform a6f8800.usb: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.950781 <6>[ 11.690778] platform a8f8800.usb: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.950923 <6>[ 11.701761] platform leds: deferred probe pending: leds-gpio: Failed to get GPIO '/leds/led-user4' 07:03:16.989720 <6>[ 11.711226] platform f100000.pinctrl: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.994769 <6>[ 11.722567] platform 18591000.cpufreq: deferred probe pending: qcom-cpufreq-hw: Failed to find icc paths 07:03:16.994929 <6>[ 11.732573] platform b220000.interrupt-controller: deferred probe pending: (reason unknown) 07:03:16.995076 <4>[ 11.741438] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.034092 <4>[ 11.749935] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.034331 <4>[ 11.758430] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.039326 <4>[ 11.766916] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 1dfa000.crypto 07:03:17.039482 <4>[ 11.775495] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 1dfa000.crypto 07:03:17.039623 <4>[ 11.784081] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 9091000.pmu 07:03:17.039759 <4>[ 11.792389] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 90b6400.pmu 07:03:17.078467 <4>[ 11.800705] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.083560 <4>[ 11.809198] qnoc-sm8250 1500000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.083720 <4>[ 11.817508] qnoc-sm8250 9100000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.083866 <4>[ 11.825825] qnoc-sm8250 163d000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.084006 <4>[ 11.834140] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.122721 <4>[ 11.842456] qnoc-sm8250 1500000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.127829 <4>[ 11.850766] qnoc-sm8250 9100000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.127989 <4>[ 11.859076] qnoc-sm8250 163d000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.128144 <4>[ 11.867388] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.128286 <4>[ 11.875706] qnoc-sm8250 163d000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.167089 <4>[ 11.884733] qnoc-sm8250 1740000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.172232 <4>[ 11.893760] qnoc-sm8250 1500000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.172404 <4>[ 11.902780] qnoc-sm8250 9100000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.172564 <4>[ 11.911805] qnoc-sm8250 163d000.interconnect: sync_state() pending due to ae00000.display-subsystem 07:03:17.172705 <4>[ 11.921359] qnoc-sm8250 1740000.interconnect: sync_state() pending due to ae00000.display-subsystem 07:03:17.211346 <4>[ 11.930932] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 17300000.remoteproc 07:03:17.216527 <4>[ 11.940758] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to ae00000.display-subsystem 07:03:17.216694 <4>[ 11.951113] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to aa00000.video-codec 07:03:17.216840 <4>[ 11.960935] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 8804000.mmc 07:03:17.255721 <4>[ 11.970059] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 8300000.remoteproc 07:03:17.255962 <4>[ 11.979795] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261054 <4>[ 11.988021] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261220 <4>[ 11.996242] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261366 <4>[ 12.004465] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261506 <4>[ 12.012691] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 884000.i2c 07:03:17.300099 <4>[ 12.021008] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 884000.i2c 07:03:17.305306 <4>[ 12.030029] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 980000.spi 07:03:17.305467 <4>[ 12.038254] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 980000.spi 07:03:17.305613 <4>[ 12.046479] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 980000.spi 07:03:17.305754 <4>[ 12.054705] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 980000.spi 07:03:17.344314 <4>[ 12.062927] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 980000.spi 07:03:17.349541 <4>[ 12.071244] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 980000.spi 07:03:17.349701 <4>[ 12.080272] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.349846 <4>[ 12.088494] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.349986 <4>[ 12.096713] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.388758 <4>[ 12.104937] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.388993 <4>[ 12.113158] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 990000.i2c 07:03:17.394156 <4>[ 12.121473] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 990000.i2c 07:03:17.394314 <4>[ 12.130504] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.394458 <4>[ 12.138733] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.394598 <4>[ 12.146958] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.433035 <4>[ 12.155179] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.438301 <4>[ 12.163405] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 994000.i2c 07:03:17.438461 <4>[ 12.171722] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 994000.i2c 07:03:17.438607 <4>[ 12.180742] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 998000.serial 07:03:17.438748 <4>[ 12.189235] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 998000.serial 07:03:17.477464 <4>[ 12.197719] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 998000.serial 07:03:17.482759 <4>[ 12.206299] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 998000.serial 07:03:17.482918 <4>[ 12.215592] qnoc-sm8250 1500000.interconnect: sync_state() pending due to a90000.serial 07:03:17.483065 <4>[ 12.224084] qnoc-sm8250 9100000.interconnect: sync_state() pending due to a90000.serial 07:03:17.483207 <4>[ 12.232576] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to a90000.serial 07:03:17.503624 <4>[ 12.241158] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to a90000.serial ------ Bisect log: ------ git bisect start # good: [b401b621758e46812da61fa58a67c3fd8d91de0d] Linux 6.8-rc5 git bisect good b401b621758e46812da61fa58a67c3fd8d91de0d # bad: [2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e] Add linux-next specific files for 20240220 git bisect bad 2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e # good: [d0427d6bc95f2dae2595859f39c2de343479c909] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git git bisect good d0427d6bc95f2dae2595859f39c2de343479c909 # good: [4c165a847139a6564d28e0f4d8e9fc9c67f22359] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git git bisect good 4c165a847139a6564d28e0f4d8e9fc9c67f22359 # bad: [4dfc8ee8540b799d604551c41c82a9e07089e20e] Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git git bisect bad 4dfc8ee8540b799d604551c41c82a9e07089e20e # bad: [1fad63263f1650f15d5bd174391a53d3e600c327] Merge branch 'rcu/next' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git git bisect bad 1fad63263f1650f15d5bd174391a53d3e600c327 # bad: [0ced0254dca0bc06b09cfe31d6af411856379ea0] Merge branch into tip/master: 'x86/vdso' git bisect bad 0ced0254dca0bc06b09cfe31d6af411856379ea0 # good: [218b13db258c091e646857fc962ef45fe2163054] Merge branch 'x86/core' into x86/merge, to ease integration testing git bisect good 218b13db258c091e646857fc962ef45fe2163054 # bad: [0b1902960678524b91f9ee3c94fc6561cfa1ead9] Merge branch into tip/master: 'timers/ptp' git bisect bad 0b1902960678524b91f9ee3c94fc6561cfa1ead9 # bad: [fa4d750326d50e3cc7801ada3d641daf14a4cb9d] Merge branch into tip/master: 'irq/msi' git bisect bad fa4d750326d50e3cc7801ada3d641daf14a4cb9d # good: [9e04f6432c7ebaf33d5ce9a6e15bc544da316e54] Merge branch into tip/master: 'irq/core' git bisect good 9e04f6432c7ebaf33d5ce9a6e15bc544da316e54 # bad: [1a4671ff7a903e87e4e76213e200bb8bcfa942e4] platform-msi: Remove unused interfaces git bisect bad 1a4671ff7a903e87e4e76213e200bb8bcfa942e4 # bad: [ac81e94ab001c2882e89c9b61417caea64b800df] genirq/msi: Extend msi_parent_ops git bisect bad ac81e94ab001c2882e89c9b61417caea64b800df # bad: [de1ff306dcf4546d6a8863b1f956335e0d3fbb9b] genirq/irqdomain: Remove the param count restriction from select() git bisect bad de1ff306dcf4546d6a8863b1f956335e0d3fbb9b # good: [15137825100422c4c393c87af5aa5a8fa297b1f3] irqchip/gic-v3: Make gic_irq_domain_select() robust for zero parameter count git bisect good 15137825100422c4c393c87af5aa5a8fa297b1f3 # first bad commit: [de1ff306dcf4546d6a8863b1f956335e0d3fbb9b] genirq/irqdomain: Remove the param count restriction from select() ------ Thanks, Aishwarya
On Thu, 22 Feb 2024 13:01:32 +0000, Aishwarya TCV <aishwarya.tcv@arm.com> wrote: > > > > On 27/01/2024 16:17, Anup Patel wrote: > > From: Thomas Gleixner <tglx@linutronix.de> > > > > Now that the GIC-v3 callback can handle invocation with a fwspec parameter > > count of 0 lift the restriction in the core code and invoke select() > > unconditionally when the domain provides it. > > > > Preparatory change for per device MSI domains. > > > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > --- > > Hi Thomas/Anup > > Currently when booting the kernel against next-master(next-20240222) > with Arm64 on Qualcomm boards RB5/DB845C, the kernel is resulting in > boot failures for our CI. I can send the full logs if required. Most > other boards seem to be fine. > > A bisect (full log below) identified this patch as introducing the > failure. Bisected it on the tag "next-20240220" at repo > "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". > > This works fine on Linux v6.8-rc5 Can you please try [1]? M. [1] https://lore.kernel.org/linux-kernel/20240220114731.1898534-1-maz@kernel.org
On 22/02/2024 16:28, Marc Zyngier wrote: > On Thu, 22 Feb 2024 13:01:32 +0000, > Aishwarya TCV <aishwarya.tcv@arm.com> wrote: >> >> >> >> On 27/01/2024 16:17, Anup Patel wrote: >>> From: Thomas Gleixner <tglx@linutronix.de> >>> >>> Now that the GIC-v3 callback can handle invocation with a fwspec parameter >>> count of 0 lift the restriction in the core code and invoke select() >>> unconditionally when the domain provides it. >>> >>> Preparatory change for per device MSI domains. >>> >>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> >>> --- >> >> Hi Thomas/Anup >> >> Currently when booting the kernel against next-master(next-20240222) >> with Arm64 on Qualcomm boards RB5/DB845C, the kernel is resulting in >> boot failures for our CI. I can send the full logs if required. Most >> other boards seem to be fine. >> >> A bisect (full log below) identified this patch as introducing the >> failure. Bisected it on the tag "next-20240220" at repo >> "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". >> >> This works fine on Linux v6.8-rc5 > > Can you please try [1]? > > M. > > [1] https://lore.kernel.org/linux-kernel/20240220114731.1898534-1-maz@kernel.org > With the patch[1] applied on next-master(next-20240222), successfully tested booting the kernel with Arm64 on Qualcomm boards RB5/DB845C. Confirming that the patch is resolving the boot issue on RB5/DB845C Thanks Aishwarya
Dear All, On 27.01.2024 17:17, Anup Patel wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > Now that the GIC-v3 callback can handle invocation with a fwspec parameter > count of 0 lift the restriction in the core code and invoke select() > unconditionally when the domain provides it. > > Preparatory change for per device MSI domains. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> This patch landed recently in linux-next (next-20240221) as commit de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction from select()"). I've noticed that it breaks booting of Qualcomm's Robotics RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting freezes after "clk: Disabling unused clocks", but this is probably a consequence of some earlier failure. Reverting $subject on top of next-20240221 fixes this problem. Let me know how can I help debugging this issue. > --- > kernel/irq/irqdomain.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > index 0bdef4fe925b..8fee37918195 100644 > --- a/kernel/irq/irqdomain.c > +++ b/kernel/irq/irqdomain.c > @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec, > */ > mutex_lock(&irq_domain_mutex); > list_for_each_entry(h, &irq_domain_list, link) { > - if (h->ops->select && fwspec->param_count) > + if (h->ops->select) > rc = h->ops->select(h, fwspec, bus_token); > else if (h->ops->match) > rc = h->ops->match(h, to_of_node(fwnode), bus_token); Best regards
Hi Marek Szyprowski, > -----Original Message----- > From: linux-arm-kernel <linux-arm-kernel-bounces@lists.infradead.org> On > Behalf Of Marek Szyprowski > Sent: Friday, February 23, 2024 10:23 AM > Subject: Re: [PATCH v12 02/25] genirq/irqdomain: Remove the param count > restriction from select() > > Dear All, > > On 27.01.2024 17:17, Anup Patel wrote: > > From: Thomas Gleixner <tglx@linutronix.de> > > > > Now that the GIC-v3 callback can handle invocation with a fwspec > > parameter count of 0 lift the restriction in the core code and invoke > > select() unconditionally when the domain provides it. > > > > Preparatory change for per device MSI domains. > > > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > > This patch landed recently in linux-next (next-20240221) as commit > de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction from > select()"). I've noticed that it breaks booting of Qualcomm's Robotics > RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting > freezes after "clk: Disabling unused clocks", but this is probably a > consequence of some earlier failure. Reverting $subject on top of > next-20240221 fixes this problem. Let me know how can I help debugging > this issue. > > > > --- > > kernel/irq/irqdomain.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index > > 0bdef4fe925b..8fee37918195 100644 > > --- a/kernel/irq/irqdomain.c > > +++ b/kernel/irq/irqdomain.c > > @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct > irq_fwspec *fwspec, > > */ > > mutex_lock(&irq_domain_mutex); > > list_for_each_entry(h, &irq_domain_list, link) { > > - if (h->ops->select && fwspec->param_count) > > + if (h->ops->select) > > rc = h->ops->select(h, fwspec, bus_token); > > else if (h->ops->match) > > rc = h->ops->match(h, to_of_node(fwnode), bus_token); This patch looks reverted on todays's next. But there was a fix for fixing the issue you mentioned [1] [1] https://lore.kernel.org/all/170844679345.398.17551290253758129895.tip-bot2@tip-bot2/ Cheers, Biju
On 23.02.2024 11:45, Biju Das wrote: >> On 27.01.2024 17:17, Anup Patel wrote: >>> From: Thomas Gleixner <tglx@linutronix.de> >>> >>> Now that the GIC-v3 callback can handle invocation with a fwspec >>> parameter count of 0 lift the restriction in the core code and invoke >>> select() unconditionally when the domain provides it. >>> >>> Preparatory change for per device MSI domains. >>> >>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> >> >> This patch landed recently in linux-next (next-20240221) as commit >> de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction from >> select()"). I've noticed that it breaks booting of Qualcomm's Robotics >> RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting >> freezes after "clk: Disabling unused clocks", but this is probably a >> consequence of some earlier failure. Reverting $subject on top of >> next-20240221 fixes this problem. Let me know how can I help debugging >> this issue. >> >> >>> --- >>> kernel/irq/irqdomain.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index >>> 0bdef4fe925b..8fee37918195 100644 >>> --- a/kernel/irq/irqdomain.c >>> +++ b/kernel/irq/irqdomain.c >>> @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct >> irq_fwspec *fwspec, >>> */ >>> mutex_lock(&irq_domain_mutex); >>> list_for_each_entry(h, &irq_domain_list, link) { >>> - if (h->ops->select && fwspec->param_count) >>> + if (h->ops->select) >>> rc = h->ops->select(h, fwspec, bus_token); >>> else if (h->ops->match) >>> rc = h->ops->match(h, to_of_node(fwnode), bus_token); > This patch looks reverted on todays's next. But there was a fix for fixing the issue you mentioned [1] > > [1] https://lore.kernel.org/all/170844679345.398.17551290253758129895.tip-bot2@tip-bot2/ Thanks! Today's next seems to be broken on ARM64 (doesn't compile here), so I've missed it. Best regards
Hi Marek Szyprowski, > -----Original Message----- > From: Marek Szyprowski <m.szyprowski@samsung.com> > Sent: Friday, February 23, 2024 10:57 AM > Subject: Re: [PATCH v12 02/25] genirq/irqdomain: Remove the param count > restriction from select() > > On 23.02.2024 11:45, Biju Das wrote: > >> On 27.01.2024 17:17, Anup Patel wrote: > >>> From: Thomas Gleixner <tglx@linutronix.de> > >>> > >>> Now that the GIC-v3 callback can handle invocation with a fwspec > >>> parameter count of 0 lift the restriction in the core code and > >>> invoke > >>> select() unconditionally when the domain provides it. > >>> > >>> Preparatory change for per device MSI domains. > >>> > >>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > >>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> > >> > >> This patch landed recently in linux-next (next-20240221) as commit > >> de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction > >> from select()"). I've noticed that it breaks booting of Qualcomm's > >> Robotics > >> RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting > >> freezes after "clk: Disabling unused clocks", but this is probably a > >> consequence of some earlier failure. Reverting $subject on top of > >> next-20240221 fixes this problem. Let me know how can I help > >> debugging this issue. > >> > >> > >>> --- > >>> kernel/irq/irqdomain.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index > >>> 0bdef4fe925b..8fee37918195 100644 > >>> --- a/kernel/irq/irqdomain.c > >>> +++ b/kernel/irq/irqdomain.c > >>> @@ -448,7 +448,7 @@ struct irq_domain > >>> *irq_find_matching_fwspec(struct > >> irq_fwspec *fwspec, > >>> */ > >>> mutex_lock(&irq_domain_mutex); > >>> list_for_each_entry(h, &irq_domain_list, link) { > >>> - if (h->ops->select && fwspec->param_count) > >>> + if (h->ops->select) > >>> rc = h->ops->select(h, fwspec, bus_token); > >>> else if (h->ops->match) > >>> rc = h->ops->match(h, to_of_node(fwnode), > bus_token); > > This patch looks reverted on todays's next. But there was a fix for > > fixing the issue you mentioned [1] > > > > [1] > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fall%2F170844679345.398.17551290253758129895.tip-bot2%40t > > ip-bot2%2F&data=05%7C02%7Cbiju.das.jz%40bp.renesas.com%7Cffce754120ba4 > > ff0f8d708dc345e1c1a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C63844 > > 2825998732581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lYLVpa4tz2fEU1Jc > > DDGUF6eigi2YJuGDouMXrJSlibo%3D&reserved=0 > > Thanks! Today's next seems to be broken on ARM64 (doesn't compile here), > so I've missed it. FYI, ARM64 defconfig works for me. Linux smarc-rzg2l 6.8.0-rc5-next-20240223-gfebe82167ab7 #1430 SMP PREEMPT Fri Feb 23 07:41:52 GMT 2024 aarch64 GNU/Linux Cheers, Biju
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index 0bdef4fe925b..8fee37918195 100644 --- a/kernel/irq/irqdomain.c +++ b/kernel/irq/irqdomain.c @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec, */ mutex_lock(&irq_domain_mutex); list_for_each_entry(h, &irq_domain_list, link) { - if (h->ops->select && fwspec->param_count) + if (h->ops->select) rc = h->ops->select(h, fwspec, bus_token); else if (h->ops->match) rc = h->ops->match(h, to_of_node(fwnode), bus_token);