From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=217.194.8.81 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794477895; b=Z2M8s2NZO7Wveyq/GPDEhmxPEcDlHHNidWGFr6L1TiKzH2ih9vd+fjMNaBSw4GBvTLVc qlQJQ0/btj5rN3yOWrKU3Nt2Dpv+gLHHPNNoVzl4+9Yl4kW4R1z62HYeVG3CyDyaRO1kP aJTnldAHiqiZuDXuA5t2UGXCeCx7VAaJR783jr+f93oZZ8ExzCH8ImyYbx4KUlpqGARGL G9HBaZRzQmMEEO53wSuwBPLaoWhNiWSsLjoubEoxyfRn3c5DoFFcfkBt7LK5MET6R80MU i9agk2w6uMadCvbLW22lXCM+B9rqe7QWhiBzcZ8WhtxJqJuNks5nvO+5W+kdvAuzVXw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794477895; h=DMARC-Filter:Received:DKIM-Signature:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To; bh=12FxQz40ZG0aBXbOpbg2g2yd/BGfhAmZAB/dUKb2ZeE=; b=X31LnDwXAoZNB8Bp/rcvnIN6YzpqVKWUehPk2v5vEBYw2QeYGcCO4+noA7OYlmcgGM1g P2NeOtGOsP4Jx7zSOx6hKJLqSzmpv4ptlTJOWZb3W3NNhIjAiHidKhHkIQdsjvdSmXBLh dA5QXNxShk1JV7OVn6yIaI+bFzni9OuzC6i5htYYci49KmlKNAXxxth6uoOznD8jlu1qm iUWUe7sOHBKtDgeJ1cpL7aDVMJON72uwDQJoOkY2IHbItVrlGcZq1tM3iM92DhaCzksV2 aduj4LSq4LpnuXqi9e57SOzI1Vh6BafKba7BaZf51Xa165gP3gFaJnq8a7nHSE1JwJw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=dolcini.it; spf=pass smtp.mailfrom=dolcini.it; dkim=pass header.d=dolcini.it header.i=@dolcini.it header.a=rsa-sha256 header.s=default header.b=EwVro4zd; arc=none smtp.remote-ip=217.194.8.81 Received: from mail11.truemail.it (mail11.truemail.it [217.194.8.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 51807606A88C; Thu, 12 Nov 2026 10:04:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 51807606A88C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=dolcini.it Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=dolcini.it Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=dolcini.it header.i=@dolcini.it header.a=rsa-sha256 header.s=default header.b=EwVro4zd Received: from francesco-nb (93-49-2-63.ip317.fastwebnet.it [93.49.2.63]) by mail11.truemail.it (Postfix) with ESMTPA id 3F8C021447; Thu, 12 Nov 2026 11:04:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolcini.it; s=default; t=1794477892; bh=12FxQz40ZG0aBXbOpbg2g2yd/BGfhAmZAB/dUKb2ZeE=; h=From:To:Subject; b=EwVro4zddjIo4VKA5LMoi5hY6WS6oYjLYIW3pLBAhZEtcrPJL7OG3Gw+6Mgi+ZdbM CH5ZI8CTi+aWldncyyeQd33H9WrPwKL0Z/bQUw9CL/Hw8viEiQwXMxqAuieEU2mWwv VoWZaGMdIjayD37MhMmpD9MI0w28sKu9+YHn6Ymboc4YeFLR84lDJHpzMdegGyAYIS tLm3szk1apuqKYfIlR1M6+611kM5Zi2IgLr8QViCXglUJpaN4jkCvgjYDgONsZMdz1 Mg0Qp7Mv21oOhfYy0UXS10xuQv1Hd8DXOOyBuhENDdbp9z6e4bW1nmIoDkxgevwze7 yq+t72XwHJAOA== Date: Thu, 12 Nov 2026 11:04:48 +0100 From: Francesco Dolcini To: "Peng Fan (OSS)" , regressions@lists.linux.dev Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Saravana Kannan , Sudeep Holla , Hans de Goede , driver-core@lists.linux.dev, linux-kernel@vger.kernel.org, imx@lists.linux.dev, Peng Fan , stable@vger.kernel.org Subject: Re: [PATCH] driver core: hand off fwnode ownership when shared fwnode owner is rejected Message-ID: <20261112100448.GA53281@francesco-nb> References: <20260928-driver-core-v1-1-0846bb8e0f32@nxp.com> X-Mailing-List: driver-core@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260928-driver-core-v1-1-0846bb8e0f32@nxp.com> +regression list Hello, On Mon, Sep 28, 2026 at 07:49:01PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan > > When multiple devices share the same fwnode (e.g. the SCMI bus creates > both "pinctrl" and "pinctrl-imx" devices for SCMI_PROTOCOL_PINCTRL), only > the first device registered becomes the fwnode owner (fwnode->dev, set in > device_add()). If that owner never binds -- for example its driver returns > -ENODEV because it is blocklisted on this SoC, or because its driver is > not compiled in at all -- then driver_bound() is never called for it, so > fwnode_links_purge_suppliers() and fw_devlink_pickup_dangling_consumers() > are never run for the fwnode. The child fwnode supplier links (pin group > nodes such as lpi2c3grp, uart5grp, ...) stay unsatisfied and every > consumer of those child nodes defers probe forever. > > On i.MX95 this manifests as a complete boot failure: the generic "pinctrl" > SCMI device claims fwnode ownership but its driver returns -ENODEV, while > the vendor "pinctrl-imx" device binds successfully. Because > dev->fwnode->dev still points at the rejected "pinctrl" device, > driver_bound() of "pinctrl-imx" skips the supplier purge and dangling > consumer pickup, so all I2C buses, SPI, UART, MMC, USB and PCIe > controllers wait forever for their pinctrl suppliers. > > Fix this in two places: > > 1. In really_probe() failure path: when the driver definitively rejects > a device (-ENODEV / -ENXIO), fw_devlink_release_shared_fwnode() is > called. If the rejected device is the fwnode owner, it either > transfers ownership to an already-bound sibling (and runs the > purge/pickup on its behalf) or clears ownership so the next sibling > to bind can re-acquire it. > > 2. In device_links_driver_bound(): re-acquire the fwnode when it is > unowned (!fwnode->dev) or when the current owner has no driver at > all (!fwnode->dev->driver, meaning the driver was never compiled in > or loaded as a module). This covers the case where probe rejection > never happens because no driver ever matches. > > fwnode->dev is not serialized by a lock; instead every writer only ever > touches a fwnode->dev it already owns (== dev, as device_del() does when > it clears ownership) or one that is currently unowned (== NULL, as > device_add() does when it claims ownership). This patch follows the same > discipline: fw_devlink_release_shared_fwnode() only writes fwnode->dev > when this device is the current owner; device_links_driver_bound() only > claims fwnode->dev when it is NULL or when the current owner has no > driver (and therefore cannot be in the process of binding). > > Fixes: f9aa460672c9 ("driver core: Refactor fw_devlink feature") > Cc: stable@vger.kernel.org > Assisted-by: LLM > Signed-off-by: Peng Fan > --- > This issue is triggered by > aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols") > in linux-next next-20260925. > > But I think this is a fix to > f9aa460672c9 ("driver core: Refactor fw_devlink feature") > > Detailed information could be found in patch commit log. Sudeep's series [1] fixes this in linux-next, but it is not yet in mainline. I'd like to have this tracked so that it is not lost. #regzbot ^introduced: aac4e67d6eb9 #regzbot title: arm_scmi: i.MX95 does not boot, all pinctrl consumers deferred #regzbot fix: pinctrl: imx: Match the standard SCMI pinctrl device #regzbot link: https://lore.kernel.org/all/20261005-scmi_bus_fixes-v3-0-d9bada32ed38@kernel.org/