summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorThorsten Leemhuis <fedora@leemhuis.info>2020-03-18 07:59:37 +0100
committerThorsten Leemhuis <fedora@leemhuis.info>2020-03-18 07:59:37 +0100
commit0614c1dae2cf7cfb37dd75969784e4d1416a5eed (patch)
tree8093376914c8973c70a34ec85bc22420a5c1cd6b
parent14df560022da6b876a915de375fc5485ad4454bf (diff)
parenta4bc4dcc75f879d29558f5a238f26b4e6849e080 (diff)
downloadkernel-0614c1dae2cf7cfb37dd75969784e4d1416a5eed.tar.gz
kernel-0614c1dae2cf7cfb37dd75969784e4d1416a5eed.tar.xz
kernel-0614c1dae2cf7cfb37dd75969784e4d1416a5eed.zip
Merge remote-tracking branch 'origin/f30' into f30-user-thl-vanilla-fedora
-rw-r--r--0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch136
-rw-r--r--kernel.spec12
-rw-r--r--ucsi-oops-fixes.patch264
3 files changed, 412 insertions, 0 deletions
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 <hch@lst.de>
+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 <aros@gmx.com>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ 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 7be833eb6..461547d24 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -593,6 +593,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) (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
@@ -1836,6 +1842,12 @@ fi
#
#
%changelog
+* Sat Mar 14 2020 Hans de Goede <hdegoede@redhat.com>
+- Fix UCSI oopses (rhbz 1785972)
+
+* Fri Mar 13 2020 Hans de Goede <hdegoede@redhat.com>
+- Fix some HP x360 models not booting (rhbz 1790115)
+
* Thu Mar 12 2020 Justin M. Forbes <jforbes@fedoraproject.org> - 5.5.9-100
- Linux v5.5.9
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: <heikki.krogerus@linux.intel.com>
+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 <hdegoede@gapps.redhat.com>
+ (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 <hdegoede@gapps.redhat.com>; 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 <hdegoede@redhat.com>; 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 <hdegoede@redhat.com>; 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 <heikki.krogerus@linux.intel.com>
+To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Hans de Goede <hdegoede@redhat.com>,
+ 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 <andrea.lagala@gmail.com>
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=3D206365
+Cc: stable@vger.kernel.org
+Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+---
+ 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: <heikki.krogerus@linux.intel.com>
+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 <hdegoede@gapps.redhat.com>
+ (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 <hdegoede@gapps.redhat.com>; 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 <hdegoede@redhat.com>; 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 <hdegoede@redhat.com>; 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 <heikki.krogerus@linux.intel.com>
+To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Hans de Goede <hdegoede@redhat.com>,
+ 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 <heikki.krogerus@linux.intel.com>
+---
+ 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
+