Message ID | 20221124102056.393220-3-treapking@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp3305308wrr; Thu, 24 Nov 2022 02:22:44 -0800 (PST) X-Google-Smtp-Source: AA0mqf7QRvzv1GB2gtdogle4MKSbzoB3M3TUAXLF2HTO9s0jnCmCvnP7GTaAQyE1JkhHOBUXHhzn X-Received: by 2002:a17:906:28d1:b0:78d:bc56:8f22 with SMTP id p17-20020a17090628d100b0078dbc568f22mr25705220ejd.256.1669285364658; Thu, 24 Nov 2022 02:22:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669285364; cv=none; d=google.com; s=arc-20160816; b=J2z37xjHxes2i88QtRihWHfKmBVsA4caiCJ8eWZ7VYV8td2kv2VxMlmXfDbJuUU3p+ WHN9RqBJLt2gHVslkeWJksEzYovWTNPPLlDctIBMyzDBUQF8ZFqCiAGviJxUV3ly8Y/t 6sQWWJgBFv4YQuGTqT8nPGO9sf/hClSX9LTvtMC66v6tk9IQZvd9S7EBovt+0339xZsu Gh6fsypbTwB0wU1ydXt8DOjCmsnBMD3RaNYFyftEalLWnsxyFZXAXjpk2BK9viQdX3Os BwbHgRKYOjKtciw7qgj3ys+G6QmXy4iprZ2mHBFoNtdc8KW6OH6YZnMnxUUgLu9AUR5v pJlQ== 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=j3Zp7oNSpvCJzlmrAgiA+eyc89NALrCy35DmIPjsn8o=; b=FaB2/ZRkvPCC1mjoLUWCLypJXMqYvoEoYwMhY5xiCSmBMp1D96hrICdvxrM5hhyZGM P7v4GsOVo8iD7xlpwLNSr3SVM6oZiOLt0byVlejyckmi/m6rN5LsOKWxKUXIgUcl0VH0 JmQaPm4obT6WHOCQ/5A9hPcjQhux9Ptld+XVfpJ7XOx1jcLaWWgeDKVJYYUcqTswOja+ 5OdR2zfaw8Ux1gCW4vyK1z88Ks+6rNLyaKCCgt1nHWI5Ks7qOFOgQ6WZsZxA85mBRwJC ONLXQ/hlHZNx7jKvrt8DdgR8im1Flp2znAUYlBA7aBlrtUM5E2R9uRqslPkFgevFx4O8 a1aQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Lk6A3X3u; 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 hp40-20020a1709073e2800b0078b96068bc0si220547ejc.79.2022.11.24.02.22.19; Thu, 24 Nov 2022 02:22:44 -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=Lk6A3X3u; 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 S229870AbiKXKVk (ORCPT <rfc822;fengqi706@gmail.com> + 99 others); Thu, 24 Nov 2022 05:21:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229869AbiKXKVZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 24 Nov 2022 05:21:25 -0500 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D39614FEDB for <linux-kernel@vger.kernel.org>; Thu, 24 Nov 2022 02:21:21 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id p12so1108028plq.4 for <linux-kernel@vger.kernel.org>; Thu, 24 Nov 2022 02:21:21 -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=j3Zp7oNSpvCJzlmrAgiA+eyc89NALrCy35DmIPjsn8o=; b=Lk6A3X3u7rHOEkHOKdmz7Rf/XoRmo/K4/VfJsj8Om775/vkojm7XMlKACeEPdtGuaY GWc3uQh8uXQFtaJdIUpElGlC0FwjCX/fGyfhcBNnkoABKE+H+lRGtSCr6xHwihfNhdnD YH1yIBafS0Aw0dZHXl5eRfe/hATI+Ef9EbYm0= 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=j3Zp7oNSpvCJzlmrAgiA+eyc89NALrCy35DmIPjsn8o=; b=h6UofC6psPd6iLNIrcyeZOuB2IldpAanPxB27jBTpuBgTBsFzWowvJwYHTzFftGz0b xmeadWzMTR2Jk3hdQQUhVqFj0AUX/KfeuMitR5dmUMcbQ6wQQS6ruHb/CtVpENnRw/0i ciNDKDenkZ6pUMyXfvu/osjBlZsWu3cfZ7U2xihZZvuQhgNI0OQtgX/wrLQokLSfmyPp 4kiEGB4I7ifNsO4yUObQ6LQ+hQg8T0CuU/a9OS6MY8I3uH6EOeW6HaHXpRnkWVpHc/cq yYt5VvzhCiaz/fPDxM4EV0TcfK+L0UDJfNg5zG+9faKeLQC3tYSmcXADnssMo1PlT+Bw SJ8g== X-Gm-Message-State: ANoB5plNTdeVOFSg7IabzLv8FRswQsz5VZY1fG+1cfzdmo5CWy3WLn1I bx2VzqTPSp97keDia7HaUYwPaA== X-Received: by 2002:a17:90a:448a:b0:218:48f3:2e48 with SMTP id t10-20020a17090a448a00b0021848f32e48mr34222110pjg.36.1669285280659; Thu, 24 Nov 2022 02:21:20 -0800 (PST) Received: from treapking.tpe.corp.google.com ([2401:fa00:1:10:d446:708:8556:dfee]) by smtp.gmail.com with ESMTPSA id t123-20020a625f81000000b005747b59fc54sm854584pfb.172.2022.11.24.02.21.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Nov 2022 02:21:20 -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: Javier Martinez Canillas <javierm@redhat.com>, Stephen Boyd <swboyd@chromium.org>, dri-devel@lists.freedesktop.org, Hsin-Yi Wang <hsinyi@chromium.org>, Thomas Zimmermann <tzimmermann@suse.de>, devicetree@vger.kernel.org, Pin-yen Lin <treapking@chromium.org>, chrome-platform@lists.linux.dev, linux-acpi@vger.kernel.org, Marek Vasut <marex@denx.de>, Xin Ji <xji@analogixsemi.com>, Lyude Paul <lyude@redhat.com>, =?utf-8?q?N=C3=ADcolas_F_=2E_R_=2E_A_=2E_Pra?= =?utf-8?q?do?= <nfraprado@collabora.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, linux-kernel@vger.kernel.org, Allen Chen <allen.chen@ite.com.tw> Subject: [PATCH v6 2/7] platform/chrome: cros_ec_typec: Purge blocking switch devlinks Date: Thu, 24 Nov 2022 18:20:51 +0800 Message-Id: <20221124102056.393220-3-treapking@chromium.org> X-Mailer: git-send-email 2.38.1.584.g0f3c55d4c2-goog In-Reply-To: <20221124102056.393220-1-treapking@chromium.org> References: <20221124102056.393220-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=ham 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?1750372570325601009?= X-GMAIL-MSGID: =?utf-8?q?1750372570325601009?= |
Series |
Register Type-C mode-switch in DP bridge endpoints
|
|
Commit Message
Pin-yen Lin
Nov. 24, 2022, 10:20 a.m. UTC
From: Prashant Malani <pmalani@chromium.org> When using OF graph, the fw_devlink code will create links between the individual port driver (cros-ec-typec here) and the parent device for a Type-C switch (like mode-switch). Since the mode-switch will in turn have the usb-c-connector (i.e the child of the port driver) as a supplier, fw_devlink will not be able to resolve the cyclic dependency correctly. As a result, the mode-switch driver probe() never runs, so mode-switches are never registered. Because of that, the port driver probe constantly fails with -EPROBE_DEFER, because the Type-C connector class requires all switch devices to be registered prior to port registration. To break this deadlock and allow the mode-switch registration to occur, purge all the usb-c-connector nodes' absent suppliers. This eliminates the connector as a supplier for a switch and allows it to be probed. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Pin-yen Lin <treapking@chromium.org> --- Changes in v6: - New in v6 drivers/platform/chrome/cros_ec_typec.c | 9 +++++++++ 1 file changed, 9 insertions(+)
Comments
On Thu, Nov 24, 2022 at 06:20:51PM +0800, Pin-yen Lin wrote: > From: Prashant Malani <pmalani@chromium.org> > > When using OF graph, the fw_devlink code will create links between the > individual port driver (cros-ec-typec here) and the parent device for > a Type-C switch (like mode-switch). Since the mode-switch will in turn > have the usb-c-connector (i.e the child of the port driver) as a > supplier, fw_devlink will not be able to resolve the cyclic dependency > correctly. > > As a result, the mode-switch driver probe() never runs, so mode-switches > are never registered. Because of that, the port driver probe constantly > fails with -EPROBE_DEFER, because the Type-C connector class requires all > switch devices to be registered prior to port registration. > > To break this deadlock and allow the mode-switch registration to occur, > purge all the usb-c-connector nodes' absent suppliers. This eliminates > the connector as a supplier for a switch and allows it to be probed. ... > + /* > + * OF graph may have set up some device links with switches, since connectors have their > + * own compatible. Purge these to avoid a deadlock in switch probe (the switch mistakenly > + * assumes the connector is a supplier). > + */ A bit too long lines... > + if (dev->of_node) Why do you need this check? > + device_for_each_child_node(dev, fwnode) > + fw_devlink_purge_absent_suppliers(fwnode);
Hi Andy, On Thu, Nov 24, 2022 at 8:25 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Thu, Nov 24, 2022 at 06:20:51PM +0800, Pin-yen Lin wrote: > > From: Prashant Malani <pmalani@chromium.org> > > > > When using OF graph, the fw_devlink code will create links between the > > individual port driver (cros-ec-typec here) and the parent device for > > a Type-C switch (like mode-switch). Since the mode-switch will in turn > > have the usb-c-connector (i.e the child of the port driver) as a > > supplier, fw_devlink will not be able to resolve the cyclic dependency > > correctly. > > > > As a result, the mode-switch driver probe() never runs, so mode-switches > > are never registered. Because of that, the port driver probe constantly > > fails with -EPROBE_DEFER, because the Type-C connector class requires all > > switch devices to be registered prior to port registration. > > > > To break this deadlock and allow the mode-switch registration to occur, > > purge all the usb-c-connector nodes' absent suppliers. This eliminates > > the connector as a supplier for a switch and allows it to be probed. > > ... > > > + /* > > + * OF graph may have set up some device links with switches, since connectors have their > > + * own compatible. Purge these to avoid a deadlock in switch probe (the switch mistakenly > > + * assumes the connector is a supplier). > > + */ > > A bit too long lines... I'll fix this in v7. > > > + if (dev->of_node) > > Why do you need this check? We use this check to make sure only platforms using OF have their links purged. I'm not sure if this should also be done on x86 platforms. Best regards, Pin-yen > > > + device_for_each_child_node(dev, fwnode) > > + fw_devlink_purge_absent_suppliers(fwnode); > > -- > With Best Regards, > Andy Shevchenko > >
Hi Andy, Thanks for taking a look at this patch. Pin-Yen beat me to the punch with comment responses, but I'll add mine anyway. On Thu, Nov 24, 2022 at 4:25 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > ... > > > + /* > > + * OF graph may have set up some device links with switches, since connectors have their > > + * own compatible. Purge these to avoid a deadlock in switch probe (the switch mistakenly > > + * assumes the connector is a supplier). > > + */ > > A bit too long lines... They are within the 100 character limit [1] which is followed elsewhere in the driver; has something changed recently to make that invalid? > > > + if (dev->of_node) > > Why do you need this check? This issue only arises when using DT for this device. So the rationale is we don't need to perform this step on systems that don't use DT. Best regards, -Prashant [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c index 2a7ff14dc37e..f74e01d18ef3 100644 --- a/drivers/platform/chrome/cros_ec_typec.c +++ b/drivers/platform/chrome/cros_ec_typec.c @@ -382,6 +382,15 @@ static int cros_typec_init_ports(struct cros_typec_data *typec) return -EINVAL; } + /* + * OF graph may have set up some device links with switches, since connectors have their + * own compatible. Purge these to avoid a deadlock in switch probe (the switch mistakenly + * assumes the connector is a supplier). + */ + if (dev->of_node) + device_for_each_child_node(dev, fwnode) + fw_devlink_purge_absent_suppliers(fwnode); + /* DT uses "reg" to specify port number. */ port_prop = dev->of_node ? "reg" : "port-number"; device_for_each_child_node(dev, fwnode) {