From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: "Christian A. Ehrhardt" <lk@c--e.de>
Cc: linux-usb@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Hans de Goede <hdegoede@redhat.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Saranya Gopal <saranya.gopal@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Fix stuck UCSI controller on DELL
Date: Thu, 4 Jan 2024 13:59:02 +0200 [thread overview]
Message-ID: <ZZadhlh3q9ZInxvU@kuha.fi.intel.com> (raw)
In-Reply-To: <20240103100635.57099-1-lk@c--e.de>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
Hi Christian,
On Wed, Jan 03, 2024 at 11:06:35AM +0100, Christian A. Ehrhardt wrote:
> I have a DELL Latitude 5431 where typec only works somewhat.
> After the first plug/unplug event the PPM seems to be stuck and
> commands end with a timeout (GET_CONNECTOR_STATUS failed (-110)).
>
> This patch fixes it for me but according to my reading it is in
> violation of the UCSI spec. On the other hand searching through
> the net it appears that many DELL models seem to have timeout problems
> with UCSI.
>
> Do we want some kind of quirk here? There does not seem to be a quirk
> framework for this part of the code, yet. Or is it ok to just send the
> additional ACK in all cases and hope that the PPM will do the right
> thing?
We can use DMI quirks. Something like the attached diff (not tested).
thanks,
--
heikki
[-- Attachment #2: dell_ucsi_quirk.diff --]
[-- Type: text/plain, Size: 2307 bytes --]
diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 6bbf490ac401..7e8b1fcfa024 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -113,18 +113,44 @@ ucsi_zenbook_read(struct ucsi *ucsi, unsigned int offset, void *val, size_t val_
return 0;
}
-static const struct ucsi_operations ucsi_zenbook_ops = {
- .read = ucsi_zenbook_read,
- .sync_write = ucsi_acpi_sync_write,
- .async_write = ucsi_acpi_async_write
-};
+static int ucsi_dell_sync_write(struct ucsi *ucsi, unsigned int offset,
+ const void *val, size_t val_len)
+{
+ u64 ctrl = *(u64 *)val;
+ int ret;
+
+ ret = ucsi_acpi_sync_write(ucsi, offset, val, val_len);
+ if (ret && (ctrl & (UCSI_ACK_CC_CI | UCSI_ACK_CONNECTOR_CHANGE))) {
+ ctrl= UCSI_ACK_CC_CI | UCSI_ACK_COMMAND_COMPLETE;
+
+ dev_dbg(ucsi->dev->parent, "%s: ACK failed\n", __func__);
+ ret = ucsi_acpi_sync_write(ucsi, UCSI_CONTROL, &ctrl, sizeof(ctrl));
+ }
-static const struct dmi_system_id zenbook_dmi_id[] = {
+ return ret;
+}
+
+static const struct dmi_system_id ucsi_acpi_quirks[] = {
{
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "ZenBook UX325UA_UM325UA"),
},
+ .driver_data = &(struct ucsi_operations) {
+ .read = ucsi_zenbook_read,
+ .sync_write = ucsi_acpi_sync_write,
+ .async_write = ucsi_acpi_async_write
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ },
+ .driver_data = &(struct ucsi_operations) {
+ .read = ucsi_acpi_read,
+ .sync_write = ucsi_dell_sync_write,
+ .async_write = ucsi_acpi_async_write
+ },
},
{ }
};
@@ -151,6 +177,7 @@ static int ucsi_acpi_probe(struct platform_device *pdev)
{
struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
const struct ucsi_operations *ops = &ucsi_acpi_ops;
+ const struct dmi_system_id *id;
struct ucsi_acpi *ua;
struct resource *res;
acpi_status status;
@@ -180,8 +207,9 @@ static int ucsi_acpi_probe(struct platform_device *pdev)
init_completion(&ua->complete);
ua->dev = &pdev->dev;
- if (dmi_check_system(zenbook_dmi_id))
- ops = &ucsi_zenbook_ops;
+ id = dmi_first_match(ucsi_acpi_quirks);
+ if (id)
+ ops = id->driver_data;
ua->ucsi = ucsi_create(&pdev->dev, ops);
if (IS_ERR(ua->ucsi))
next prev parent reply other threads:[~2024-01-04 11:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 10:06 [RFC] Fix stuck UCSI controller on DELL Christian A. Ehrhardt
2024-01-04 11:59 ` Heikki Krogerus [this message]
2024-01-15 18:55 ` Christian A. Ehrhardt
2024-01-17 3:00 ` Mario Limonciello
2024-01-17 6:35 ` Christian A. Ehrhardt
2024-01-17 17:34 ` Mario Limonciello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZZadhlh3q9ZInxvU@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lk@c--e.de \
--cc=mario.limonciello@amd.com \
--cc=neil.armstrong@linaro.org \
--cc=saranya.gopal@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox