From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) (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 32508344D8C for ; Thu, 29 Jan 2026 13:49:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769694597; cv=none; b=h0VyvReDLZVkcjxFo8TaT5YzwE55ykYGE/XdHNjsl3DmeqXkYwYdr1bV4wwBSunVRtP2pofXfNT7TmOMOhGLz1YZqCjz6u5mOXRkquogMCpFZgmHKTAARWQWE7jaKHwuxsQ4fcO9DTNfNV+quUSsvmL7QZsyBJFBTI6jr1LGguM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769694597; c=relaxed/simple; bh=Kx1nkocKHg2r0KbodzyE6L4KOQagRhJ/saQ/g0TrF+g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HI74daGcZcaRA1R9pHchWhhp3YZvq2sC05YP72xOnd7PIDBybAdJpxvlxitLxDPDa47J6z9EoY/rQTU9NpHNAMo2o2npzL3XaS9NaZgQ5nUjcjl7mwcaHa5rTXfUxXdrCGM1AtvWQE5iRvGaTdtCZRjQXzL0B+Lb38wuoCKZF0w= 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=MqUu8Ubv; arc=none smtp.client-ip=209.85.210.193 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="MqUu8Ubv" Received: by mail-pf1-f193.google.com with SMTP id d2e1a72fcca58-81dab89f286so495917b3a.2 for ; Thu, 29 Jan 2026 05:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1769694595; x=1770299395; 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=MVJS0XZnQdJSuFRyO9cJopaQzPSIm6FDGJq3O2WzR/w=; b=MqUu8UbvxitnXnJTGHY5ruvNJV8KH9cJGi0hvHQc5CJmR8TmY+QDdt3QeIw3DPrMvJ t4Ac1K4x1Mncr0YnE4dabFNV5Tfd6P/o2dsY397c00UyyQBESfQw0jjGSharhjhEa4oU mIps82+3jo8ZbtGssM/JphJrze1iOruCydgoiECd1xWQJKlyZjRNv56Lek2XBgh2jmrC 9S+Hhc9FHEBnY7wjFgIPujlErsDg1rjFHEFzt7rVU2FbSow3Me6ZOdr5HMV7eVndN5tP Vm9R4zyIqvPbtOTklEZGTDcZgzHLBeL/QeWmvhRIMjVt/F+KfPTfgOdui5nMA9Ea9xYd PlZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769694595; x=1770299395; 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=MVJS0XZnQdJSuFRyO9cJopaQzPSIm6FDGJq3O2WzR/w=; b=hSVpB3ovzZFnjnPKX5469JkpSXY7e31G0K5of9Crozxoj840IS2o9J7gBzxyjwd1of g7jMBPiLxIatQqzvxCJV0NK7ozmN74QyKeF3JUxLO8HyKN/+h5P+Hn+0e5/EhNB0IK7S wEkQDt86taSWx+H7l1vwtfceC9VovBHRdSiTGqakWLEjKr0ASWSnLLf8WIblXac+1py0 BmTN1hUQa6KjgZgr+Bh8XWnolj6Q1ltwRM22jGeGjpKavbgu2rlgrWweM6LOmbpNJHnO FdNH2oR+mhKBBMNQv4VlndNpz5dwNe34jf3K6ns/vgMELGOx9EtDtRcxEf85CGkBy72N QmPg== X-Forwarded-Encrypted: i=1; AJvYcCWTC4JKXsmrCejQMYpT7OBHQZxaIi7spqjKAfgKNbegxGykmTf1f3bqNaWZG4sGXfWMkQTSEVgTxP0uWmg=@vger.kernel.org X-Gm-Message-State: AOJu0YyHUjqH4YBPUwj9/uaV+VmkjCld48+HY+PZIEu98i5LI1CWeCrD EBn2q4QV7qYKjg3FmLifs7env24viGY5h32/1E2SimEHW/JPKYsNIM5MD1nG2lIPRc0= X-Gm-Gg: AZuq6aLi7Dn+lHcP0TFHsd9z810ppJqDuFjiI0Z17vpQIszNsIKlBUb65rqMG8jyTUH BSR1wEO9NX6WkkeXuUySQbKG4nOvPSxcKZDXcusQhds7HX4v23G2ICRXQEUZw8EowMKALTFE5Pk Pj1uYD38bU/kwvKTtvj3ekWItdI2WjMN9ef/hjuQBk9M4PD1APFoxJNpRupABt91Grnxj1ZzJo2 eITITFNxiiSnCLdDSJtQDtK78L5We+N4JZYeK1vmzfHikeCdlxWk3J35xenqDynLDWvR+PuZwye +Ww4mFq9RXK37L8h5LfcwrjiXauFpIDmqfS9T/X8pBxG72jufmpLqjc504w+cz0/yJWGiXVTxMX AeHG52l35FkrhQmDdS6CvAGvQVIjujtMN/on89KAkZo6EdyHoXrflUfEHnvcynChvkL9FGn0z7B /BLEUn/CiMtLf6hdIVCg== X-Received: by 2002:a05:6a00:2e2a:b0:800:8fdf:1a54 with SMTP id d2e1a72fcca58-82369275931mr8476106b3a.34.1769694595607; Thu, 29 Jan 2026 05:49:55 -0800 (PST) Received: from sunil-laptop ([106.51.192.152]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82379bfcaadsm6072882b3a.37.2026.01.29.05.49.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jan 2026 05:49:54 -0800 (PST) Date: Thu, 29 Jan 2026 19:19:43 +0530 From: Sunil V L To: Bjorn Helgaas Cc: "Rafael J. Wysocki" , huyuye , Bjorn Helgaas , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Robert Moore , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, dai.hualiang@zte.com.cn, deng.weixian@zte.com.cn, guo.chang2@zte.com.cn, liu.qingtao2@zte.com.cn, wu.jiabao@zte.com.cn, lin.yongchun@zte.com.cn, hu.yuye@zte.com.cn, zhang.longxiang@zte.com.cn, zuo.jiang@zte.com.cn, li.kunpeng@zte.com.cn, Sunil V L , Lorenzo Pieralisi Subject: Re: [PATCH v2] ACPI: pci_root: Clear the acpi dependencies after PCI root bridge initialization on RISC-V Message-ID: References: <20260127194648.GA368841@bhelgaas> 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: <20260127194648.GA368841@bhelgaas> On Tue, Jan 27, 2026 at 01:46:48PM -0600, Bjorn Helgaas wrote: > On Tue, Jan 27, 2026 at 06:50:24PM +0100, Rafael J. Wysocki wrote: > > On Tue, Jan 27, 2026 at 6:26 PM Bjorn Helgaas wrote: > > > On Tue, Jan 27, 2026 at 04:00:49PM +0100, Rafael J. Wysocki wrote: > > > > On Mon, Jan 12, 2026 at 3:17 PM huyuye wrote: > > > > > [...] > > Not really. > > > > acpi_dev_clear_dependencies() is related to the way Linux uses _DEP > > which is to defer the enumeration of dependent devices until the > > devices they depend on are ready. > > > > So by calling acpi_dev_clear_dependencies() the driver basically > > allows other drivers to bind to devices. > > I assumed the dependency expressed by _DEP would be satisfied by the > execution of some other ACPI method. E.g., the dependency might be > satisfied when a _REG method makes an opregion available (although the > spec seems to suggest that's only one of the possible dependencies). > > But in this case it sounds like RISC-V is using _DEP not because of > any ACPI-related ordering requirement, but simply to enforce the OS > enumeration order (and therefore naming). I guess this refers to PCI > device naming, so I suppose that dependency is on > pci_acpi_scan_root(). > Right. Devices that use wired interrupts (or GSIs) depend on the APLIC interrupt controller being probed first. ACPI uses the _DEP mechanism to enforce this probe order. However, when multiple dependent PCI bridges are present in the system, there is no guarantee that they will be probed in the same order on every reboot. This patch addresses the issue by adding _DEP relationships between the PCI bridge nodes in the platform, ensuring that they are always probed in a deterministic order. > I thought udev was supposed to be the real solution for consistent > naming. Is this sort of a workaround to accomplish the same end? > Yes, Marc had suggested this as well, but it looks like it’s not easy to use in this environment [1]. > In any case, your IS_ENABLED(CONFIG_RISCV) proposal seems fine to me. > I think it's nice if we can avoid adding another __weak function. > I agree. But I am not sure if ARM also can get into this situation with GICv5. Adding Lorenzo. [1] - https://lore.kernel.org/linux-riscv/20251126161540.6460-1-ni_liqiang@126.com/ Thanks, Sunil