Message ID | 20240220111044.133776-3-herve.codina@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-72881-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp325293dyc; Tue, 20 Feb 2024 03:12:23 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCURkp11OQN8Ntw2LwT8rgRRZOFQEOn3Dc8VN2RgLDqqXy+aK1pvnNak5HTepV2JVqh2ESreXfd16Z/0Yvt+a6KvLzj7ow== X-Google-Smtp-Source: AGHT+IGXwQD9jem7LqmfUAxPPsC5sCYbYW6TkWodp0XTP/lD4BzpYiF6Hd1PGT3TSM+d0nq19jBT X-Received: by 2002:a17:90a:34cf:b0:299:5b95:cd7d with SMTP id m15-20020a17090a34cf00b002995b95cd7dmr4705956pjf.45.1708427543593; Tue, 20 Feb 2024 03:12:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708427543; cv=pass; d=google.com; s=arc-20160816; b=KI5KrkzpUFLxQJVY3lUkGQ7638Tg8Eo4lTgYqfG48Gz3y1YWrvaNzVcAgDmSV9lWbT Sp3OP//rutQxX/AOnN/HNXkIXMkoXKhYHrK2RzGtsLEyDi/8dHzzThxu2wvMMG1u28Ds sV0fgUF+QpXwOKPfFMPO72Cxk/qhEWq0Dlu8LOW3+rF7/ZiEo8i7My/8eeVj3MVZJkHL +/zeL9a996uDWW+BfG6SjzSoOhrNSFclaGruRoQPbzw0nP4nJtp3+xZqeXrptdxlHoE8 SmWypeD24x+kbMRO3YYibFlmIKpg7KGXOtiC4PNl8zZFlo/1vx+QxRtZFqr6g9LeOOhi Ui7g== 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=eFeqAc0viLZubDduFEQRtTQhhOqlv7YIdJ9vqQOHsWs=; fh=njSy/rlbAoKk1TdE9G+RzNVawG67mOpp31Vpsfilr4g=; b=aWwzKmCQOk/UCQnI38k/Vsc9s6vVBl83RJFsqIHx1hYQGq9nnfD+OEjCfZcnGZspAd kK9vdzGBho50TQij3sj9ixL12dqIpfDbnD0kO7kbugGAqfsKrxtRIZa9JGJWM8rYcE/4 M2JMZuHYVYo3ywCF6+pIyZO1gYidKnFi/ko9IMHocv3M0TG7cT64XN5oDMQWxpelktNT p5P5WQg2vwnyxWp9MvDDmCaxtUhjQekeCEiRH42CO2bpn/sHNlpvccCFLYNX7QDwaqym eBrZ3Czp5pg4Z2OJ2O+p95rqDtRYtKbiC6i3scTDTq5q8rIX2XpY7HNGLwDqKMUi4ePK +Axg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=RKYZaPEJ; arc=pass (i=1 spf=pass spfdomain=bootlin.com dkim=pass dkdomain=bootlin.com dmarc=pass fromdomain=bootlin.com); spf=pass (google.com: domain of linux-kernel+bounces-72881-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-72881-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id mu12-20020a17090b388c00b00298f81cae30si6103383pjb.44.2024.02.20.03.12.23 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Feb 2024 03:12:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-72881-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=RKYZaPEJ; arc=pass (i=1 spf=pass spfdomain=bootlin.com dkim=pass dkdomain=bootlin.com dmarc=pass fromdomain=bootlin.com); spf=pass (google.com: domain of linux-kernel+bounces-72881-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-72881-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 594B9282717 for <ouuuleilei@gmail.com>; Tue, 20 Feb 2024 11:12:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9F24767E62; Tue, 20 Feb 2024 11:11:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="RKYZaPEJ" Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.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 7E9E467C45; Tue, 20 Feb 2024 11:10:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708427461; cv=none; b=jZOee6QQzxXvjw9g4IByYkP0fZOagQIi83ddoHhwyhsWIJeUJxX7ljR/dny9LtAIUSDB2flUZoLr10mFdgcDH+zmvLjqcB8AAlkTP8XR+6vFtYsDkMPwTQYkK+G6ijCLyTZZ1lwhDS1AE8/zPs27XcN2rkytfdq4DClvL1Vwf+8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708427461; c=relaxed/simple; bh=SORknAyK89FTpPMUYDIygldtRacLzHgxp/VDNZfKqJY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Pq3pI8mV6JOKKi8JE4jnvuWrEAox7oCPbV2dIUHEqhaarbl665BPh1++dRzH06xNGBdky1Lzeno1su7g2H7xlJWZLvLA+WuXkf+/MBrTmpHb2syIMKyzK9VtcPEzluCQugaVxx+pViJ4sF7tnGlZfRMIPfxgUbui68JmEgk/g/U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=RKYZaPEJ; arc=none smtp.client-ip=217.70.183.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPA id 4906C1BF209; Tue, 20 Feb 2024 11:10:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1708427456; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eFeqAc0viLZubDduFEQRtTQhhOqlv7YIdJ9vqQOHsWs=; b=RKYZaPEJC+YwyWaq+Vd6q3jwz1J1O+djnucz/L2Nc/pCdc+LpnnqKGweCyYqqab0hxw/zo llSi0TCWhhLFGQUF7veRhkz1jHCHvkbEdeFIk6M2w8FDQnn45TApkJifS/7WcX729LnMM4 RmQnIqzu+OARccUzXZasSo8HtO5/z5roV8ztrMgx1HneWTrD3kRc+8NJd9bABDhLwochuR +H3HG11tkb74Ei4sWNoxk+sxr0WeVyBecQim9ytbovIkEeYXqXwwjJdb8J85gmfnSo9YIF OoUGO+0QjNoKtbzy10C7CpDmQfPdQQWLk3zFktun/qPy2Ast6p9au2TwSEcEXw== From: Herve Codina <herve.codina@bootlin.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Shawn Guo <shawnguo@kernel.org>, Saravana Kannan <saravanak@google.com>, Wolfram Sang <wsa@kernel.org>, Mark Brown <broonie@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be>, Rob Herring <robh@kernel.org>, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Luca Ceresoli <luca.ceresoli@bootlin.com>, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, Herve Codina <herve.codina@bootlin.com>, stable@vger.kernel.org Subject: [PATCH 2/2] of: property: fw_devlink: Fix links to supplier when created from phandles Date: Tue, 20 Feb 2024 12:10:37 +0100 Message-ID: <20240220111044.133776-3-herve.codina@bootlin.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240220111044.133776-1-herve.codina@bootlin.com> References: <20240220111044.133776-1-herve.codina@bootlin.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-GND-Sasl: herve.codina@bootlin.com X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791416120302922642 X-GMAIL-MSGID: 1791416120302922642 |
Series |
devlink: Take care of FWNODE_FLAG_NOT_DEVICE in case of DT overlays
|
|
Commit Message
Herve Codina
Feb. 20, 2024, 11:10 a.m. UTC
Since commit 1a50d9403fb9 ("treewide: Fix probing of devices in DT
overlays"), when using device-tree overlays, the FWNODE_FLAG_NOT_DEVICE
is set on each overlay nodes. This flag is cleared when a struct device
is actually created for the DT node.
Also, when a device is created, the device DT node is parsed for known
phandle and devlinks consumer/supplier links are created between the
device (consumer) and the devices referenced by phandles (suppliers).
As these supplier device can have a struct device not already created,
the FWNODE_FLAG_NOT_DEVICE can be set for suppliers and leads the
devlink supplier point to the device's parent instead of the device
itself.
Avoid this situation clearing the supplier FWNODE_FLAG_NOT_DEVICE just
before the devlink creation if a device is supposed to be created and
handled later in the process.
Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays")
Cc: <stable@vger.kernel.org>
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
drivers/of/property.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
Comments
On Tue, Feb 20, 2024 at 3:10 AM Herve Codina <herve.codina@bootlin.com> wrote: > > Since commit 1a50d9403fb9 ("treewide: Fix probing of devices in DT > overlays"), when using device-tree overlays, the FWNODE_FLAG_NOT_DEVICE > is set on each overlay nodes. This flag is cleared when a struct device > is actually created for the DT node. > Also, when a device is created, the device DT node is parsed for known > phandle and devlinks consumer/supplier links are created between the > device (consumer) and the devices referenced by phandles (suppliers). > As these supplier device can have a struct device not already created, > the FWNODE_FLAG_NOT_DEVICE can be set for suppliers and leads the > devlink supplier point to the device's parent instead of the device > itself. > > Avoid this situation clearing the supplier FWNODE_FLAG_NOT_DEVICE just > before the devlink creation if a device is supposed to be created and > handled later in the process. > > Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays") > Cc: <stable@vger.kernel.org> > Signed-off-by: Herve Codina <herve.codina@bootlin.com> > --- > drivers/of/property.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/of/property.c b/drivers/of/property.c > index 641a40cf5cf3..ff5cac477dbe 100644 > --- a/drivers/of/property.c > +++ b/drivers/of/property.c > @@ -1097,6 +1097,7 @@ static void of_link_to_phandle(struct device_node *con_np, > struct device_node *sup_np) > { > struct device_node *tmp_np = of_node_get(sup_np); > + struct fwnode_handle *sup_fwnode; > > /* Check that sup_np and its ancestors are available. */ > while (tmp_np) { > @@ -1113,7 +1114,20 @@ static void of_link_to_phandle(struct device_node *con_np, > tmp_np = of_get_next_parent(tmp_np); > } > > - fwnode_link_add(of_fwnode_handle(con_np), of_fwnode_handle(sup_np)); > + /* > + * In case of overlays, the fwnode are added with FWNODE_FLAG_NOT_DEVICE > + * flag set. A node can have a phandle that references an other node > + * added by the overlay. > + * Clear the supplier's FWNODE_FLAG_NOT_DEVICE so that fw_devlink links > + * to this supplier instead of linking to its parent. > + */ > + sup_fwnode = of_fwnode_handle(sup_np); > + if (sup_fwnode->flags & FWNODE_FLAG_NOT_DEVICE) { > + if (of_property_present(sup_np, "compatible") && > + of_device_is_available(sup_np)) > + sup_fwnode->flags &= ~FWNODE_FLAG_NOT_DEVICE; > + } > + fwnode_link_add(of_fwnode_handle(con_np), sup_fwnode); Nack. of_link_to_phandle() doesn't care about any of the fwnode flags. It just creates links between the consumer and supplier nodes. Don't add more intelligence into it please. Also, "compatible" doesn't really guarantee device creation and you can have devices created out of nodes with no compatible property. I finally managed to get away from looking for the "compatible" property. So, let's not add back a dependency on that property please. Can you please give a real example where you are hitting this? I have some thoughts on solutions, but I want to understand the issue fully before I make suggestions. Thanks, Saravana
Hi Saravana, On Tue, 20 Feb 2024 18:40:40 -0800 Saravana Kannan <saravanak@google.com> wrote: > On Tue, Feb 20, 2024 at 3:10 AM Herve Codina <herve.codina@bootlin.com> wrote: > > > > Since commit 1a50d9403fb9 ("treewide: Fix probing of devices in DT > > overlays"), when using device-tree overlays, the FWNODE_FLAG_NOT_DEVICE > > is set on each overlay nodes. This flag is cleared when a struct device > > is actually created for the DT node. > > Also, when a device is created, the device DT node is parsed for known > > phandle and devlinks consumer/supplier links are created between the > > device (consumer) and the devices referenced by phandles (suppliers). > > As these supplier device can have a struct device not already created, > > the FWNODE_FLAG_NOT_DEVICE can be set for suppliers and leads the > > devlink supplier point to the device's parent instead of the device > > itself. > > > > Avoid this situation clearing the supplier FWNODE_FLAG_NOT_DEVICE just > > before the devlink creation if a device is supposed to be created and > > handled later in the process. > > > > Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays") > > Cc: <stable@vger.kernel.org> > > Signed-off-by: Herve Codina <herve.codina@bootlin.com> > > --- > > drivers/of/property.c | 16 +++++++++++++++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c > > index 641a40cf5cf3..ff5cac477dbe 100644 > > --- a/drivers/of/property.c > > +++ b/drivers/of/property.c > > @@ -1097,6 +1097,7 @@ static void of_link_to_phandle(struct device_node *con_np, > > struct device_node *sup_np) > > { > > struct device_node *tmp_np = of_node_get(sup_np); > > + struct fwnode_handle *sup_fwnode; > > > > /* Check that sup_np and its ancestors are available. */ > > while (tmp_np) { > > @@ -1113,7 +1114,20 @@ static void of_link_to_phandle(struct device_node *con_np, > > tmp_np = of_get_next_parent(tmp_np); > > } > > > > - fwnode_link_add(of_fwnode_handle(con_np), of_fwnode_handle(sup_np)); > > + /* > > + * In case of overlays, the fwnode are added with FWNODE_FLAG_NOT_DEVICE > > + * flag set. A node can have a phandle that references an other node > > + * added by the overlay. > > + * Clear the supplier's FWNODE_FLAG_NOT_DEVICE so that fw_devlink links > > + * to this supplier instead of linking to its parent. > > + */ > > + sup_fwnode = of_fwnode_handle(sup_np); > > + if (sup_fwnode->flags & FWNODE_FLAG_NOT_DEVICE) { > > + if (of_property_present(sup_np, "compatible") && > > + of_device_is_available(sup_np)) > > + sup_fwnode->flags &= ~FWNODE_FLAG_NOT_DEVICE; > > + } > > + fwnode_link_add(of_fwnode_handle(con_np), sup_fwnode); > > Nack. > > of_link_to_phandle() doesn't care about any of the fwnode flags. It > just creates links between the consumer and supplier nodes. Don't add > more intelligence into it please. Also, "compatible" doesn't really > guarantee device creation and you can have devices created out of > nodes with no compatible property. I finally managed to get away from > looking for the "compatible" property. So, let's not add back a > dependency on that property please. > > Can you please give a real example where you are hitting this? I have > some thoughts on solutions, but I want to understand the issue fully > before I make suggestions. > I detected the issue with this overlay: --- 8< --- &{/} { reg_dock_sys_3v3: regulator-dock-sys-3v3 { compatible = "regulator-fixed"; regulator-name = "DOCK_SYS_3V3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; gpios = <&tca6424_dock_1 5 GPIO_ACTIVE_HIGH>; // DOCK_SYS3V3_EN enable-active-high; regulator-always-on; }; }; &i2c5 { tca6424_dock_1: gpio@22 { compatible = "ti,tca6424"; reg = <0x22>; gpio-controller; #gpio-cells = <2>; interrupt-parent = <&gpio4>; interrupts = <1 IRQ_TYPE_EDGE_FALLING>; interrupt-controller; #interrupt-cells = <2>; vcc-supply = <®_dock_ctrl_3v3>; }; }; --- 8< --- The regulator uses a gpio. The supplier for the regulator was not the gpio chip (gpio@22) but the i2c bus. I first tried to clear always the flag in of_link_to_phandle() without any check to a "compatible" string and in that case, I broke pinctrl. All devices were waiting for the pinctrl they used (child of pinctrl device node) even if the pinctrl driver was bound to the device. For pinctrl, the DT structure looks like the following: --- 8< --- { ... pinctrl@1234 { reg = <1234>; compatible = "vendor,chip"; pinctrl_some_device: grp { fsl,pins = < ... >; }; }; some_device@4567 { compablile = "foo,bar"; reg = <4567>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_some_device>; ... }; }; --- 8< --- In that case the link related to pinctrl for some_device needs to be to the 'pinctrl_some_device' node parent (i.e. the pinctrl@1234 node). Best regards, Hervé
diff --git a/drivers/of/property.c b/drivers/of/property.c index 641a40cf5cf3..ff5cac477dbe 100644 --- a/drivers/of/property.c +++ b/drivers/of/property.c @@ -1097,6 +1097,7 @@ static void of_link_to_phandle(struct device_node *con_np, struct device_node *sup_np) { struct device_node *tmp_np = of_node_get(sup_np); + struct fwnode_handle *sup_fwnode; /* Check that sup_np and its ancestors are available. */ while (tmp_np) { @@ -1113,7 +1114,20 @@ static void of_link_to_phandle(struct device_node *con_np, tmp_np = of_get_next_parent(tmp_np); } - fwnode_link_add(of_fwnode_handle(con_np), of_fwnode_handle(sup_np)); + /* + * In case of overlays, the fwnode are added with FWNODE_FLAG_NOT_DEVICE + * flag set. A node can have a phandle that references an other node + * added by the overlay. + * Clear the supplier's FWNODE_FLAG_NOT_DEVICE so that fw_devlink links + * to this supplier instead of linking to its parent. + */ + sup_fwnode = of_fwnode_handle(sup_np); + if (sup_fwnode->flags & FWNODE_FLAG_NOT_DEVICE) { + if (of_property_present(sup_np, "compatible") && + of_device_is_available(sup_np)) + sup_fwnode->flags &= ~FWNODE_FLAG_NOT_DEVICE; + } + fwnode_link_add(of_fwnode_handle(con_np), sup_fwnode); } /**