From 0ab6ad25e904c5fc15ccffd612690190baf3fd53 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Fri, 13 Mar 2020 15:43:49 +0100 Subject: Fix some HP x360 models not booting (rhbz 1790115) --- ...-clarify-and-fix-platform-device-DMA-mask.patch | 136 +++++++++++++++++++++ kernel.spec | 6 + 2 files changed, 142 insertions(+) create mode 100644 0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch diff --git a/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch b/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch new file mode 100644 index 000000000..873509eb0 --- /dev/null +++ b/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch @@ -0,0 +1,136 @@ +From e3a36eb6dfaeea8175c05d5915dcf0b939be6dab Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Wed, 11 Mar 2020 17:07:10 +0100 +Subject: [PATCH] driver code: clarify and fix platform device DMA mask + allocation + +This does three inter-related things to clarify the usage of the +platform device dma_mask field. In the process, fix the bug introduced +by cdfee5623290 ("driver core: initialize a default DMA mask for +platform device") that caused Artem Tashkinov's laptop to not boot with +newer Fedora kernels. + +This does: + + - First off, rename the field to "platform_dma_mask" to make it + greppable. + + We have way too many different random fields called "dma_mask" in + various data structures, where some of them are actual masks, and + some of them are just pointers to the mask. And the structures all + have pointers to each other, or embed each other inside themselves, + and "pdev" sometimes means "platform device" and sometimes it means + "PCI device". + + So to make it clear in the code when you actually use this new field, + give it a unique name (it really should be something even more unique + like "platform_device_dma_mask", since it's per platform device, not + per platform, but that gets old really fast, and this is unique + enough in context). + + To further clarify when the field gets used, initialize it when we + actually start using it with the default value. + + - Then, use this field instead of the random one-off allocation in + platform_device_register_full() that is now unnecessary since we now + already have a perfectly fine allocation for it in the platform + device structure. + + - The above then allows us to fix the actual bug, where the error path + of platform_device_register_full() would unconditionally free the + platform device DMA allocation with 'kfree()'. + + That kfree() was dont regardless of whether the allocation had been + done earlier with the (now removed) kmalloc, or whether + setup_pdev_dma_masks() had already been used and the dma_mask pointer + pointed to the mask that was part of the platform device. + +It seems most people never triggered the error path, or only triggered +it from a call chain that set an explicit pdevinfo->dma_mask value (and +thus caused the unnecessary allocation that was "cleaned up" in the +error path) before calling platform_device_register_full(). + +Robin Murphy points out that in Artem's case the wdat_wdt driver failed +in platform_device_add(), and that was the one that had called +platform_device_register_full() with pdevinfo.dma_mask = 0, and would +have caused that kfree() of pdev.dma_mask corrupting the heap. + +A later unrelated kmalloc() then oopsed due to the heap corruption. + +Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device") +Reported-bisected-and-tested-by: Artem S. Tashkinov +Reviewed-by: Robin Murphy +Cc: Greg Kroah-Hartman +Signed-off-by: Christoph Hellwig +Signed-off-by: Linus Torvalds +--- + drivers/base/platform.c | 25 ++++++------------------- + include/linux/platform_device.h | 2 +- + 2 files changed, 7 insertions(+), 20 deletions(-) + +diff --git a/drivers/base/platform.c b/drivers/base/platform.c +index 7fa654f1288b..b5ce7b085795 100644 +--- a/drivers/base/platform.c ++++ b/drivers/base/platform.c +@@ -363,10 +363,10 @@ static void setup_pdev_dma_masks(struct platform_device *pdev) + { + if (!pdev->dev.coherent_dma_mask) + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); +- if (!pdev->dma_mask) +- pdev->dma_mask = DMA_BIT_MASK(32); +- if (!pdev->dev.dma_mask) +- pdev->dev.dma_mask = &pdev->dma_mask; ++ if (!pdev->dev.dma_mask) { ++ pdev->platform_dma_mask = DMA_BIT_MASK(32); ++ pdev->dev.dma_mask = &pdev->platform_dma_mask; ++ } + }; + + /** +@@ -662,20 +662,8 @@ struct platform_device *platform_device_register_full( + pdev->dev.of_node_reused = pdevinfo->of_node_reused; + + if (pdevinfo->dma_mask) { +- /* +- * This memory isn't freed when the device is put, +- * I don't have a nice idea for that though. Conceptually +- * dma_mask in struct device should not be a pointer. +- * See http://thread.gmane.org/gmane.linux.kernel.pci/9081 +- */ +- pdev->dev.dma_mask = +- kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL); +- if (!pdev->dev.dma_mask) +- goto err; +- +- kmemleak_ignore(pdev->dev.dma_mask); +- +- *pdev->dev.dma_mask = pdevinfo->dma_mask; ++ pdev->platform_dma_mask = pdevinfo->dma_mask; ++ pdev->dev.dma_mask = &pdev->platform_dma_mask; + pdev->dev.coherent_dma_mask = pdevinfo->dma_mask; + } + +@@ -700,7 +688,6 @@ struct platform_device *platform_device_register_full( + if (ret) { + err: + ACPI_COMPANION_SET(&pdev->dev, NULL); +- kfree(pdev->dev.dma_mask); + platform_device_put(pdev); + return ERR_PTR(ret); + } +diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h +index 276a03c24691..041bfa412aa0 100644 +--- a/include/linux/platform_device.h ++++ b/include/linux/platform_device.h +@@ -24,7 +24,7 @@ struct platform_device { + int id; + bool id_auto; + struct device dev; +- u64 dma_mask; ++ u64 platform_dma_mask; + u32 num_resources; + struct resource *resource; + +-- +2.25.1 + diff --git a/kernel.spec b/kernel.spec index d0b397ce1..25280e7bf 100644 --- a/kernel.spec +++ b/kernel.spec @@ -575,6 +575,9 @@ Patch511: v2_20200128_dmoulding_me_com.patch # Submitted upstream Patch512: iommu-WARN_TAINT-fixes.patch +# Fix some HP x360 models not booting (rhbz 1790115) +Patch513: 0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch + # END OF PATCH DEFINITIONS %endif @@ -1815,6 +1818,9 @@ fi # # %changelog +* Fri Mar 13 2020 Hans de Goede +- Fix some HP x360 models not booting (rhbz 1790115) + * Thu Mar 12 2020 Justin M. Forbes - 5.5.9-100 - Linux v5.5.9 -- cgit From a4bc4dcc75f879d29558f5a238f26b4e6849e080 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Sat, 14 Mar 2020 16:13:22 +0100 Subject: Fix UCSI oopses (rhbz 1785972) --- kernel.spec | 8 +- ucsi-oops-fixes.patch | 264 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 271 insertions(+), 1 deletion(-) create mode 100644 ucsi-oops-fixes.patch diff --git a/kernel.spec b/kernel.spec index 25280e7bf..29ee80e9b 100644 --- a/kernel.spec +++ b/kernel.spec @@ -575,9 +575,12 @@ Patch511: v2_20200128_dmoulding_me_com.patch # Submitted upstream Patch512: iommu-WARN_TAINT-fixes.patch -# Fix some HP x360 models not booting (rhbz 1790115) +# Fix some HP x360 models not booting (rhbz 1790115) (in mainline now) Patch513: 0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch +# Fix UCSI oopses, (rhbz 1785972) (in gkh's usb-linus, heading towards mainline) +Patch514: ucsi-oops-fixes.patch + # END OF PATCH DEFINITIONS %endif @@ -1818,6 +1821,9 @@ fi # # %changelog +* Sat Mar 14 2020 Hans de Goede +- Fix UCSI oopses (rhbz 1785972) + * Fri Mar 13 2020 Hans de Goede - Fix some HP x360 models not booting (rhbz 1790115) diff --git a/ucsi-oops-fixes.patch b/ucsi-oops-fixes.patch new file mode 100644 index 000000000..67c1ab4f2 --- /dev/null +++ b/ucsi-oops-fixes.patch @@ -0,0 +1,264 @@ +Delivered-To: hdegoede@gapps.redhat.com +Received: by 2002:ac9:3cca:0:0:0:0:0 with SMTP id x10csp668580ocf; + Wed, 11 Mar 2020 06:00:20 -0700 (PDT) +X-Google-Smtp-Source: ADFU+vvLKVQ2NCRrbKk+46iEGOgL/dp5kNAySiFCE1BMXIcEIQUMJiy8VDfxwzkL4b/KDmsigoak +X-Received: by 2002:a25:6806:: with SMTP id d6mr2754667ybc.326.1583931620742; + Wed, 11 Mar 2020 06:00:20 -0700 (PDT) +ARC-Seal: i=1; a=rsa-sha256; t=1583931620; cv=none; + d=google.com; s=arc-20160816; + b=GRQ4h+cMvCbklF6XW5Q2mltKo9tJfib6QJHpNf6iNAtnlnvES/vRFnJJTCa601ohr9 + C/HY4T0/cN46QA/mdPDIQz1+CMUnRpi7PDYoLeoc8TUMaPY/PU7QG3eQB6Mc8qP608Y9 + 72lCJ+R+IEaXBUgNAmtiD1DB3C2bi8EctnvQN6JxfAAUU6Qp802Ru2kxmAI24d4GVjF9 + +FweOPG0cKBTdc8Al2jDyW7BIlYxtbSa1T/CvPUoNznd7ojx7uzwYegsvvfP9gicpzVa + fEoH1Bhxvx/qURM0GfOO6xsxAX1jG8c58JGoNZLWYCqfA3p/k4FgsLtrWxIHDHC/FG+0 + PGGg== +ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; + h=content-transfer-encoding:mime-version:references:in-reply-to + :message-id:date:subject:cc:to:from:delivered-to; + bh=QqHHD8kGkQgrKZCRDMePpiviR2jnsd9jIjJ3n7LCR5M=; + b=ycs3X68dm/6atsaad09LdioLoV+Js6lfsdgJsmymghQw7Wtld2MRz3STNMD1QcCD90 + sYGhDb0ilsba4RKe2G6hoXDLAau1VFSS6Yam9htpytW2hdea/r1nIG6W1m03UZtZ1wsA + da/jufsdUKNhcKmZJs5Ok0Zk9c3F6Zt/h0IemuKwfFolV6q2EpfpogUH7DQsVZXWEKND + l+apv3mjYqv5rJBRVY1q0H4/pNVuptRX+2Srnj5Siz+982kSAAGgb3WFB3AsS7RyklgX + 1Ho+CIco+U0d1wHM9BXylsjvLLjQRQOMklWXHm1qqXPQ0ybhClJmED5sJIr/Jf4mJ0KB + A1Ng== +ARC-Authentication-Results: i=1; mx.google.com; + spf=pass (google.com: best guess record for domain of heikki.krogerus@linux.intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=heikki.krogerus@linux.intel.com +Return-Path: +Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com. [205.139.110.61]) + by mx.google.com with ESMTPS id a15si1271762ybk.78.2020.03.11.06.00.20 + for + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Wed, 11 Mar 2020 06:00:20 -0700 (PDT) +Received-SPF: pass (google.com: best guess record for domain of heikki.krogerus@linux.intel.com designates 134.134.136.126 as permitted sender) client-ip=134.134.136.126; +Authentication-Results: mx.google.com; + spf=pass (google.com: best guess record for domain of heikki.krogerus@linux.intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=heikki.krogerus@linux.intel.com +Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com + [66.187.233.88]) (Using TLS) by relay.mimecast.com with ESMTP id + us-mta-456-lABK24RoPMylyDoOfppDdw-1; Wed, 11 Mar 2020 09:00:19 -0400 +X-MC-Unique: lABK24RoPMylyDoOfppDdw-1 +Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) + (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F06A8185A795 + for ; Wed, 11 Mar 2020 13:00:18 +0000 (UTC) +Received: by smtp.corp.redhat.com (Postfix) + id ED3AF1134CD6; Wed, 11 Mar 2020 13:00:18 +0000 (UTC) +Delivered-To: hdegoede@redhat.com +Received: from mimecast-mx02.redhat.com (mimecast03.extmail.prod.ext.rdu2.redhat.com [10.11.55.19]) + by smtp.corp.redhat.com (Postfix) with ESMTPS id E8DE21134CC1 + for ; Wed, 11 Mar 2020 13:00:18 +0000 (UTC) +Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) + (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) + (No client certificate requested) + by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D4F1980030B + for ; Wed, 11 Mar 2020 13:00:18 +0000 (UTC) +Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (Using + TLS) by relay.mimecast.com with ESMTP id + us-mta-396-cq2xxB_jPiKPJtJzTaqmBA-2; Wed, 11 Mar 2020 09:00:13 -0400 +X-MC-Unique: cq2xxB_jPiKPJtJzTaqmBA-2 +X-Amp-Result: SKIPPED(no attachment in message) +X-Amp-File-Uploaded: False +Received: from fmsmga001.fm.intel.com ([10.253.24.23]) + by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2020 06:00:11 -0700 +X-ExtLoop1: 1 +X-IronPort-AV: E=Sophos;i="5.70,540,1574150400"; + d="scan'208";a="353878525" +Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) + by fmsmga001.fm.intel.com with ESMTP; 11 Mar 2020 06:00:09 -0700 +From: Heikki Krogerus +To: Greg Kroah-Hartman +Cc: Hans de Goede , + linux-usb@vger.kernel.org, + stable@vger.kernel.org +Subject: [PATCH 1/2] usb: typec: ucsi: displayport: Fix NULL pointer dereference +Date: Wed, 11 Mar 2020 16:00:05 +0300 +Message-Id: <20200311130006.41288-2-heikki.krogerus@linux.intel.com> +In-Reply-To: <20200311130006.41288-1-heikki.krogerus@linux.intel.com> +References: <20200311130006.41288-1-heikki.krogerus@linux.intel.com> +MIME-Version: 1.0 +X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 +X-Mimecast-Spam-Score: 0 +X-Mimecast-Originator: linux.intel.com +Content-Type: text/plain; charset=WINDOWS-1252 +Content-Transfer-Encoding: quoted-printable + +If the registration of the DisplayPort was not successful, +or if the port does not support DisplayPort alt mode in the +first place, the function ucsi_displayport_remove_partner() +will fail with NULL pointer dereference when it attempts to +access the driver data. + +Adding a check to the function to make sure there really is +driver data for the device before modifying it. + +Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") +Reported-by: Andrea Gagliardi La Gala +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=3D206365 +Cc: stable@vger.kernel.org +Signed-off-by: Heikki Krogerus +--- + drivers/usb/typec/ucsi/displayport.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/usb/typec/ucsi/displayport.c b/drivers/usb/typec/ucsi/= +displayport.c +index 0f1273ae086c..261131c9e37c 100644 +--- a/drivers/usb/typec/ucsi/displayport.c ++++ b/drivers/usb/typec/ucsi/displayport.c +@@ -271,6 +271,9 @@ void ucsi_displayport_remove_partner(struct typec_altmo= +de *alt) + =09=09return; +=20 + =09dp =3D typec_altmode_get_drvdata(alt); ++=09if (!dp) ++=09=09return; ++ + =09dp->data.conf =3D 0; + =09dp->data.status =3D 0; + =09dp->initialized =3D false; +--=20 +2.25.1 + +Delivered-To: hdegoede@gapps.redhat.com +Received: by 2002:ac9:3cca:0:0:0:0:0 with SMTP id x10csp668601ocf; + Wed, 11 Mar 2020 06:00:21 -0700 (PDT) +X-Google-Smtp-Source: ADFU+vsGhdWLjQ3QpxqWj6WbYOo0YlQLm+xaXhCA9qDlbUCuTwO0DTYoUpCtv/Wic/3KISqZC1e0 +X-Received: by 2002:a17:906:90d9:: with SMTP id v25mr2356602ejw.73.1583931621591; + Wed, 11 Mar 2020 06:00:21 -0700 (PDT) +ARC-Seal: i=1; a=rsa-sha256; t=1583931621; cv=none; + d=google.com; s=arc-20160816; + b=TLDfI22LVNxWmkmYrQN2uyHHPtPhg7WoBmf4iRg+OckIGdycsI9lsHbEayPwTnavnh + zh/vP7ADiHK/CgvjRmi23hCcrqZchwKPBXKVGyfsW3uVNSuKzUHc/hvUeH4kyDpUkYei + DYmbgn+d4egWgMwPcnILYiOOXOVCRXM5fx2dZ1fce9PUl2XNCZ2WVg4a9oRUD1sTUpSM + 5bSTil75+tWtb8iWaE6mjnA9QGdt8Fro9J5c96ieLXGDeBnn17yqeV0z2x5041uCzomd + VjYisvIyCmgwyrP/1rmcNiefcXT8cywY6VDBXT4iZokr9E+Uc9oaWlrr68Dknu0L9Sps + kikQ== +ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; + h=content-transfer-encoding:mime-version:references:in-reply-to + :message-id:date:subject:cc:to:from:delivered-to; + bh=2VcPAoJ6MUqHi98RX96U06C9ISBArMXJM424R6yWYho=; + b=pgfElkmeiDab/DIqnu1P0nT7ENBYKSc1y7f0xD7a3nxknW4dRVi0JTJB0U0LlWHKMi + oD+hUOzkTK7A6WFPHHQYUBwWaP1l4YyV9NttwwdNGvqJ3QPLaSRMGE1o8GMviHmTCinS + wyoSx18HZANbQFED3KSI0XOvRPCxnItDbLtvd8xCCddAHkEoBJSWO2xMCxaTmiw9OrjP + bJnzeQzbmEnLwTiYz/v9cwb99Rmnu8L6I/wgdbdso92c3YTO2jSCcEZcwsXOZOrrwfvB + OpyJ9yZ53djiEcP9IXwuMIIuwGoo3jiRzoBTKYVvD6m/w+RUWNqyiadKfEC81qIjtM8e + L0sA== +ARC-Authentication-Results: i=1; mx.google.com; + spf=pass (google.com: best guess record for domain of heikki.krogerus@linux.intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=heikki.krogerus@linux.intel.com +Return-Path: +Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com. [207.211.31.120]) + by mx.google.com with ESMTPS id n15si1068927ejy.114.2020.03.11.06.00.21 + for + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Wed, 11 Mar 2020 06:00:21 -0700 (PDT) +Received-SPF: pass (google.com: best guess record for domain of heikki.krogerus@linux.intel.com designates 134.134.136.126 as permitted sender) client-ip=134.134.136.126; +Authentication-Results: mx.google.com; + spf=pass (google.com: best guess record for domain of heikki.krogerus@linux.intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=heikki.krogerus@linux.intel.com +Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com + [66.187.233.88]) (Using TLS) by relay.mimecast.com with ESMTP id + us-mta-457-hFBicEuyOd600736mXrw_g-1; Wed, 11 Mar 2020 09:00:19 -0400 +X-MC-Unique: hFBicEuyOd600736mXrw_g-1 +Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) + (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B396080029A + for ; Wed, 11 Mar 2020 13:00:18 +0000 (UTC) +Received: by smtp.corp.redhat.com (Postfix) + id B09DA2037E5A; Wed, 11 Mar 2020 13:00:18 +0000 (UTC) +Delivered-To: hdegoede@redhat.com +Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) + by smtp.corp.redhat.com (Postfix) with ESMTPS id AA6B62026D67 + for ; Wed, 11 Mar 2020 13:00:17 +0000 (UTC) +Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) + (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) + (No client certificate requested) + by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0FD8B8001EA + for ; Wed, 11 Mar 2020 13:00:17 +0000 (UTC) +Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (Using + TLS) by relay.mimecast.com with ESMTP id + us-mta-60-lllq3BsjPKu9X3G8f-NF5Q-1; Wed, 11 Mar 2020 09:00:14 -0400 +X-MC-Unique: lllq3BsjPKu9X3G8f-NF5Q-1 +X-Amp-Result: SKIPPED(no attachment in message) +X-Amp-File-Uploaded: False +Received: from fmsmga001.fm.intel.com ([10.253.24.23]) + by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2020 06:00:13 -0700 +X-ExtLoop1: 1 +X-IronPort-AV: E=Sophos;i="5.70,540,1574150400"; + d="scan'208";a="353878533" +Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) + by fmsmga001.fm.intel.com with ESMTP; 11 Mar 2020 06:00:11 -0700 +From: Heikki Krogerus +To: Greg Kroah-Hartman +Cc: Hans de Goede , + linux-usb@vger.kernel.org, + stable@vger.kernel.org +Subject: [PATCH 2/2] usb: typec: ucsi: displayport: Fix a potential race during registration +Date: Wed, 11 Mar 2020 16:00:06 +0300 +Message-Id: <20200311130006.41288-3-heikki.krogerus@linux.intel.com> +In-Reply-To: <20200311130006.41288-1-heikki.krogerus@linux.intel.com> +References: <20200311130006.41288-1-heikki.krogerus@linux.intel.com> +MIME-Version: 1.0 +X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 +X-Mimecast-Spam-Score: 0 +X-Mimecast-Originator: linux.intel.com +Content-Type: text/plain; charset=WINDOWS-1252 +Content-Transfer-Encoding: quoted-printable + +Locking the connector in ucsi_register_displayport() to make +sure that nothing can access the displayport alternate mode +before the function has finished and the alternate mode is +actually ready. + +Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") +Cc: stable@vger.kernel.org +Signed-off-by: Heikki Krogerus +--- + drivers/usb/typec/ucsi/displayport.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/usb/typec/ucsi/displayport.c b/drivers/usb/typec/ucsi/= +displayport.c +index 261131c9e37c..048381c058a5 100644 +--- a/drivers/usb/typec/ucsi/displayport.c ++++ b/drivers/usb/typec/ucsi/displayport.c +@@ -288,6 +288,8 @@ struct typec_altmode *ucsi_register_displayport(struct = +ucsi_connector *con, + =09struct typec_altmode *alt; + =09struct ucsi_dp *dp; +=20 ++=09mutex_lock(&con->lock); ++ + =09/* We can't rely on the firmware with the capabilities. */ + =09desc->vdo |=3D DP_CAP_DP_SIGNALING | DP_CAP_RECEPTACLE; +=20 +@@ -296,12 +298,15 @@ struct typec_altmode *ucsi_register_displayport(struc= +t ucsi_connector *con, + =09desc->vdo |=3D all_assignments << 16; +=20 + =09alt =3D typec_port_register_altmode(con->port, desc); +-=09if (IS_ERR(alt)) ++=09if (IS_ERR(alt)) { ++=09=09mutex_unlock(&con->lock); + =09=09return alt; ++=09} +=20 + =09dp =3D devm_kzalloc(&alt->dev, sizeof(*dp), GFP_KERNEL); + =09if (!dp) { + =09=09typec_unregister_altmode(alt); ++=09=09mutex_unlock(&con->lock); + =09=09return ERR_PTR(-ENOMEM); + =09} +=20 +@@ -314,5 +319,7 @@ struct typec_altmode *ucsi_register_displayport(struct = +ucsi_connector *con, + =09alt->ops =3D &ucsi_displayport_ops; + =09typec_altmode_set_drvdata(alt, dp); +=20 ++=09mutex_unlock(&con->lock); ++ + =09return alt; + } +--=20 +2.25.1 + -- cgit