From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (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 2BDAC33A03C for ; Fri, 21 Nov 2025 08:51:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763715070; cv=none; b=GKYPCZ0IXxSGTi9UPXNDtvA0lUeQnVcdslPrKem49XkCbNedlvJJPvxmR8Lkl/NBnVPYxfCX4BJqL+sujl7/Ez7g2S+WmjKRz5MKi9YV/CLPLO38THHN5Awm5weNxi4Udegpa0MNp2GYPyuTZMYB7yjRKu7kJ0+TRNv6mJ4I1O0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763715070; c=relaxed/simple; bh=sd/LiWrbtwaBwTkH9XCz3DjCFYb/6b+Fn6RgAT343Sk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WofMFX+Ufvo8jzzuJ2C6b/vlyvEpQjrJir/BDHgOhH4CDTROjICCXKeRfKAhPh7pyTKHLBdISZmX9ExV+684iGodHi+8fHClEtKBpv5P1mlgtDdv3pMj+N7xoVm1se2tLbZ1CrpDWhTr5s1HrjXQuRnwzkkVzf79zWEEx/85hjI= 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=htdfMiGP; arc=none smtp.client-ip=209.85.214.178 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="htdfMiGP" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-297dd95ffe4so15517135ad.3 for ; Fri, 21 Nov 2025 00:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1763715066; x=1764319866; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=2Zl49bFVQ8HXNASEX2XzPWaAJ5IL+RSr8MjMD86xJZI=; b=htdfMiGP3Pg9E4/RZ1kclQwZqceAGnTxqkF7qM2NMMumeHK3n5vjI6qz8lLQ/0rO9o bfhVJvGlygXWLfUY0ksDa+YOQWfhjvA9ZlVb747XlXBR+fJRyJ1vSrn0U5taYRhwjiiY IJjzGkKFzrw8VnqMxh0mJeMljqlfpDzhDO8ZoPmCkHp56YAKR1rfHeZcyd4HgdnPzuBO sYCsxLLJRnju9AKHleyFkbrO+iOLA2dvu6EnMMoDqTuzuYyg8la9VHBzRFWVp7YhWSEi orV0U8u+nkh9Lo7jtJEygt4W2GRHYx85Fa58aR8D7cmhWB9/zGwT/ETyLqrrBjFZpSmv N9lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763715066; x=1764319866; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2Zl49bFVQ8HXNASEX2XzPWaAJ5IL+RSr8MjMD86xJZI=; b=ZJH+N+VCMzDHUtdWejNRzYkVAYqim+XXYHNm3DQj1Fshba4hwOi9zQZXnj1BcWV7sK otfXW8XufjmJ2q2x/yQ568PvsXxuAr15587/qOHcqtyUMUoNtTUc/zSJsefS++8sKnzX 7wUt/q62PZX+ENbSNm+ZR53SgW9g6AH0z0OuMYMA5mqVjDad3mcdKl7K7+IZw8xrhKLN 2ijaXzFb9SHtmruhQpk0SfDJk1I/7QTdDBxRctme/QiLPILRzIUz6X/lZlqFAP59ZC6K CEM+clHd6+VF1ImePZl9Zi36y849tBvn2tyq5dPTqO/1OrBIhr2K3vUA7YPHnSeZKjfI LDEw== X-Forwarded-Encrypted: i=1; AJvYcCXJ1BNe5O08YlR52ppSPkbVN0/R3wVBSpN6SS+8vMEZmQ5d3OU9jQZZXeTYOV5XyRQk1Y+PsS9XS4EDQ9o=@vger.kernel.org X-Gm-Message-State: AOJu0YxxVCUyoxB+n5ZtvWevgJayg9h3w0kheBZLQoYH22nRFzaQvOj1 6c5POPq0br0IZtOJX7txkBsaNn6L2yDHPGPuRN2oJPSY7/DJ31G/0Q5A613CXBf9JV0= X-Gm-Gg: ASbGncsC0E8IaabMvElcVYohoSwpk/8KzlAo8/lOJaxtPPEQYnYF+iQhGwyhoKN6un+ nfXS6pBlUIyDI/rhaK2ycfgzi4hnR0r5GnRCpcwbbG7gj44DmUBBSufbd0GaLcTMiUBy/QJ046H 9IxaTC02zbfQgUuMR88C58QSm0syG6U1h1H2sCnIyWdE8VE6EvCnyHD6mJLhRCKD1TSra1e2b9w xHrdujs8uO3cqk+TO026v2dJsJKGivwwBr27SIC5i1a0re8OWw68f09vVASLrW5LCHDDkNJwGzB AmtVSrJVbfnPcW6jkPazXFVYbtfkyCy3bsegMLFII6k6FHroc/q5EdUUWQddot82HDXZwsQXWaH VmxKy5TwqxzmVE8ppU2/4IY0DUWgeG+Rsw1IrAW8TJVu2u4HnDHP6ya5Y9tFIaOoKTg0hfN/ufF 30ZGZ1LzrLuBr/jht0 X-Google-Smtp-Source: AGHT+IForle4Voi5B250DXGCJPKzmYnRrMuv4VZwFpXmqKqn4IMqRvfMy2WJ1GWndhzWr/EzoK5qvQ== X-Received: by 2002:a17:90b:35cc:b0:341:194:5e7d with SMTP id 98e67ed59e1d1-34733f19c00mr2066526a91.24.1763715066040; Fri, 21 Nov 2025 00:51:06 -0800 (PST) Received: from sunil-laptop ([106.51.195.35]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-345b036a282sm5593927a91.4.2025.11.21.00.50.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 00:51:05 -0800 (PST) Date: Fri, 21 Nov 2025 14:20:56 +0530 From: Sunil V L To: niliqiang Cc: apatel@ventanamicro.com, ajones@ventanamicro.com, anup@brainfault.org, atishp@atishpatra.org, bjorn@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org, frowand.list@gmail.com, krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, maz@kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com, robh+dt@kernel.org, saravanak@google.com, tglx@linutronix.de, hu.yuye@zte.com.cn, deng.weixian@zte.com.cn, ni.liqiang@zte.com.cn Subject: Re: [PATCH v16 6/9] irqchip: Add RISC-V advanced PLIC driver for direct-mode Message-ID: References: <20240307140307.646078-7-apatel@ventanamicro.com> <20251120144311.5083-1-ni_liqiang@126.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251120144311.5083-1-ni_liqiang@126.com> Hi Liqiang, On Thu, Nov 20, 2025 at 10:43:11PM +0800, niliqiang wrote: > > diff --git a/drivers/irqchip/irq-riscv-aplic-main.c b/drivers/irqchip/irq-riscv-aplic-main.c > > +static const struct of_device_id aplic_match[] = { > > + { .compatible = "riscv,aplic" }, > > + {} > > +}; > > + > > +static struct platform_driver aplic_driver = { > > + .driver = { > > + .name = "riscv-aplic", > > + .of_match_table = aplic_match, > > + }, > > + .probe = aplic_probe, > > +}; > > +builtin_platform_driver(aplic_driver); > > Dear Anup Patel and all concerned, > > I am writing to inquire about the historical rationale behind defining the APLIC driver's > initialization priority using builtin_platform_driver in the current implementation. > > In our environment, we are encountering an issue where this priority level causes ACPI-based PCIe > enumeration to be executed in the system_unbound_wq work queue. This parallel execution model > results in PCIe devices being enumerated in an arbitrary order rather than strictly following the > sequence defined in the ACPI DSDT table. > > The random enumeration order is adversely affecting customer experience, particularly in scenarios > where device ordering is critical for proper system operation or application compatibility. > > We are considering modifying the APLIC driver's initialization priority to ensure PCIe enumeration > occurs sequentially according to the DSDT specification. However, before proceeding with such > changes, we wanted to consult with you regarding: > > 1. Were there specific technical considerations that led to the current priority selection? > 2. Are there any potential side effects or broader impacts that we might have overlooked? > 3. Would you support such a priority adjustment, or do you have alternative suggestions to > address the enumeration order issue? > > We greatly appreciate your insights and expertise on this matter, as it will help us make an > informed decision while maintaining system stability and compatibility. > > Thank you for your time and consideration. > IRQ subsystem maintainers rejected the idea of relying on initcalls to enforce probe order because initcalls do not guarantee ordering. The Linux driver model instead ensures probe order through device dependencies. Since PCI INTx depends on the APLIC being probed first, the PCI host bridge probe cannot occur until after the APLIC probe completes. This requirement and behavior are the same for both DT and ACPI. In DT, the driver model uses fw_devlink to establish probe ordering, while in ACPI this is handled through either an explicit _DEP or, on RISC-V, the GSI mapping. Typically, this dependency appears in the DSDT only for the PCI host bridge. Individual PCIe devices are enumerated through the standard PCI scan once the host bridge has been probed. Therefore, I’m not sure what you meant by a probe sequence defined in the DSDT for PCIe devices. Regards, Sunil