Message ID | 20230204133040.1236799-2-treapking@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1352240wrn; Sat, 4 Feb 2023 05:32:22 -0800 (PST) X-Google-Smtp-Source: AK7set/E+8DJzXx2beqlcVrX1NTTHdSYaIw0uNa6vDlneBkJWM+8H9Yv904HSfA5WmGsw+QLDScj X-Received: by 2002:a05:6a00:230c:b0:56c:232e:395e with SMTP id h12-20020a056a00230c00b0056c232e395emr16311356pfh.15.1675517541918; Sat, 04 Feb 2023 05:32:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675517541; cv=none; d=google.com; s=arc-20160816; b=L+10iLPKE8TwoEgqv08hOngn2b95VdiFWIZ7uztKu2Fgjg1Uk/ZBXGw1zjz0Cg+d/p 3x+7NLaSXrEFVmFvf0oKAxWokx+CgHBFZxufscncgwro/ROKg/Y1ETEurKEDol1FwKRe tF/iP5aWi6IlpA7WSGtk6szbu8/xwu+8IQBDO5Sp7Ljwme3ne4J0U4N6Z+G6pC4vEHBY HkVTIAUsfrJ0CtJF8BIxxFucHKlOBn5Ihd9ZKTa1u0j97iUBSk6m1kG/qGL2UVtOLlhh SPz051cESWnVUl9DzmI8YjvE25HImr/vdpj+VpG3ukoO6j+M9Y3Tk7YhxOkatwiJyNEe FO3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=R9iPc9yhVkUofB90tWrcvmiWB1xZN7L6aBmsKjdgh6c=; b=Ly/VUgvGPgrHs1xcsqaBLQRE3Vgl46Q88CjVMEyjfEH0o3jFCRTUC3ZXkNU/YAy/pD aQ/UW9tfQCfs2Pd/kthozcxU16rfIDbzL0kCbvaBI9XKh6crj0y7CPdh7TMjk1anEa9m EPUTtD3bKG+3bQn+WmgN38uUIS2kR5AjIitDdJCKHuXXqgrVEeg0q+IPBJJ6pQBknwKb HqPQtPXx8uhYr8KSaAvAuCBzOUbl8Eotl11gkt7lC9628nVlFibGONyV2aGlrlFjrtyU Hv454TCk7aG9RKfJK5xM83i6s3g96pzrWqK9DFTHSwNYDSsAz0i39/kF0u5oPvNfk9mr 0fAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="MmH3x/xM"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r19-20020aa79633000000b0059d554d67ccsi413396pfg.183.2023.02.04.05.32.08; Sat, 04 Feb 2023 05:32:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="MmH3x/xM"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232414AbjBDNbE (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Sat, 4 Feb 2023 08:31:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbjBDNbB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 4 Feb 2023 08:31:01 -0500 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 151F336FC3 for <linux-kernel@vger.kernel.org>; Sat, 4 Feb 2023 05:30:57 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id s13so3778094pgc.10 for <linux-kernel@vger.kernel.org>; Sat, 04 Feb 2023 05:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=R9iPc9yhVkUofB90tWrcvmiWB1xZN7L6aBmsKjdgh6c=; b=MmH3x/xM62zRTISXSedEvzRlaMSI+F8Qma5UmquaxSwlvv6YsPZ+8h1xP3F7M3D1Df QCXfWhoJOdvLdzh0hNXPqpam40tk12C8NpO5zRmImK/NmNXbcxJ9dSbO/w8oKgfe20ZG QRCqSAG2eCerNb0ZmsoC546f3eCSx0931M3tA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=R9iPc9yhVkUofB90tWrcvmiWB1xZN7L6aBmsKjdgh6c=; b=XOiRTIX9BzlAUUufhtOlBS0QG4qVMxS8YoBQFDmAaJ+nJRYHtoY6sob5NHXTYfBJ2q PdBUlwY6+/9/bIew1nZtigg9VFOYnnQ4cSNhGXL4HZPZ5y1KrUvzWlCoYBYG8DIXJZod 1Q4oUPfXv+CJLF0gtaS5aN0cjUrNRXG0DEbnI0DVZcJnXUlc00N9YtlUN5y8JHKT4cMl 1Y+IYwXqEcizv63JAfIk9iktb5F0zGz1VXPHBtPH389tkGGAzSI2tDLhfWZi+h1FvaU4 Dly2Oy5P29bGDMOFb1DHydO4lSddxaQHsQECBl9tCuzFpTl7LoxqKxA8dxsVf5PMqgTf fdsg== X-Gm-Message-State: AO0yUKVIFeWsLcUZvWqoPWtHr0x7xP+NpiGcl6OiVM/OLqKo0IllBBdY c28c4Jn1b76nj9F1AlVQCPSomQ== X-Received: by 2002:a05:6a00:882:b0:593:96a2:d60a with SMTP id q2-20020a056a00088200b0059396a2d60amr18474657pfj.30.1675517456766; Sat, 04 Feb 2023 05:30:56 -0800 (PST) Received: from treapking.tpe.corp.google.com ([2401:fa00:1:10:c1ad:2bdc:7b5a:72e3]) by smtp.gmail.com with ESMTPSA id 144-20020a621596000000b00593ce7ebbaasm3655639pfv.184.2023.02.04.05.30.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Feb 2023 05:30:56 -0800 (PST) From: Pin-yen Lin <treapking@chromium.org> To: Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <robert.foss@linaro.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Daniel Scally <djrscally@gmail.com>, Heikki Krogerus <heikki.krogerus@linux.intel.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J . Wysocki" <rafael@kernel.org>, Prashant Malani <pmalani@chromium.org>, Benson Leung <bleung@chromium.org>, Guenter Roeck <groeck@chromium.org> Cc: linux-kernel@vger.kernel.org, =?utf-8?q?N=C3=ADcolas_F_=2E_R_=2E_A_=2E_P?= =?utf-8?q?rado?= <nfraprado@collabora.com>, Hsin-Yi Wang <hsinyi@chromium.org>, devicetree@vger.kernel.org, Pin-yen Lin <treapking@chromium.org>, Allen Chen <allen.chen@ite.com.tw>, Lyude Paul <lyude@redhat.com>, linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org, Marek Vasut <marex@denx.de>, Xin Ji <xji@analogixsemi.com>, Stephen Boyd <swboyd@chromium.org>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Thomas Zimmermann <tzimmermann@suse.de>, Javier Martinez Canillas <javierm@redhat.com>, chrome-platform@lists.linux.dev, Chen-Yu Tsai <wenst@chromium.org> Subject: [PATCH v11 1/9] device property: Add remote endpoint to devcon matcher Date: Sat, 4 Feb 2023 21:30:32 +0800 Message-Id: <20230204133040.1236799-2-treapking@chromium.org> X-Mailer: git-send-email 2.39.1.519.gcb327c4b5f-goog In-Reply-To: <20230204133040.1236799-1-treapking@chromium.org> References: <20230204133040.1236799-1-treapking@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756907482098395272?= X-GMAIL-MSGID: =?utf-8?q?1756907482098395272?= |
Series |
Register Type-C mode-switch in DP bridge endpoints
|
|
Commit Message
Pin-yen Lin
Feb. 4, 2023, 1:30 p.m. UTC
From: Prashant Malani <pmalani@chromium.org> When searching the device graph for device matches, check the remote-endpoint itself for a match. Some drivers register devices for individual endpoints. This allows the matcher code to evaluate those for a match too, instead of only looking at the remote parent devices. This is required when a device supports two mode switches in its endpoints, so we can't simply register the mode switch with the parent node. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> --- Changes in v11: - Added missing fwnode_handle_put in drivers/base/property.c Changes in v10: - Collected Reviewed-by and Tested-by tags Changes in v6: - New in v6 drivers/base/property.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Comments
Hi Pin-yen, On Sat, Feb 04, 2023 at 09:30:32PM +0800, Pin-yen Lin wrote: > From: Prashant Malani <pmalani@chromium.org> > > When searching the device graph for device matches, check the > remote-endpoint itself for a match. > > Some drivers register devices for individual endpoints. This allows > the matcher code to evaluate those for a match too, instead > of only looking at the remote parent devices. This is required when a > device supports two mode switches in its endpoints, so we can't simply > register the mode switch with the parent node. > > Signed-off-by: Prashant Malani <pmalani@chromium.org> > Signed-off-by: Pin-yen Lin <treapking@chromium.org> > Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> > Tested-by: Chen-Yu Tsai <wenst@chromium.org> Thanks for the update. I intended to give my Reviewed-by: but there's something still needs to be addressed. See below. > > --- > > Changes in v11: > - Added missing fwnode_handle_put in drivers/base/property.c > > Changes in v10: > - Collected Reviewed-by and Tested-by tags > > Changes in v6: > - New in v6 > > drivers/base/property.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/drivers/base/property.c b/drivers/base/property.c > index 2a5a37fcd998..e6f915b72eb7 100644 > --- a/drivers/base/property.c > +++ b/drivers/base/property.c > @@ -1223,6 +1223,22 @@ static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode, > break; > } > > + /* > + * Some drivers may register devices for endpoints. Check > + * the remote-endpoints for matches in addition to the remote > + * port parent. > + */ > + node = fwnode_graph_get_remote_endpoint(ep); Here fwnode_graph_get_remote_endpoint() returns an endpoint... > + if (fwnode_device_is_available(node)) { and you're calling fwnode_device_is_available() on the endpoint node, which always returns true. Shouldn't you call this on the device node instead? What about match() below? > + ret = match(node, con_id, data); > + if (ret) { > + if (matches) > + matches[count] = ret; > + count++; > + } > + } > + fwnode_handle_put(node); > + > node = fwnode_graph_get_remote_port_parent(ep); > if (!fwnode_device_is_available(node)) { > fwnode_handle_put(node);
Hi Sakari, Thanks for the review. On Mon, Feb 6, 2023 at 5:11 AM Sakari Ailus <sakari.ailus@linux.intel.com> wrote: > > Hi Pin-yen, > > On Sat, Feb 04, 2023 at 09:30:32PM +0800, Pin-yen Lin wrote: > > From: Prashant Malani <pmalani@chromium.org> > > > > When searching the device graph for device matches, check the > > remote-endpoint itself for a match. > > > > Some drivers register devices for individual endpoints. This allows > > the matcher code to evaluate those for a match too, instead > > of only looking at the remote parent devices. This is required when a > > device supports two mode switches in its endpoints, so we can't simply > > register the mode switch with the parent node. > > > > Signed-off-by: Prashant Malani <pmalani@chromium.org> > > Signed-off-by: Pin-yen Lin <treapking@chromium.org> > > Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> > > Tested-by: Chen-Yu Tsai <wenst@chromium.org> > > Thanks for the update. > > I intended to give my Reviewed-by: but there's something still needs to be > addressed. See below. > > > > > --- > > > > Changes in v11: > > - Added missing fwnode_handle_put in drivers/base/property.c > > > > Changes in v10: > > - Collected Reviewed-by and Tested-by tags > > > > Changes in v6: > > - New in v6 > > > > drivers/base/property.c | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/drivers/base/property.c b/drivers/base/property.c > > index 2a5a37fcd998..e6f915b72eb7 100644 > > --- a/drivers/base/property.c > > +++ b/drivers/base/property.c > > @@ -1223,6 +1223,22 @@ static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode, > > break; > > } > > > > + /* > > + * Some drivers may register devices for endpoints. Check > > + * the remote-endpoints for matches in addition to the remote > > + * port parent. > > + */ > > + node = fwnode_graph_get_remote_endpoint(ep); > > Here fwnode_graph_get_remote_endpoint() returns an endpoint... > > > + if (fwnode_device_is_available(node)) { > > and you're calling fwnode_device_is_available() on the endpoint node, which > always returns true. > > Shouldn't you call this on the device node instead? What about match() > below? Yes we should have checked the availability on the device node itself instead of the endpoint node. But regarding the match() call, we need to call it with the endpoint node because that's where we put the "mode-switch" properties and register the mode switches on. We can't use the device node because we want to register two mode switches for the same device node. Regards, Pin-yen > > > + ret = match(node, con_id, data); > > + if (ret) { > > + if (matches) > > + matches[count] = ret; > > + count++; > > + } > > + } > > + fwnode_handle_put(node); > > + > > node = fwnode_graph_get_remote_port_parent(ep); > > if (!fwnode_device_is_available(node)) { > > fwnode_handle_put(node); > > -- > Kind regards, > > Sakari Ailus
Hi Pin-yen, On Thu, Feb 09, 2023 at 12:28:33PM +0800, Pin-yen Lin wrote: > Hi Sakari, > > Thanks for the review. > > On Mon, Feb 6, 2023 at 5:11 AM Sakari Ailus > <sakari.ailus@linux.intel.com> wrote: > > > > Hi Pin-yen, > > > > On Sat, Feb 04, 2023 at 09:30:32PM +0800, Pin-yen Lin wrote: > > > From: Prashant Malani <pmalani@chromium.org> > > > > > > When searching the device graph for device matches, check the > > > remote-endpoint itself for a match. > > > > > > Some drivers register devices for individual endpoints. This allows > > > the matcher code to evaluate those for a match too, instead > > > of only looking at the remote parent devices. This is required when a > > > device supports two mode switches in its endpoints, so we can't simply > > > register the mode switch with the parent node. > > > > > > Signed-off-by: Prashant Malani <pmalani@chromium.org> > > > Signed-off-by: Pin-yen Lin <treapking@chromium.org> > > > Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> > > > Tested-by: Chen-Yu Tsai <wenst@chromium.org> > > > > Thanks for the update. > > > > I intended to give my Reviewed-by: but there's something still needs to be > > addressed. See below. > > > > > > > > --- > > > > > > Changes in v11: > > > - Added missing fwnode_handle_put in drivers/base/property.c > > > > > > Changes in v10: > > > - Collected Reviewed-by and Tested-by tags > > > > > > Changes in v6: > > > - New in v6 > > > > > > drivers/base/property.c | 16 ++++++++++++++++ > > > 1 file changed, 16 insertions(+) > > > > > > diff --git a/drivers/base/property.c b/drivers/base/property.c > > > index 2a5a37fcd998..e6f915b72eb7 100644 > > > --- a/drivers/base/property.c > > > +++ b/drivers/base/property.c > > > @@ -1223,6 +1223,22 @@ static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode, > > > break; > > > } > > > > > > + /* > > > + * Some drivers may register devices for endpoints. Check > > > + * the remote-endpoints for matches in addition to the remote > > > + * port parent. > > > + */ > > > + node = fwnode_graph_get_remote_endpoint(ep); > > > > Here fwnode_graph_get_remote_endpoint() returns an endpoint... > > > > > + if (fwnode_device_is_available(node)) { > > > > and you're calling fwnode_device_is_available() on the endpoint node, which > > always returns true. > > > > Shouldn't you call this on the device node instead? What about match() > > below? > > Yes we should have checked the availability on the device node itself > instead of the endpoint node. But regarding the match() call, we need > to call it with the endpoint node because that's where we put the > "mode-switch" properties and register the mode switches on. We can't > use the device node because we want to register two mode switches for > the same device node. Ok. I think it should be documented for both fwnode_connection_find_match() and fwnode_connection_find_matches() may then be also called with the endpoint node.
diff --git a/drivers/base/property.c b/drivers/base/property.c index 2a5a37fcd998..e6f915b72eb7 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -1223,6 +1223,22 @@ static unsigned int fwnode_graph_devcon_matches(struct fwnode_handle *fwnode, break; } + /* + * Some drivers may register devices for endpoints. Check + * the remote-endpoints for matches in addition to the remote + * port parent. + */ + node = fwnode_graph_get_remote_endpoint(ep); + if (fwnode_device_is_available(node)) { + ret = match(node, con_id, data); + if (ret) { + if (matches) + matches[count] = ret; + count++; + } + } + fwnode_handle_put(node); + node = fwnode_graph_get_remote_port_parent(ep); if (!fwnode_device_is_available(node)) { fwnode_handle_put(node);