From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 38BEF20C490; Sat, 22 Nov 2025 09:38:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763804283; cv=none; b=p1AkyaMa94zU8kvcaBDTB1d25G/VZ86+39lClN7GQOp2r/mVZJiDRxo4l+/+9RhU5yCOMF3bYlaqHQV9+H3ljJvG2uCEtQ8pl4VlQK+o0Y490iQnkYJZga16HXlbB5bjVAp2WdVEAFcZaF9AXWpcD0DpVKwW4aHpJ8YbqisAQwA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763804283; c=relaxed/simple; bh=XYJsNNEAFKWw+GFpRdXSFOCFfouPlV2hU/sp7ovg0ng=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=GGMpIdz93qZ5OuXScr+1NnAkeAE35PG2NQq5z0SSiWuuysKTfQGRnWL53pItrUyB9x+uMftmNSGZ3Tv2SiDilWbUYFjioY/wKjdQsbjkIpTfJ1Ta/r43dt3cOTYnRsGnXKzesK7NLgMY1KX2k33xRRVIGsnF0vm2d8ARman/ssE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RUJRkzdt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RUJRkzdt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94781C4CEF5; Sat, 22 Nov 2025 09:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763804282; bh=XYJsNNEAFKWw+GFpRdXSFOCFfouPlV2hU/sp7ovg0ng=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RUJRkzdtRToNgW4Uy5JkI2e2Dch22SVdb2x7yUV/20KlwHeEDQYiSywUzeq4rdC9c J2o4aQPO2LfK812kH5eHQbekl/XxEw804txakvdVtSwu5CC4pgcZXgxnyrvBBuQt4x kD/cv+zr7+zndCu5SLbt0RiIooG1/OS1c5EeXeiUxJSDxoMnTJ8yz7WiPFMigPpTdo vPPZ2DYCyk+ERCfCqbChitSkEMcbzeZ6Ftlit0wZ9i0twkG9n6+wfmZ947yNpHrNK0 cW2JGAgWULrKcLZ2Eds3zl3uAjiktb41EaEJswDtO0LMU3NY7oCIC35o+2S+x85v0R 8e36id9jvF0/A== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vMk47-00000007SZ3-3Ecj; Sat, 22 Nov 2025 09:37:59 +0000 Date: Sat, 22 Nov 2025 09:37:58 +0000 Message-ID: <87ms4eflvt.wl-maz@kernel.org> From: Marc Zyngier To: niliqiang Cc: sunilvl@ventanamicro.com, ajones@ventanamicro.com, anup@brainfault.org, apatel@ventanamicro.com, atishp@atishpatra.org, bjorn@kernel.org, conor+dt@kernel.org, deng.weixian@zte.com.cn, devicetree@vger.kernel.org, frowand.list@gmail.com, hu.yuye@zte.com.cn, krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, ni.liqiang@zte.com.cn, palmer@dabbelt.com, paul.walmsley@sifive.com, robh+dt@kernel.org, saravanak@google.com, tglx@linutronix.de, dai.hualiang@zte.com.cn, liu.qingtao2@zte.com.cn, guo.chang2@zte.com.cn, wu.jiabao@zte.com.cn, liu.wenhong35@zte.com.cn Subject: Re: [PATCH v16 6/9] irqchip: Add RISC-V advanced PLIC driver for direct-mode In-Reply-To: <20251121135407.53372-1-ni_liqiang@126.com> References: <20251121135407.53372-1-ni_liqiang@126.com> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ni_liqiang@126.com, sunilvl@ventanamicro.com, ajones@ventanamicro.com, anup@brainfault.org, apatel@ventanamicro.com, atishp@atishpatra.org, bjorn@kernel.org, conor+dt@kernel.org, deng.weixian@zte.com.cn, devicetree@vger.kernel.org, frowand.list@gmail.com, hu.yuye@zte.com.cn, krzysztof.kozlowski+dt@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, ni.liqiang@zte.com.cn, palmer@dabbelt.com, paul.walmsley@sifive.com, robh+dt@kernel.org, saravanak@google.com, tglx@linutronix.de, dai.hualiang@zte.com.cn, liu.qingtao2@zte.com.cn, guo.chang2@zte.com.cn, wu.jiabao@zte.com.cn, liu.wenhong35@zte.com.cn X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 21 Nov 2025 13:54:07 +0000, niliqiang wrote: > [...] > 2. But the OS enumerates them in random order upon each boot (first boot = sequence =E2=89=A0 second boot sequence) > first boot sequence ~ # dmesg |grep -i "PCI Root" > [ 8794.588531] ACPI: PCI Root Bridge [PC08] (domain 0006 [bus 80-ff]) > [ 8794.624478] ACPI: PCI Root Bridge [PC06] (domain 0005 [bus 00-ff]) > [ 8794.672741] ACPI: PCI Root Bridge [PC10] (domain 0008 [bus 00-ff]) > [ 8794.696680] ACPI: PCI Root Bridge [PC07] (domain 0006 [bus 00-7f]) > [ 8794.728234] ACPI: PCI Root Bridge [PC11] (domain 0009 [bus 00-ff]) > [ 8794.755098] ACPI: PCI Root Bridge [PC09] (domain 0007 [bus 00-ff]) > second boot sequence ~ # dmesg |grep -i "PCI Root" > [ 8794.588531] ACPI: PCI Root Bridge [PC09] (domain 0007 [bus 00-ff]) > [ 8794.624478] ACPI: PCI Root Bridge [PC06] (domain 0005 [bus 00-ff]) > [ 8794.672741] ACPI: PCI Root Bridge [PC08] (domain 0006 [bus 80-ff]) > [ 8794.696680] ACPI: PCI Root Bridge [PC11] (domain 0009 [bus 00-ff]) > [ 8794.728234] ACPI: PCI Root Bridge [PC07] (domain 0006 [bus 00-7f]) > [ 8794.755098] ACPI: PCI Root Bridge [PC10] (domain 0008 [bus 00-ff]) >=20 > This creates a critical issue: when NVMe devices are connected to > these host bridges, the unpredictable kernel scanning sequence > causes device identifiers (e.g., /dev/nvme0n1, /dev/nvme1n1) to > change across reboots. In server environments, such device naming > instability is unacceptable as it breaks storage configuration > reliability and consistency. You're barking up the wrong tree. It is *userspace*'s job to ensure this consistency. That's why udev exists. That's why device and partition UUIDs exist. In short, this isn't the kernel's job. The kernel gives you all the tools you need already. Thanks, M. --=20 Jazz isn't dead. It just smells funny.