--- /dev/null
+From 9c7e355ccbb33d239360c876dbe49ad5ade65b47 Mon Sep 17 00:00:00 2001
+From: Mohan Kumar <mkumard@nvidia.com>
+Date: Mon, 2 Jan 2023 12:18:44 +0530
+Subject: dmaengine: tegra210-adma: fix global intr clear
+
+From: Mohan Kumar <mkumard@nvidia.com>
+
+commit 9c7e355ccbb33d239360c876dbe49ad5ade65b47 upstream.
+
+The current global interrupt clear programming register offset
+was not correct. Fix the programming with right offset
+
+Fixes: ded1f3db4cd6 ("dmaengine: tegra210-adma: prepare for supporting newer Tegra chips")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
+Link: https://lore.kernel.org/r/20230102064844.31306-1-mkumard@nvidia.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/tegra210-adma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/dma/tegra210-adma.c
++++ b/drivers/dma/tegra210-adma.c
+@@ -224,7 +224,7 @@ static int tegra_adma_init(struct tegra_
+ int ret;
+
+ /* Clear any interrupts */
+- tdma_write(tdma, tdma->cdata->global_int_clear, 0x1);
++ tdma_write(tdma, tdma->cdata->ch_base_offset + tdma->cdata->global_int_clear, 0x1);
+
+ /* Assert soft reset */
+ tdma_write(tdma, ADMA_GLOBAL_SOFT_RESET, 0x1);
--- /dev/null
+From 973a9c810c785ac270a6d50d8cf862b0c1643a10 Mon Sep 17 00:00:00 2001
+From: Joshua Ashton <joshua@froggi.es>
+Date: Tue, 10 Jan 2023 22:50:42 +0000
+Subject: drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix
+
+From: Joshua Ashton <joshua@froggi.es>
+
+commit 973a9c810c785ac270a6d50d8cf862b0c1643a10 upstream.
+
+The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is
+missing the values for the fourth column of the matrix.
+
+The fourth column of the matrix is essentially just a value that is
+added given that the color is 3 components in size.
+These values are needed to bias the chroma from the [-1, 1] -> [0, 1]
+range.
+
+This fixes color being very green when using Gamescope HDR on HDMI
+output which prefers YCC 4:4:4.
+
+Fixes: 40df2f809e8f ("drm/amd/display: color space ycbcr709 support")
+Reviewed-by: Melissa Wen <mwen@igalia.com>
+Signed-off-by: Joshua Ashton <joshua@froggi.es>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
++++ b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
+@@ -92,8 +92,8 @@ static const struct out_csc_color_matrix
+ { 0xE00, 0xF349, 0xFEB7, 0x1000, 0x6CE, 0x16E3,
+ 0x24F, 0x200, 0xFCCB, 0xF535, 0xE00, 0x1000} },
+ { COLOR_SPACE_YCBCR2020_TYPE,
+- { 0x1000, 0xF149, 0xFEB7, 0x0000, 0x0868, 0x15B2,
+- 0x01E6, 0x0000, 0xFB88, 0xF478, 0x1000, 0x0000} },
++ { 0x1000, 0xF149, 0xFEB7, 0x1004, 0x0868, 0x15B2,
++ 0x01E6, 0x201, 0xFB88, 0xF478, 0x1000, 0x1004} },
+ { COLOR_SPACE_YCBCR709_BLACK_TYPE,
+ { 0x0000, 0x0000, 0x0000, 0x1000, 0x0000, 0x0000,
+ 0x0000, 0x0200, 0x0000, 0x0000, 0x0000, 0x1000} },
--- /dev/null
+From 040625ab82ce6dca7772cb3867fe5c9eb279a344 Mon Sep 17 00:00:00 2001
+From: hongao <hongao@uniontech.com>
+Date: Tue, 22 Nov 2022 19:20:34 +0800
+Subject: drm/amd/display: Fix set scaling doesn's work
+
+From: hongao <hongao@uniontech.com>
+
+commit 040625ab82ce6dca7772cb3867fe5c9eb279a344 upstream.
+
+[Why]
+Setting scaling does not correctly update CRTC state. As a result
+dc stream state's src (composition area) && dest (addressable area)
+was not calculated as expected. This causes set scaling doesn's work.
+
+[How]
+Correctly update CRTC state when setting scaling property.
+
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Tested-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Signed-off-by: hongao <hongao@uniontech.com>
+Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -7409,8 +7409,8 @@ static int amdgpu_dm_atomic_check(struct
+ goto fail;
+ }
+
+- if (dm_old_con_state->abm_level !=
+- dm_new_con_state->abm_level)
++ if (dm_old_con_state->abm_level != dm_new_con_state->abm_level ||
++ dm_old_con_state->scaling != dm_new_con_state->scaling)
+ new_crtc_state->connectors_changed = true;
+ }
+
--- /dev/null
+From 67b0b4ed259e425b7eed09da75b42c80682ca003 Mon Sep 17 00:00:00 2001
+From: Sasa Dragic <sasa.dragic@gmail.com>
+Date: Mon, 19 Dec 2022 18:29:27 +0100
+Subject: drm/i915: re-disable RC6p on Sandy Bridge
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sasa Dragic <sasa.dragic@gmail.com>
+
+commit 67b0b4ed259e425b7eed09da75b42c80682ca003 upstream.
+
+RC6p on Sandy Bridge got re-enabled over time, causing visual glitches
+and GPU hangs.
+
+Disabled originally in commit 1c8ecf80fdee ("drm/i915: do not enable
+RC6p on Sandy Bridge").
+
+Signed-off-by: Sasa Dragic <sasa.dragic@gmail.com>
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221219172927.9603-2-sasa.dragic@gmail.com
+Fixes: fb6db0f5bf1d ("drm/i915: Remove unsafe i915.enable_rc6")
+Fixes: 13c5a577b342 ("drm/i915/gt: Select the deepest available parking mode for rc6")
+Cc: stable@vger.kernel.org
+Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+(cherry picked from commit 0c8a6e9ea232c221976a0670256bd861408d9917)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/i915_pci.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_pci.c
++++ b/drivers/gpu/drm/i915/i915_pci.c
+@@ -418,7 +418,8 @@ static const struct intel_device_info in
+ .has_coherent_ggtt = true, \
+ .has_llc = 1, \
+ .has_rc6 = 1, \
+- .has_rc6p = 1, \
++ /* snb does support rc6p, but enabling it causes various issues */ \
++ .has_rc6p = 0, \
+ .has_rps = true, \
+ .ppgtt_type = INTEL_PPGTT_FULL, \
+ .ppgtt_size = 31, \
--- /dev/null
+From e181119046a0ec16126b682163040e8e33f310c1 Mon Sep 17 00:00:00 2001
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Mon, 16 Jan 2023 21:19:03 +0100
+Subject: dt-bindings: phy: g12a-usb3-pcie-phy: fix compatible string documentation
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+commit e181119046a0ec16126b682163040e8e33f310c1 upstream.
+
+The compatible string in the driver doesn't have the meson prefix.
+Fix this in the documentation and rename the file accordingly.
+
+Fixes: 87a55485f2fc ("dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/0a82be92-ce85-da34-9d6f-4b33034473e5@gmail.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml | 57 ++++++++++
+ Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml | 57 ----------
+ 2 files changed, 57 insertions(+), 57 deletions(-)
+ rename Documentation/devicetree/bindings/phy/{amlogic,meson-g12a-usb3-pcie-phy.yaml => amlogic,g12a-usb3-pcie-phy.yaml} (82%)
+
+--- /dev/null
++++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml
+@@ -0,0 +1,57 @@
++# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
++# Copyright 2019 BayLibre, SAS
++%YAML 1.2
++---
++$id: "http://devicetree.org/schemas/phy/amlogic,g12a-usb3-pcie-phy.yaml#"
++$schema: "http://devicetree.org/meta-schemas/core.yaml#"
++
++title: Amlogic G12A USB3 + PCIE Combo PHY
++
++maintainers:
++ - Neil Armstrong <narmstrong@baylibre.com>
++
++properties:
++ compatible:
++ enum:
++ - amlogic,g12a-usb3-pcie-phy
++
++ reg:
++ maxItems: 1
++
++ clocks:
++ maxItems: 1
++
++ clock-names:
++ items:
++ - const: ref_clk
++
++ resets:
++ maxItems: 1
++
++ reset-names:
++ items:
++ - const: phy
++
++ "#phy-cells":
++ const: 1
++
++required:
++ - compatible
++ - reg
++ - clocks
++ - clock-names
++ - resets
++ - reset-names
++ - "#phy-cells"
++
++examples:
++ - |
++ phy@46000 {
++ compatible = "amlogic,g12a-usb3-pcie-phy";
++ reg = <0x46000 0x2000>;
++ clocks = <&ref_clk>;
++ clock-names = "ref_clk";
++ resets = <&phy_reset>;
++ reset-names = "phy";
++ #phy-cells = <1>;
++ };
+--- a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
++++ /dev/null
+@@ -1,57 +0,0 @@
+-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+-# Copyright 2019 BayLibre, SAS
+-%YAML 1.2
+----
+-$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml#"
+-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+-
+-title: Amlogic G12A USB3 + PCIE Combo PHY
+-
+-maintainers:
+- - Neil Armstrong <narmstrong@baylibre.com>
+-
+-properties:
+- compatible:
+- enum:
+- - amlogic,meson-g12a-usb3-pcie-phy
+-
+- reg:
+- maxItems: 1
+-
+- clocks:
+- maxItems: 1
+-
+- clock-names:
+- items:
+- - const: ref_clk
+-
+- resets:
+- maxItems: 1
+-
+- reset-names:
+- items:
+- - const: phy
+-
+- "#phy-cells":
+- const: 1
+-
+-required:
+- - compatible
+- - reg
+- - clocks
+- - clock-names
+- - resets
+- - reset-names
+- - "#phy-cells"
+-
+-examples:
+- - |
+- phy@46000 {
+- compatible = "amlogic,meson-g12a-usb3-pcie-phy";
+- reg = <0x46000 0x2000>;
+- clocks = <&ref_clk>;
+- clock-names = "ref_clk";
+- resets = <&phy_reset>;
+- reset-names = "phy";
+- #phy-cells = <1>;
+- };
--- /dev/null
+From a769b05eeed7accc4019a1ed9799dd72067f1ce8 Mon Sep 17 00:00:00 2001
+From: Khazhismel Kumykov <khazhy@chromium.org>
+Date: Tue, 17 Jan 2023 17:02:12 -0800
+Subject: gsmi: fix null-deref in gsmi_get_variable
+
+From: Khazhismel Kumykov <khazhy@chromium.org>
+
+commit a769b05eeed7accc4019a1ed9799dd72067f1ce8 upstream.
+
+We can get EFI variables without fetching the attribute, so we must
+allow for that in gsmi.
+
+commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
+access layer") added a new get_variable call with attr=NULL, which
+triggers panic in gsmi.
+
+Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
+Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/google/gsmi.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/firmware/google/gsmi.c
++++ b/drivers/firmware/google/gsmi.c
+@@ -359,9 +359,10 @@ static efi_status_t gsmi_get_variable(ef
+ memcpy(data, gsmi_dev.data_buf->start, *data_size);
+
+ /* All variables are have the following attributes */
+- *attr = EFI_VARIABLE_NON_VOLATILE |
+- EFI_VARIABLE_BOOTSERVICE_ACCESS |
+- EFI_VARIABLE_RUNTIME_ACCESS;
++ if (attr)
++ *attr = EFI_VARIABLE_NON_VOLATILE |
++ EFI_VARIABLE_BOOTSERVICE_ACCESS |
++ EFI_VARIABLE_RUNTIME_ACCESS;
+ }
+
+ spin_unlock_irqrestore(&gsmi_dev.lock, flags);
--- /dev/null
+From 5bfdd3c654bd879bff50c2e85e42f85ae698b42f Mon Sep 17 00:00:00 2001
+From: Tobias Schramm <t.schramm@manjaro.org>
+Date: Mon, 9 Jan 2023 08:29:40 +0100
+Subject: serial: atmel: fix incorrect baudrate setup
+
+From: Tobias Schramm <t.schramm@manjaro.org>
+
+commit 5bfdd3c654bd879bff50c2e85e42f85ae698b42f upstream.
+
+Commit ba47f97a18f2 ("serial: core: remove baud_rates when serial console
+setup") changed uart_set_options to select the correct baudrate
+configuration based on the absolute error between requested baudrate and
+available standard baudrate settings.
+Prior to that commit the baudrate was selected based on which predefined
+standard baudrate did not exceed the requested baudrate.
+This change of selection logic was never reflected in the atmel serial
+driver. Thus the comment left in the atmel serial driver is no longer
+accurate.
+Additionally the manual rounding up described in that comment and applied
+via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses
+tty_termios_encode_baud_rate to determine the appropriate baudrate flags
+this can cause baudrate selection to fail entirely because
+tty_termios_encode_baud_rate will only select a baudrate if relative error
+between requested and selected baudrate does not exceed +/-2%.
+Fix that by requesting actual, exact baudrate used by the serial.
+
+Fixes: ba47f97a18f2 ("serial: core: remove baud_rates when serial console setup")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
+Acked-by: Richard Genoud <richard.genoud@gmail.com>
+Link: https://lore.kernel.org/r/20230109072940.202936-1-t.schramm@manjaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/atmel_serial.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/drivers/tty/serial/atmel_serial.c
++++ b/drivers/tty/serial/atmel_serial.c
+@@ -2642,13 +2642,7 @@ static void __init atmel_console_get_opt
+ else if (mr == ATMEL_US_PAR_ODD)
+ *parity = 'o';
+
+- /*
+- * The serial core only rounds down when matching this to a
+- * supported baud rate. Make sure we don't end up slightly
+- * lower than one of those, as it would make us fall through
+- * to a much lower baud rate than we really want.
+- */
+- *baud = port->uartclk / (16 * (quot - 1));
++ *baud = port->uartclk / (16 * quot);
+ }
+
+ static int __init atmel_console_setup(struct console *co, char *options)
--- /dev/null
+From e8914b52e5b024e4af3d810a935fe0805eee8a36 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
+Date: Tue, 3 Jan 2023 11:34:35 +0200
+Subject: serial: pch_uart: Pass correct sg to dma_unmap_sg()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+
+commit e8914b52e5b024e4af3d810a935fe0805eee8a36 upstream.
+
+A local variable sg is used to store scatterlist pointer in
+pch_dma_tx_complete(). The for loop doing Tx byte accounting before
+dma_unmap_sg() alters sg in its increment statement. Therefore, the
+pointer passed into dma_unmap_sg() won't match to the one given to
+dma_map_sg().
+
+To fix the problem, use priv->sg_tx_p directly in dma_unmap_sg()
+instead of the local variable.
+
+Fixes: da3564ee027e ("pch_uart: add multi-scatter processing")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Link: https://lore.kernel.org/r/20230103093435.4396-1-ilpo.jarvinen@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/pch_uart.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/pch_uart.c
++++ b/drivers/tty/serial/pch_uart.c
+@@ -776,7 +776,7 @@ static void pch_dma_tx_complete(void *ar
+ }
+ xmit->tail &= UART_XMIT_SIZE - 1;
+ async_tx_ack(priv->desc_tx);
+- dma_unmap_sg(port->dev, sg, priv->orig_nent, DMA_TO_DEVICE);
++ dma_unmap_sg(port->dev, priv->sg_tx_p, priv->orig_nent, DMA_TO_DEVICE);
+ priv->tx_dma_use = 0;
+ priv->nent = 0;
+ priv->orig_nent = 0;
mmc-sunxi-mmc-fix-clock-refcount-imbalance-during-unbind.patch
btrfs-fix-race-between-quota-rescan-and-disable-leading-to-null-pointer-deref.patch
cifs-do-not-include-page-data-when-checking-signature.patch
+usb-gadgetfs-fix-race-between-mounting-and-unmounting.patch
+usb-serial-cp210x-add-scalance-lpe-9000-device-id.patch
+usb-host-ehci-fsl-fix-module-alias.patch
+usb-typec-altmodes-displayport-add-pin-assignment-helper.patch
+usb-typec-altmodes-displayport-fix-pin-assignment-calculation.patch
+usb-gadget-g_webcam-send-color-matching-descriptor-per-frame.patch
+usb-gadget-f_ncm-fix-potential-null-ptr-deref-in-ncm_bitrate.patch
+usb-storage-apply-ignore_uas-only-for-hiksemi-md202-on-rtl9210.patch
+dt-bindings-phy-g12a-usb3-pcie-phy-fix-compatible-string-documentation.patch
+serial-pch_uart-pass-correct-sg-to-dma_unmap_sg.patch
+dmaengine-tegra210-adma-fix-global-intr-clear.patch
+serial-atmel-fix-incorrect-baudrate-setup.patch
+gsmi-fix-null-deref-in-gsmi_get_variable.patch
+drm-i915-re-disable-rc6p-on-sandy-bridge.patch
+drm-amd-display-fix-set-scaling-doesn-s-work.patch
+drm-amd-display-fix-color_space_ycbcr2020_type-matrix.patch
--- /dev/null
+From c6ec929595c7443250b2a4faea988c62019d5cd2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Maciej=20=C5=BBenczykowski?= <maze@google.com>
+Date: Tue, 17 Jan 2023 05:18:39 -0800
+Subject: usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej Żenczykowski <maze@google.com>
+
+commit c6ec929595c7443250b2a4faea988c62019d5cd2 upstream.
+
+In Google internal bug 265639009 we've received an (as yet) unreproducible
+crash report from an aarch64 GKI 5.10.149-android13 running device.
+
+AFAICT the source code is at:
+ https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10
+
+The call stack is:
+ ncm_close() -> ncm_notify() -> ncm_do_notify()
+with the crash at:
+ ncm_do_notify+0x98/0x270
+Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)
+
+Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):
+
+ // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification)
+ 0B 0D 00 79 strh w11, [x8, #6]
+
+ // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request)
+ 6C 0A 00 B9 str w12, [x19, #8]
+
+ // x10 (NULL) was read here from offset 0 of valid pointer x9
+ // IMHO we're reading 'cdev->gadget' and getting NULL
+ // gadget is indeed at offset 0 of struct usb_composite_dev
+ 2A 01 40 F9 ldr x10, [x9]
+
+ // loading req->buf pointer, which is at offset 0 of struct usb_request
+ 69 02 40 F9 ldr x9, [x19]
+
+ // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed
+ 4B 5D 40 B9 ldr w11, [x10, #0x5c]
+
+which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:
+
+ event->wLength = cpu_to_le16(8);
+ req->length = NCM_STATUS_BYTECOUNT;
+
+ /* SPEED_CHANGE data is up/down speeds in bits/sec */
+ data = req->buf + sizeof *event;
+ data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
+
+My analysis of registers and NULL ptr deref crash offset
+ (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
+heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing:
+ data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
+which calls:
+ ncm_bitrate(NULL)
+which then calls:
+ gadget_is_superspeed(NULL)
+which reads
+ ((struct usb_gadget *)NULL)->max_speed
+and hits a panic.
+
+AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
+(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)
+
+It's not at all clear to me how this is all supposed to work...
+but returning 0 seems much better than panic-ing...
+
+Cc: Felipe Balbi <balbi@kernel.org>
+Cc: Lorenzo Colitti <lorenzo@google.com>
+Cc: Carlos Llamas <cmllamas@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Maciej Żenczykowski <maze@google.com>
+Cc: stable <stable@kernel.org>
+Link: https://lore.kernel.org/r/20230117131839.1138208-1-maze@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_ncm.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/gadget/function/f_ncm.c
++++ b/drivers/usb/gadget/function/f_ncm.c
+@@ -85,7 +85,9 @@ static inline struct f_ncm *func_to_ncm(
+ /* peak (theoretical) bulk transfer rate in bits-per-second */
+ static inline unsigned ncm_bitrate(struct usb_gadget *g)
+ {
+- if (gadget_is_superspeed(g) && g->speed >= USB_SPEED_SUPER_PLUS)
++ if (!g)
++ return 0;
++ else if (gadget_is_superspeed(g) && g->speed >= USB_SPEED_SUPER_PLUS)
+ return 4250000000U;
+ else if (gadget_is_superspeed(g) && g->speed == USB_SPEED_SUPER)
+ return 3750000000U;
--- /dev/null
+From e95765e97d9cb93258a4840440d410fa6ff7e819 Mon Sep 17 00:00:00 2001
+From: Daniel Scally <dan.scally@ideasonboard.com>
+Date: Fri, 16 Dec 2022 16:05:28 +0000
+Subject: usb: gadget: g_webcam: Send color matching descriptor per frame
+
+From: Daniel Scally <dan.scally@ideasonboard.com>
+
+commit e95765e97d9cb93258a4840440d410fa6ff7e819 upstream.
+
+Currently the color matching descriptor is only sent across the wire
+a single time, following the descriptors for each format and frame.
+According to the UVC 1.5 Specification 3.9.2.6 ("Color Matching
+Descriptors"):
+
+"Only one instance is allowed for a given format and if present,
+the Color Matching descriptor shall be placed following the Video
+and Still Image Frame descriptors for that format".
+
+Add another reference to the color matching descriptor after the
+yuyv frames so that it's correctly transmitted for that format
+too.
+
+Fixes: a9914127e834 ("USB gadget: Webcam device")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
+Link: https://lore.kernel.org/r/20221216160528.479094-1-dan.scally@ideasonboard.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/legacy/webcam.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/gadget/legacy/webcam.c
++++ b/drivers/usb/gadget/legacy/webcam.c
+@@ -293,6 +293,7 @@ static const struct uvc_descriptor_heade
+ (const struct uvc_descriptor_header *) &uvc_format_yuv,
+ (const struct uvc_descriptor_header *) &uvc_frame_yuv_360p,
+ (const struct uvc_descriptor_header *) &uvc_frame_yuv_720p,
++ (const struct uvc_descriptor_header *) &uvc_color_matching,
+ (const struct uvc_descriptor_header *) &uvc_format_mjpg,
+ (const struct uvc_descriptor_header *) &uvc_frame_mjpg_360p,
+ (const struct uvc_descriptor_header *) &uvc_frame_mjpg_720p,
+@@ -305,6 +306,7 @@ static const struct uvc_descriptor_heade
+ (const struct uvc_descriptor_header *) &uvc_format_yuv,
+ (const struct uvc_descriptor_header *) &uvc_frame_yuv_360p,
+ (const struct uvc_descriptor_header *) &uvc_frame_yuv_720p,
++ (const struct uvc_descriptor_header *) &uvc_color_matching,
+ (const struct uvc_descriptor_header *) &uvc_format_mjpg,
+ (const struct uvc_descriptor_header *) &uvc_frame_mjpg_360p,
+ (const struct uvc_descriptor_header *) &uvc_frame_mjpg_720p,
+@@ -317,6 +319,7 @@ static const struct uvc_descriptor_heade
+ (const struct uvc_descriptor_header *) &uvc_format_yuv,
+ (const struct uvc_descriptor_header *) &uvc_frame_yuv_360p,
+ (const struct uvc_descriptor_header *) &uvc_frame_yuv_720p,
++ (const struct uvc_descriptor_header *) &uvc_color_matching,
+ (const struct uvc_descriptor_header *) &uvc_format_mjpg,
+ (const struct uvc_descriptor_header *) &uvc_frame_mjpg_360p,
+ (const struct uvc_descriptor_header *) &uvc_frame_mjpg_720p,
--- /dev/null
+From d18dcfe9860e842f394e37ba01ca9440ab2178f4 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 23 Dec 2022 09:59:09 -0500
+Subject: USB: gadgetfs: Fix race between mounting and unmounting
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit d18dcfe9860e842f394e37ba01ca9440ab2178f4 upstream.
+
+The syzbot fuzzer and Gerald Lee have identified a use-after-free bug
+in the gadgetfs driver, involving processes concurrently mounting and
+unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()
+can race with gadgetfs_kill_sb(), causing the latter to deallocate
+the_device while the former is using it. The output from KASAN says,
+in part:
+
+BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]
+BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
+BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]
+BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]
+BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]
+BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
+BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
+Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
+
+CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
+Call Trace:
+ <TASK>
+...
+ atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]
+ __refcount_sub_and_test include/linux/refcount.h:272 [inline]
+ __refcount_dec_and_test include/linux/refcount.h:315 [inline]
+ refcount_dec_and_test include/linux/refcount.h:333 [inline]
+ put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]
+ gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086
+ deactivate_locked_super+0xa7/0xf0 fs/super.c:332
+ vfs_get_super fs/super.c:1190 [inline]
+ get_tree_single+0xd0/0x160 fs/super.c:1207
+ vfs_get_tree+0x88/0x270 fs/super.c:1531
+ vfs_fsconfig_locked fs/fsopen.c:232 [inline]
+
+The simplest solution is to ensure that gadgetfs_fill_super() and
+gadgetfs_kill_sb() are serialized by making them both acquire a new
+mutex.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+33d7ad66d65044b93f16@syzkaller.appspotmail.com
+Reported-and-tested-by: Gerald Lee <sundaywind2004@gmail.com>
+Link: https://lore.kernel.org/linux-usb/CAO3qeMVzXDP-JU6v1u5Ags6Q-bb35kg3=C6d04DjzA9ffa5x1g@mail.gmail.com/
+Fixes: e5d82a7360d1 ("vfs: Convert gadgetfs to use the new mount API")
+CC: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/Y6XCPXBpn3tmjdCC@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/legacy/inode.c | 28 +++++++++++++++++++++-------
+ 1 file changed, 21 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/gadget/legacy/inode.c
++++ b/drivers/usb/gadget/legacy/inode.c
+@@ -229,6 +229,7 @@ static void put_ep (struct ep_data *data
+ */
+
+ static const char *CHIP;
++static DEFINE_MUTEX(sb_mutex); /* Serialize superblock operations */
+
+ /*----------------------------------------------------------------------*/
+
+@@ -2013,13 +2014,20 @@ gadgetfs_fill_super (struct super_block
+ {
+ struct inode *inode;
+ struct dev_data *dev;
++ int rc;
+
+- if (the_device)
+- return -ESRCH;
++ mutex_lock(&sb_mutex);
++
++ if (the_device) {
++ rc = -ESRCH;
++ goto Done;
++ }
+
+ CHIP = usb_get_gadget_udc_name();
+- if (!CHIP)
+- return -ENODEV;
++ if (!CHIP) {
++ rc = -ENODEV;
++ goto Done;
++ }
+
+ /* superblock */
+ sb->s_blocksize = PAGE_SIZE;
+@@ -2056,13 +2064,17 @@ gadgetfs_fill_super (struct super_block
+ * from binding to a controller.
+ */
+ the_device = dev;
+- return 0;
++ rc = 0;
++ goto Done;
+
+-Enomem:
++ Enomem:
+ kfree(CHIP);
+ CHIP = NULL;
++ rc = -ENOMEM;
+
+- return -ENOMEM;
++ Done:
++ mutex_unlock(&sb_mutex);
++ return rc;
+ }
+
+ /* "mount -t gadgetfs path /dev/gadget" ends up here */
+@@ -2084,6 +2096,7 @@ static int gadgetfs_init_fs_context(stru
+ static void
+ gadgetfs_kill_sb (struct super_block *sb)
+ {
++ mutex_lock(&sb_mutex);
+ kill_litter_super (sb);
+ if (the_device) {
+ put_dev (the_device);
+@@ -2091,6 +2104,7 @@ gadgetfs_kill_sb (struct super_block *sb
+ }
+ kfree(CHIP);
+ CHIP = NULL;
++ mutex_unlock(&sb_mutex);
+ }
+
+ /*----------------------------------------------------------------------*/
--- /dev/null
+From 5d3d01ae15d2f37ed0325c99ab47ef0ae5d05f3c Mon Sep 17 00:00:00 2001
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+Date: Fri, 20 Jan 2023 13:27:14 +0100
+Subject: usb: host: ehci-fsl: Fix module alias
+
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+
+commit 5d3d01ae15d2f37ed0325c99ab47ef0ae5d05f3c upstream.
+
+Commit ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent
+driver module") changed DRV_NAME which was used for MODULE_ALIAS as well.
+Starting from this the module alias didn't match the platform device
+name created in fsl-mph-dr-of.c
+Change DRV_NAME to match the driver name for host mode in fsl-mph-dr-of.
+This is needed for module autoloading on ls1021a.
+
+Fixes: ca07e1c1e4a6 ("drivers:usb:fsl:Make fsl ehci drv an independent driver module")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
+Link: https://lore.kernel.org/r/20230120122714.3848784-1-alexander.stein@ew.tq-group.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/ehci-fsl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/host/ehci-fsl.c
++++ b/drivers/usb/host/ehci-fsl.c
+@@ -29,7 +29,7 @@
+ #include "ehci-fsl.h"
+
+ #define DRIVER_DESC "Freescale EHCI Host controller driver"
+-#define DRV_NAME "ehci-fsl"
++#define DRV_NAME "fsl-ehci"
+
+ static struct hc_driver __read_mostly fsl_ehci_hc_driver;
+
--- /dev/null
+From 3f9e76e31704a325170e5aec2243c8d084d74854 Mon Sep 17 00:00:00 2001
+From: Michael Adler <michael.adler@siemens.com>
+Date: Tue, 3 Jan 2023 14:48:50 +0100
+Subject: USB: serial: cp210x: add SCALANCE LPE-9000 device id
+
+From: Michael Adler <michael.adler@siemens.com>
+
+commit 3f9e76e31704a325170e5aec2243c8d084d74854 upstream.
+
+Add the USB serial console device ID for Siemens SCALANCE LPE-9000
+which have a USB port for their serial console.
+
+Signed-off-by: Michael Adler <michael.adler@siemens.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/cp210x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/serial/cp210x.c
++++ b/drivers/usb/serial/cp210x.c
+@@ -61,6 +61,7 @@ static const struct usb_device_id id_tab
+ { USB_DEVICE(0x0846, 0x1100) }, /* NetGear Managed Switch M4100 series, M5300 series, M7100 series */
+ { USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless smartcard reader */
+ { USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC Device */
++ { USB_DEVICE(0x0908, 0x0070) }, /* Siemens SCALANCE LPE-9000 USB Serial Console */
+ { USB_DEVICE(0x0908, 0x01FF) }, /* Siemens RUGGEDCOM USB Serial Console */
+ { USB_DEVICE(0x0988, 0x0578) }, /* Teraoka AD2000 */
+ { USB_DEVICE(0x0B00, 0x3070) }, /* Ingenico 3070 */
--- /dev/null
+From dbd24ec17b85b45f4e823d1aa5607721920f2b05 Mon Sep 17 00:00:00 2001
+From: Juhyung Park <qkrwngud825@gmail.com>
+Date: Tue, 17 Jan 2023 17:51:54 +0900
+Subject: usb-storage: apply IGNORE_UAS only for HIKSEMI MD202 on RTL9210
+
+From: Juhyung Park <qkrwngud825@gmail.com>
+
+commit dbd24ec17b85b45f4e823d1aa5607721920f2b05 upstream.
+
+The commit e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
+blacklists UAS for all of RTL9210 enclosures.
+
+The RTL9210 controller was advertised with UAS since its release back in
+2019 and was shipped with a lot of enclosure products with different
+firmware combinations.
+
+Blacklist UAS only for HIKSEMI MD202.
+
+This should hopefully be replaced with more robust method than just
+comparing strings. But with limited information [1] provided thus far
+(dmesg when the device is plugged in, which includes manufacturer and
+product, but no lsusb -v to compare against), this is the best we can do
+for now.
+
+[1] https://lore.kernel.org/all/20230109115550.71688-1-qkrwngud825@gmail.com
+
+Fixes: e00b488e813f ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS")
+Cc: Alan Stern <stern@rowland.harvard.edu>
+Cc: Hongling Zeng <zenghongling@kylinos.cn>
+Cc: stable@vger.kernel.org
+Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
+Acked-by: Oliver Neukum <oneukum@suse.com>
+Link: https://lore.kernel.org/r/20230117085154.123301-1-qkrwngud825@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/uas-detect.h | 13 +++++++++++++
+ drivers/usb/storage/unusual_uas.h | 7 -------
+ 2 files changed, 13 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/storage/uas-detect.h
++++ b/drivers/usb/storage/uas-detect.h
+@@ -116,6 +116,19 @@ static int uas_use_uas_driver(struct usb
+ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bc2)
+ flags |= US_FL_NO_ATA_1X;
+
++ /*
++ * RTL9210-based enclosure from HIKSEMI, MD202 reportedly have issues
++ * with UAS. This isn't distinguishable with just idVendor and
++ * idProduct, use manufacturer and product too.
++ *
++ * Reported-by: Hongling Zeng <zenghongling@kylinos.cn>
++ */
++ if (le16_to_cpu(udev->descriptor.idVendor) == 0x0bda &&
++ le16_to_cpu(udev->descriptor.idProduct) == 0x9210 &&
++ (udev->manufacturer && !strcmp(udev->manufacturer, "HIKSEMI")) &&
++ (udev->product && !strcmp(udev->product, "MD202")))
++ flags |= US_FL_IGNORE_UAS;
++
+ usb_stor_adjust_quirks(udev, &flags);
+
+ if (flags & US_FL_IGNORE_UAS) {
+--- a/drivers/usb/storage/unusual_uas.h
++++ b/drivers/usb/storage/unusual_uas.h
+@@ -83,13 +83,6 @@ UNUSUAL_DEV(0x0bc2, 0x331a, 0x0000, 0x99
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_REPORT_LUNS),
+
+-/* Reported-by: Hongling Zeng <zenghongling@kylinos.cn> */
+-UNUSUAL_DEV(0x0bda, 0x9210, 0x0000, 0x9999,
+- "Hiksemi",
+- "External HDD",
+- USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+- US_FL_IGNORE_UAS),
+-
+ /* Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> */
+ UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x9999,
+ "Initio Corporation",
--- /dev/null
+From 582836e3cfab4faafbdc93bbec96fce036a08ee1 Mon Sep 17 00:00:00 2001
+From: Prashant Malani <pmalani@chromium.org>
+Date: Wed, 11 Jan 2023 02:05:41 +0000
+Subject: usb: typec: altmodes/displayport: Add pin assignment helper
+
+From: Prashant Malani <pmalani@chromium.org>
+
+commit 582836e3cfab4faafbdc93bbec96fce036a08ee1 upstream.
+
+The code to extract a peripheral's currently supported Pin Assignments
+is repeated in a couple of locations. Factor it out into a separate
+function.
+
+This will also make it easier to add fixes (we only need to update 1
+location instead of 2).
+
+Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
+Cc: stable@vger.kernel.org
+Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Signed-off-by: Prashant Malani <pmalani@chromium.org>
+Reviewed-by: Benson Leung <bleung@chromium.org>
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20230111020546.3384569-1-pmalani@chromium.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/altmodes/displayport.c | 22 ++++++++++++++--------
+ 1 file changed, 14 insertions(+), 8 deletions(-)
+
+--- a/drivers/usb/typec/altmodes/displayport.c
++++ b/drivers/usb/typec/altmodes/displayport.c
+@@ -407,6 +407,18 @@ static const char * const pin_assignment
+ [DP_PIN_ASSIGN_F] = "F",
+ };
+
++/*
++ * Helper function to extract a peripheral's currently supported
++ * Pin Assignments from its DisplayPort alternate mode state.
++ */
++static u8 get_current_pin_assignments(struct dp_altmode *dp)
++{
++ if (DP_CONF_CURRENTLY(dp->data.conf) == DP_CONF_DFP_D)
++ return DP_CAP_UFP_D_PIN_ASSIGN(dp->alt->vdo);
++ else
++ return DP_CAP_DFP_D_PIN_ASSIGN(dp->alt->vdo);
++}
++
+ static ssize_t
+ pin_assignment_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t size)
+@@ -433,10 +445,7 @@ pin_assignment_store(struct device *dev,
+ goto out_unlock;
+ }
+
+- if (DP_CONF_CURRENTLY(dp->data.conf) == DP_CONF_DFP_D)
+- assignments = DP_CAP_UFP_D_PIN_ASSIGN(dp->alt->vdo);
+- else
+- assignments = DP_CAP_DFP_D_PIN_ASSIGN(dp->alt->vdo);
++ assignments = get_current_pin_assignments(dp);
+
+ if (!(DP_CONF_GET_PIN_ASSIGN(conf) & assignments)) {
+ ret = -EINVAL;
+@@ -473,10 +482,7 @@ static ssize_t pin_assignment_show(struc
+
+ cur = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
+
+- if (DP_CONF_CURRENTLY(dp->data.conf) == DP_CONF_DFP_D)
+- assignments = DP_CAP_UFP_D_PIN_ASSIGN(dp->alt->vdo);
+- else
+- assignments = DP_CAP_DFP_D_PIN_ASSIGN(dp->alt->vdo);
++ assignments = get_current_pin_assignments(dp);
+
+ for (i = 0; assignments; assignments >>= 1, i++) {
+ if (assignments & 1) {
--- /dev/null
+From 9682b41e52cc9f42f5c33caf410464392adaef04 Mon Sep 17 00:00:00 2001
+From: Prashant Malani <pmalani@chromium.org>
+Date: Wed, 11 Jan 2023 02:05:42 +0000
+Subject: usb: typec: altmodes/displayport: Fix pin assignment calculation
+
+From: Prashant Malani <pmalani@chromium.org>
+
+commit 9682b41e52cc9f42f5c33caf410464392adaef04 upstream.
+
+Commit c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin
+assignment for UFP receptacles") fixed the pin assignment calculation
+to take into account whether the peripheral was a plug or a receptacle.
+
+But the "pin_assignments" sysfs logic was not updated. Address this by
+using the macros introduced in the aforementioned commit in the sysfs
+logic too.
+
+Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
+Cc: stable@vger.kernel.org
+Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Signed-off-by: Prashant Malani <pmalani@chromium.org>
+Reviewed-by: Benson Leung <bleung@chromium.org>
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20230111020546.3384569-2-pmalani@chromium.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/altmodes/displayport.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/typec/altmodes/displayport.c
++++ b/drivers/usb/typec/altmodes/displayport.c
+@@ -414,9 +414,9 @@ static const char * const pin_assignment
+ static u8 get_current_pin_assignments(struct dp_altmode *dp)
+ {
+ if (DP_CONF_CURRENTLY(dp->data.conf) == DP_CONF_DFP_D)
+- return DP_CAP_UFP_D_PIN_ASSIGN(dp->alt->vdo);
++ return DP_CAP_PIN_ASSIGN_DFP_D(dp->alt->vdo);
+ else
+- return DP_CAP_DFP_D_PIN_ASSIGN(dp->alt->vdo);
++ return DP_CAP_PIN_ASSIGN_UFP_D(dp->alt->vdo);
+ }
+
+ static ssize_t
projects / thirdparty / kernel / stable-queue.git / commitdiff
