Message ID | 20240213130018.3029991-3-heikki.krogerus@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-63551-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp613763dyb; Tue, 13 Feb 2024 07:30:14 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUq6iC6yX1uRN3K2/zL++o9x6Wc3OM9hrM7ub6mxQguzTQEEm24Otot0QpkH0ofG9Ea4YsQRKe31zv76xuLxVkJ0HTbCw== X-Google-Smtp-Source: AGHT+IERHtSbYv7uCjRAZ4qZinf6IbY/JHKSSRRPTycFkHWZL0La8nmklL+MxzagV4seKhxIApvY X-Received: by 2002:a17:903:41d1:b0:1db:4962:949e with SMTP id u17-20020a17090341d100b001db4962949emr1106572ple.27.1707838214510; Tue, 13 Feb 2024 07:30:14 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707838214; cv=pass; d=google.com; s=arc-20160816; b=P81nHWkL9nfe3b0Jiiq5I1mh/gZdYtvCLatZmx0xyMSqT6+eBqlcy8NV4P6LNwZoEF FeHliQb3ajMA/H0mRqXjjV7CVe2XB6Bsut7Cmbyj9y/wRRUf9pvceNmdrb8yw6pRM0KX l6nQpGRXgU+B1R3NUWSglgJ8UdpXCrYequQYLJWAmbY/qoik9xsnOXwX2WT7G54r0elb PVKU+MgQ2j9z5FJZ3AjuzNsLhPaJ5TbTufUKhAHsnT6pe7XmvXK/ZvUHN8EJSugjDX6x nbEnkMkoIVB8JbPa3okSrpFMS6nBQuBlaZF500kDwnbB93j5H3MEzGrYZAsCKL+7Lsmt ebSg== 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=kkGQ35KdVssLSX5zrrlXzox3ioRslheQdObqrgpivhA=; fh=bQDO9Ttz8jM4pTKc/vm85P8LfoAGJ1krQLVu/rGIaRA=; b=qvvevrh/s9C0gy/yixkp8HNUdyUnF157720YyF06vFZuoMmSeN8YpMIczu/QQk4isp MJQKiMWWDPnOhP0EOYzQQPvCuDgS88EgauG/yHvR8vmtzl/KmjKPSiu/dR3OjA6HeUIA 9sRvO9UYZH+QHDItXdbjYouQYhTe3foL/PvJviYyI/2B8gFizhKbXr4n7/+egtmgCeM4 gTRYBsrNKHfkFUAR7S87R0JbuC4daj8dh0gEBCL0vMVLgf8cmRnGQ3YasD9L8iLKKk5W YQJUXttd57lx0wrMEg8jDxv/4scKYZ7pk+KT/kxzd87jRy2MiqMy3cZHV0Xh1k0NoYdP IRBg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=loBi76Bu; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-63551-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63551-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Forwarded-Encrypted: i=2; AJvYcCVX9qHompFZz43uNLjou3SASr1utJdH66v3J4vCmJiygoPukLhLM+hCDezdsgeTuEVJ+rGksJzQkNDri67lMnzLAQyi3A== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id dq19-20020a056a020f9300b005cd813c23besi2197295pgb.415.2024.02.13.07.30.14 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 07:30:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-63551-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=loBi76Bu; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-63551-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63551-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.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 BFB1128B0A6 for <ouuuleilei@gmail.com>; Tue, 13 Feb 2024 13:01:31 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CC610524A7; Tue, 13 Feb 2024 13:00:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="loBi76Bu" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 D374D51039; Tue, 13 Feb 2024 13:00:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707829233; cv=none; b=KQiO76iCGJ88gmybRzYfl94r2RDOen6xJgP4FA3xO6sz1bMASvvnKmN4y06BIky9DNxBtena8qVOjyDVmeUWW+ledzxvbwHVhDPSXG1oThBLirc77nvtaz9F34kDZyjt2thVACZ10SfmnJtFmjc38Icoua9M6J+Siroo0Ly0sXk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707829233; c=relaxed/simple; bh=FPXgBnSmS+6sKYbXhTyHNlC+korVLPzZkGCgDSeKV5I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U1vbQa0nz8ePesFnxlrgoWdhQV18PA25FzbbxeDZN24HPWcXD7WUo+p6sWeWQxRW0u9GvRghYzNxv2uOm/ivzQFRiHFISr5dPCxw6BUkvbBt0okvKsI0YiiTWQjWfmd6zxVoO9ShRtAK7rKrfELRSaF1ncMq49ARXIE5PTNgqgc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=loBi76Bu; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707829232; x=1739365232; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FPXgBnSmS+6sKYbXhTyHNlC+korVLPzZkGCgDSeKV5I=; b=loBi76BuShhYeDmHFGG/8Iramm+LjE8Vau7YaP2GUObELxoqJcfqgURq s9Dn+4Vp61VJEa6zRgxazhMK616QqUE+kuQuxoZSqJwyL60bxTgOXFq9k K39fHnzWYFjFqwY+sM2UUNcmhGFNaZR1LrjTVd20dtrkpG8HPyD7eiL+m 27Emin+V+lIRdh7Xh2RHOE9oxFPEe4HvDIKPZytmUFOscf2OP0moWGK4A GbBrlKN9VU6zXiqavOZMdyZZy3xu4LEC0Qd2DkZomtztmdvRMvXdfIzfw voWEBvTeWMDUS6jSzWs5JFO3WI87p0fd5RCcEm5qc2E0LQIZDB0paIXPK g==; X-IronPort-AV: E=McAfee;i="6600,9927,10982"; a="1708904" X-IronPort-AV: E=Sophos;i="6.06,157,1705392000"; d="scan'208";a="1708904" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2024 05:00:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10982"; a="935348383" X-IronPort-AV: E=Sophos;i="6.06,157,1705392000"; d="scan'208";a="935348383" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 13 Feb 2024 05:00:27 -0800 From: Heikki Krogerus <heikki.krogerus@linux.intel.com> To: Prashant Malani <pmalani@chromium.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Benson Leung <bleung@chromium.org>, Tzung-Bi Shih <tzungbi@kernel.org>, Guenter Roeck <groeck@chromium.org>, Emilie Roberts <hadrosaur@google.com>, "Nyman, Mathias" <mathias.nyman@intel.com>, "Regupathy, Rajaram" <rajaram.regupathy@intel.com>, "Radjacoumar, Shyam Sundar" <ssradjacoumar@google.com>, Samuel Jacob <samjaco@google.com>, Uday Bhat <uday.m.bhat@intel.com>, linux-usb@vger.kernel.org, chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/2] platform/chrome: cros_ec_typec: Make sure the USB role switch has PLD Date: Tue, 13 Feb 2024 15:00:18 +0200 Message-ID: <20240213130018.3029991-3-heikki.krogerus@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240213130018.3029991-1-heikki.krogerus@linux.intel.com> References: <20240213130018.3029991-1-heikki.krogerus@linux.intel.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-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790798163488369256 X-GMAIL-MSGID: 1790798163488369256 |
Series |
platform/chrome: typec: xHCI DbC
|
|
Commit Message
Heikki Krogerus
Feb. 13, 2024, 1 p.m. UTC
The USB role switch does not always have the _PLD (Physical Location of Device) in ACPI tables. If it's missing, assigning the PLD hash of the port to the switch. That should guarantee that the USB Type-C port mapping code is always able to find the connection between the two (the port and the switch). Tested-by: Uday Bhat <uday.m.bhat@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> --- drivers/platform/chrome/cros_ec_typec.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
Comments
Hi Heikki, On Tue, Feb 13, 2024 at 5:00 AM Heikki Krogerus <heikki.krogerus@linux.intel.com> wrote: > > The USB role switch does not always have the _PLD (Physical > Location of Device) in ACPI tables. If it's missing, > assigning the PLD hash of the port to the switch. That > should guarantee that the USB Type-C port mapping code is > always able to find the connection between the two (the port > and the switch). > > Tested-by: Uday Bhat <uday.m.bhat@intel.com> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > drivers/platform/chrome/cros_ec_typec.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c > index 2b2f14a1b711..4d305876ec08 100644 > --- a/drivers/platform/chrome/cros_ec_typec.c > +++ b/drivers/platform/chrome/cros_ec_typec.c > @@ -24,6 +24,23 @@ > #define DP_PORT_VDO (DP_CONF_SET_PIN_ASSIGN(BIT(DP_PIN_ASSIGN_C) | BIT(DP_PIN_ASSIGN_D)) | \ > DP_CAP_DFP_D | DP_CAP_RECEPTACLE) > > +static void cros_typec_role_switch_quirk(struct fwnode_handle *fwnode) > +{ > +#ifdef CONFIG_ACPI > + struct fwnode_handle *switch_fwnode; > + > + /* Supply the USB role switch with the correct pld_crc if it's missing. */ > + switch_fwnode = fwnode_find_reference(fwnode, "usb-role-switch", 0); > + if (!IS_ERR_OR_NULL(switch_fwnode)) { > + struct acpi_device *adev = to_acpi_device_node(switch_fwnode); > + > + if (adev && !adev->pld_crc) > + adev->pld_crc = to_acpi_device_node(fwnode)->pld_crc; > + fwnode_handle_put(switch_fwnode); > + } > +#endif > +} > + I'll reiterate my comment[ 1] from v1: can this be in the common Type-C code, i.e typec_register_port() ? I don't see anything in this implementation which is Chrome OS specific. Thanks, -Prashant [1] https://lore.kernel.org/chrome-platform/CACeCKaffZBPA0Q_Bqs1hjKJB4HCj=VKrqO21dXj4AF5C5VwtVQ@mail.gmail.com/
On Tue, Feb 13, 2024 at 08:55:20AM -0800, Prashant Malani wrote: > Hi Heikki, > > On Tue, Feb 13, 2024 at 5:00 AM Heikki Krogerus > <heikki.krogerus@linux.intel.com> wrote: > > > > The USB role switch does not always have the _PLD (Physical > > Location of Device) in ACPI tables. If it's missing, > > assigning the PLD hash of the port to the switch. That > > should guarantee that the USB Type-C port mapping code is > > always able to find the connection between the two (the port > > and the switch). > > > > Tested-by: Uday Bhat <uday.m.bhat@intel.com> > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > > --- > > drivers/platform/chrome/cros_ec_typec.c | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c > > index 2b2f14a1b711..4d305876ec08 100644 > > --- a/drivers/platform/chrome/cros_ec_typec.c > > +++ b/drivers/platform/chrome/cros_ec_typec.c > > @@ -24,6 +24,23 @@ > > #define DP_PORT_VDO (DP_CONF_SET_PIN_ASSIGN(BIT(DP_PIN_ASSIGN_C) | BIT(DP_PIN_ASSIGN_D)) | \ > > DP_CAP_DFP_D | DP_CAP_RECEPTACLE) > > > > +static void cros_typec_role_switch_quirk(struct fwnode_handle *fwnode) > > +{ > > +#ifdef CONFIG_ACPI > > + struct fwnode_handle *switch_fwnode; > > + > > + /* Supply the USB role switch with the correct pld_crc if it's missing. */ > > + switch_fwnode = fwnode_find_reference(fwnode, "usb-role-switch", 0); > > + if (!IS_ERR_OR_NULL(switch_fwnode)) { > > + struct acpi_device *adev = to_acpi_device_node(switch_fwnode); > > + > > + if (adev && !adev->pld_crc) > > + adev->pld_crc = to_acpi_device_node(fwnode)->pld_crc; > > + fwnode_handle_put(switch_fwnode); > > + } > > +#endif > > +} > > + > > I'll reiterate my comment[ 1] from v1: can this be in the > common Type-C code, i.e typec_register_port() ? > > I don't see anything in this implementation which is Chrome OS specific. I'm sorry Prashant, I failed to notice your comment. This is only needed for Chrome OS. The problem affects only certain Chromebooks. I do not want to put quirks to the generic subsystem code unless we have to. If there are more device drivers that need the same quirk, then we can move it there, but not before that. This solution is in any case a hack regardless of where we put it, and I don't like it because of that. But I don't have any better ideas unfortunately. thanks,
Hi Emilie, On Wed, Feb 14, 2024 at 12:04:22PM +0100, Emilie Roberts wrote: > My understanding is that this is related to the wiring spec and not > ChromeOS specific. It seems possible that OEMs making non-ChromeOS devices > may have this same issue. Or are we certain that only Chromebooks will ever > see this? Non-ChromeOS platforms do not have this issue. The issue is with the ACPI tables - the USB role switch ACPI device nodes don't have the _PLD object on these systems. Ideally this could be fixed there by simply adding the _PLD to those ACPI device objects, but I understood that that is not an option. But maybe I misunderstood... Can the ACPI tables on these platforms still be updated? thanks,
Hi Heikki, On Wed, Feb 14, 2024 at 3:59 AM Heikki Krogerus <heikki.krogerus@linux.intel.com> wrote: > > Hi Emilie, > > On Wed, Feb 14, 2024 at 12:04:22PM +0100, Emilie Roberts wrote: > > My understanding is that this is related to the wiring spec and not > > ChromeOS specific. It seems possible that OEMs making non-ChromeOS devices > > may have this same issue. Or are we certain that only Chromebooks will ever > > see this? > > Non-ChromeOS platforms do not have this issue. > > The issue is with the ACPI tables - the USB role switch ACPI device > nodes don't have the _PLD object on these systems. Ideally this could > be fixed there by simply adding the _PLD to those ACPI device objects, > but I understood that that is not an option. > > But maybe I misunderstood... Can the ACPI tables on these platforms > still be updated? Since it's just a _PLD update to, it should be possible to do a "light" firmware update on the relevant boards. Shyam/Emilie/Won, how practical is this? I'd much prefer this to be fixed properly in the ACPI table than relying on this quirk. IAC, if we absolutely *have* to use this quirk: Acked-by: Prashant Malani <pmalani@chromium.org> Thanks,
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c index 2b2f14a1b711..4d305876ec08 100644 --- a/drivers/platform/chrome/cros_ec_typec.c +++ b/drivers/platform/chrome/cros_ec_typec.c @@ -24,6 +24,23 @@ #define DP_PORT_VDO (DP_CONF_SET_PIN_ASSIGN(BIT(DP_PIN_ASSIGN_C) | BIT(DP_PIN_ASSIGN_D)) | \ DP_CAP_DFP_D | DP_CAP_RECEPTACLE) +static void cros_typec_role_switch_quirk(struct fwnode_handle *fwnode) +{ +#ifdef CONFIG_ACPI + struct fwnode_handle *switch_fwnode; + + /* Supply the USB role switch with the correct pld_crc if it's missing. */ + switch_fwnode = fwnode_find_reference(fwnode, "usb-role-switch", 0); + if (!IS_ERR_OR_NULL(switch_fwnode)) { + struct acpi_device *adev = to_acpi_device_node(switch_fwnode); + + if (adev && !adev->pld_crc) + adev->pld_crc = to_acpi_device_node(fwnode)->pld_crc; + fwnode_handle_put(switch_fwnode); + } +#endif +} + static int cros_typec_parse_port_props(struct typec_capability *cap, struct fwnode_handle *fwnode, struct device *dev) @@ -66,6 +83,8 @@ static int cros_typec_parse_port_props(struct typec_capability *cap, cap->prefer_role = ret; } + cros_typec_role_switch_quirk(fwnode); + cap->fwnode = fwnode; return 0;