6.5.8-rc1 review

Link https://lore.kernel.org/r/1c156a6d8c9170bd6a17825f2277115525b4d50f.1696429960.git.repk@triplefau.lt open here

Signed-off-by Sasha Levin <[email protected]>

---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 30 -------------------
 1 file changed, 30 deletions(-)

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +0 ~~-30~~

index 6931973028aef..e840cadb2d75a 100644
@@ -5940,33 +5940,6 @@ static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
-#ifdef CONFIG_NET_POLL_CONTROLLER
-/* Polling receive - used by NETCONSOLE and other diagnostic tools
- * to allow network I/O with interrupts disabled.
- */
-static void stmmac_poll_controller(struct net_device *dev)
-{
-	struct stmmac_priv *priv = netdev_priv(dev);
-	int i;
-
-	/* If adapter is down, do nothing */
-	if (test_bit(STMMAC_DOWN, &priv->state))
-		return;
-
-	if (priv->plat->multi_msi_en) {
-		for (i = 0; i < priv->plat->rx_queues_to_use; i++)
-			stmmac_msi_intr_rx(0, &priv->dma_conf.rx_queue[i]);
-
-		for (i = 0; i < priv->plat->tx_queues_to_use; i++)
-			stmmac_msi_intr_tx(0, &priv->dma_conf.tx_queue[i]);
-	} else {
-		disable_irq(dev->irq);
-		stmmac_interrupt(dev->irq, dev);
-		enable_irq(dev->irq);
-	}
-}
-#endif
-
 /**
  *  stmmac_ioctl - Entry point for the Ioctl
  *  @dev: Device pointer.

@@ -6802,9 +6775,6 @@ static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_eth_ioctl = stmmac_ioctl,
 	.ndo_setup_tc = stmmac_setup_tc,
 	.ndo_select_queue = stmmac_select_queue,
-#ifdef CONFIG_NET_POLL_CONTROLLER
-	.ndo_poll_controller = stmmac_poll_controller,
-#endif
 	.ndo_set_mac_address = stmmac_set_mac_address,
 	.ndo_vlan_rx_add_vid = stmmac_vlan_rx_add_vid,
 	.ndo_vlan_rx_kill_vid = stmmac_vlan_rx_kill_vid,

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:24 UTC #2 lore raw

PATCH 2/191 RDMA/cxgb4: Check skb value for failure to allocate

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Artem Chernyshev <[email protected]>

[ Upstream commit 8fb8a82086f5bda6893ea6557c5a458e4549c6d7 ]

get_skb() can fail to allocate skb, so check it.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes 5be78ee924ae ("RDMA/cxgb4: Fix LE hash collision bug for active open connection")

Signed-off-by Artem Chernyshev <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Leon Romanovsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/hw/cxgb4/cm.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/infiniband/hw/cxgb4/cm.c +3 -0

index ced615b5ea096..040ba2224f9ff 100644
@@ -1965,6 +1965,9 @@ static int send_fw_act_open_req(struct c4iw_ep *ep, unsigned int atid)
 	int win;
 
 	skb = get_skb(NULL, sizeof(*req), GFP_KERNEL);
+	if (!skb)
+		return -ENOMEM;
+
 	req = __skb_put_zero(skb, sizeof(*req));
 	req->op_compl = htonl(WR_OP_V(FW_OFLD_CONNECTION_WR));
 	req->len16_pkd = htonl(FW_WR_LEN16_V(DIV_ROUND_UP(sizeof(*req), 16)));

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #3 lore raw

PATCH 3/191 perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jing Zhang <[email protected]>

[ Upstream commit 7f949f6f54ff593123ab95b6247bfa4542a65580 ]

The register por_dt_pmovsr Bits[7:0] indicates overflow from counters 7 to 0. But in arm_cmn_handle_irq(), only handled the overflow status of Bits[3:0] which results in unhandled overflow status of counters 4 to 7.

So let the overflow status of DTC counters 4 to 7 to be handled.

Fixes 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")

Signed-off-by Jing Zhang <[email protected]>

Reviewed-by Robin Murphy <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/perf/arm-cmn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/perf/arm-cmn.c +1 -1

index b8c15878bc86d..43aba01399bef 100644
@@ -1862,7 +1862,7 @@ static irqreturn_t arm_cmn_handle_irq(int irq, void *dev_id)
 		u64 delta;
 		int i;
 
-		for (i = 0; i < CMN_DTM_NUM_COUNTERS; i++) {
+		for (i = 0; i < CMN_DT_NUM_COUNTERS; i++) {
 			if (status & (1U << i)) {
 				ret = IRQ_HANDLED;
 				if (WARN_ON(!dtc->counters[i]))

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #4 lore raw

PATCH 4/191 platform/x86: think-lmi: Fix reference leak

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Armin Wolf <[email protected]>

[ Upstream commit 528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81 ]

If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting.
As a side note, a very similar bug was fixed in
commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver.

Compile-tested only.

Fixes 1bcad8e510b2 ("platform/x86: think-lmi: Fix issues with duplicate attributes")

Reviewed-by Mark Pearson <[email protected]>

Reviewed-by Ilpo Järvinen <[email protected]>

Signed-off-by Armin Wolf <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by Hans de Goede <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/platform/x86/think-lmi.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

drivers/platform/x86/think-lmi.c +20 -4

index 79346881cadb1..aee869769843f 100644
@@ -1248,6 +1248,24 @@ static void tlmi_release_attr(void)
 	kset_unregister(tlmi_priv.authentication_kset);
 }
 
+static int tlmi_validate_setting_name(struct kset *attribute_kset, char *name)
+{
+	struct kobject *duplicate;
+
+	if (!strcmp(name, "Reserved"))
+		return -EINVAL;
+
+	duplicate = kset_find_obj(attribute_kset, name);
+	if (duplicate) {
+		pr_debug("Duplicate attribute name found - %s\n", name);
+		/* kset_find_obj() returns a reference */
+		kobject_put(duplicate);
+		return -EBUSY;
+	}
+
+	return 0;
+}
+
 static int tlmi_sysfs_init(void)
 {
 	int i, ret;

@@ -1276,10 +1294,8 @@ static int tlmi_sysfs_init(void)
 			continue;
 
 		/* check for duplicate or reserved values */
-		if (kset_find_obj(tlmi_priv.attribute_kset, tlmi_priv.setting[i]->display_name) ||
-		    !strcmp(tlmi_priv.setting[i]->display_name, "Reserved")) {
-			pr_debug("duplicate or reserved attribute name found - %s\n",
-				tlmi_priv.setting[i]->display_name);
+		if (tlmi_validate_setting_name(tlmi_priv.attribute_kset,
+					       tlmi_priv.setting[i]->display_name) < 0) {
 			kfree(tlmi_priv.setting[i]->possible_values);
 			kfree(tlmi_priv.setting[i]);
 			tlmi_priv.setting[i] = NULL;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #5 lore raw

PATCH 5/191 drm/i915: Register engines early to avoid type confusion

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Krause <[email protected]>

[ Upstream commit 6007265ad70a87aa9b4eea79b5e5828da452cfd8 ]

Commit 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine map") switched from using for_each_engine() to for_each_uabi_engine() to iterate over the user engines. While this seems to be a sensible change, it's only safe to do when the engines are actually chained using the rb-tree structure which is not the case during early driver initialization where it can be either a lock-less list or regular double-linked list.

In fact, the modesetting initialization code may end up calling default_engines() through the fb helper code while the engines list is still llist_node-based:

i915_driver_probe() ->

    intel_display_driver_probe() ->
      intel_fbdev_init() ->
        drm_fb_helper_init() ->
          drm_client_init() ->
            drm_client_open() ->
              drm_file_alloc() ->
                i915_driver_open() ->
                  i915_gem_open() ->
                    i915_gem_context_open() ->
                      i915_gem_create_context() ->
                        default_engines()

Using for_each_uabi_engine() in default_engines() is therefore wrong, as it would try to interpret the llist as rb-tree, making it find no engine at all, as the rb_left and rb_right members will still be NULL, as they haven't been initialized yet.

To fix this type confusion register the engines earlier and at the same time reduce the amount of code that has to deal with the intermediate llist state.

Reported-by sanity checks in grsecurity

Fixes 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine map")

Signed-off-by Mathias Krause <[email protected]>

Cc Jonathan Cavitt <[email protected]>

Cc Tvrtko Ursulin <[email protected]>

Reviewed-by Tvrtko Ursulin <[email protected]>

Signed-off-by Tvrtko Ursulin <[email protected]>

[tursulin: fixed commit tag typo]

(cherry picked from commit 2b562f032fc2594fb3fac22b7a2eb3c1969a7ba3)

Signed-off-by Rodrigo Vivi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/i915/i915_gem.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

drivers/gpu/drm/i915/i915_gem.c +7 -2

index 1f65bb33dd212..a8551ce322de2 100644
@@ -1199,6 +1199,13 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 			goto err_unlock;
 	}
 
+	/*
+	 * Register engines early to ensure the engine list is in its final
+	 * rb-tree form, lowering the amount of code that has to deal with
+	 * the intermediate llist state.
+	 */
+	intel_engines_driver_register(dev_priv);
+
 	return 0;
 
 	/*

@@ -1246,8 +1253,6 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 void i915_gem_driver_register(struct drm_i915_private *i915)
 {
 	i915_gem_driver_register__shrinker(i915);
-
-	intel_engines_driver_register(i915);
 }
 
 void i915_gem_driver_unregister(struct drm_i915_private *i915)

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #6 lore raw

PATCH 6/191 arm_pmu: acpi: Add a representative platform device for TRBE

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Anshuman Khandual <[email protected]>

[ Upstream commit 1aa3d0274a4aac338ee45a3dfc3b17c944bcc2bc ]

ACPI TRBE does not have a HID for identification which could create and add a platform device into the platform bus. Also without a platform device, it cannot be probed and bound to a platform driver.

This creates a dummy platform device for TRBE after ascertaining that ACPI provides required interrupts uniformly across all cpus on the system. This device gets created inside drivers/perf/arm_pmu_acpi.c to accommodate TRBE being built as a module.

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Mark Rutland <[email protected]>

Full build log:
https://copr-be.cloud.fedoraproject.org/results/@kernel-vanilla/stable-rc/fedora-37-aarch64/06529454-stablerc-stablerc-releases/builder-live.log.gz

Signed-off-by Anshuman Khandual <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Will Deacon <[email protected]>

Stable-dep-of: 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer")

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/include/asm/acpi.h |  3 +++
 drivers/perf/arm_pmu_acpi.c   | 35 +++++++++++++++++++++++++++++++++++
 include/linux/perf/arm_pmu.h  |  1 +
 3 files changed, 39 insertions(+)

arch/arm64/include/asm/acpi.h +3 -0

index bd68e1b7f29f3..4d537d56eb847 100644
@@ -42,6 +42,9 @@
 #define ACPI_MADT_GICC_SPE  (offsetof(struct acpi_madt_generic_interrupt, \
 	spe_interrupt) + sizeof(u16))
 
+#define ACPI_MADT_GICC_TRBE  (offsetof(struct acpi_madt_generic_interrupt, \
+	trbe_interrupt) + sizeof(u16))
+
 /* Basic configuration for ACPI */
 #ifdef	CONFIG_ACPI
 pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);

drivers/perf/arm_pmu_acpi.c +35 -0

index 90815ad762ebc..8baeeb369118e 100644
@@ -139,6 +139,40 @@ static inline void arm_spe_acpi_register_device(void)
 }
 #endif /* CONFIG_ARM_SPE_PMU */
 
+#if IS_ENABLED(CONFIG_CORESIGHT_TRBE)
+static struct resource trbe_resources[] = {
+	{
+		/* irq */
+		.flags          = IORESOURCE_IRQ,
+	}
+};
+
+static struct platform_device trbe_dev = {
+	.name = ARMV8_TRBE_PDEV_NAME,
+	.id = -1,
+	.resource = trbe_resources,
+	.num_resources = ARRAY_SIZE(trbe_resources)
+};
+
+static u16 arm_trbe_parse_gsi(struct acpi_madt_generic_interrupt *gicc)
+{
+	return gicc->trbe_interrupt;
+}
+
+static void arm_trbe_acpi_register_device(void)
+{
+	int ret = arm_acpi_register_pmu_device(&trbe_dev, ACPI_MADT_GICC_TRBE,
+					       arm_trbe_parse_gsi);
+	if (ret)
+		pr_warn("ACPI: TRBE: Unable to register device\n");
+}
+#else
+static inline void arm_trbe_acpi_register_device(void)
+{
+
+}
+#endif /* CONFIG_CORESIGHT_TRBE */
+
 static int arm_pmu_acpi_parse_irqs(void)
 {
 	int irq, cpu, irq_cpu, err;

@@ -374,6 +408,7 @@ static int arm_pmu_acpi_init(void)
 		return 0;
 
 	arm_spe_acpi_register_device();
+	arm_trbe_acpi_register_device();
 
 	return 0;
 }

include/linux/perf/arm_pmu.h +1 -0

index a0801f68762bf..143fbc10ecfe0 100644
@@ -187,5 +187,6 @@ void armpmu_free_irq(int irq, int cpu);
 #endif /* CONFIG_ARM_PMU */
 
 #define ARMV8_SPE_PDEV_NAME "arm,spe-v1"
+#define ARMV8_TRBE_PDEV_NAME "arm,trbe"
 
 #endif /* __ARM_PMU_H__ */

Signature · 1 line

2.40.1

Thorsten Leemhuis

2023-10-16 16:06 UTC #7 lore raw

Re: [PATCH 6.5 006/191] arm_pmu: acpi: Add a representative platform device for TRBE

Quoted 25 lines · Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
[ Upstream commit 1aa3d0274a4aac338ee45a3dfc3b17c944bcc2bc ]
ACPI TRBE does not have a HID for identification which could create and add a platform device into the platform bus. Also without a platform device, it cannot be probed and bound to a platform driver.
This creates a dummy platform device for TRBE after ascertaining that ACPI provides required interrupts uniformly across all cpus on the system. This device gets created inside drivers/perf/arm_pmu_acpi.c to accommodate TRBE being built as a module.
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Mark Rutland <[email protected]>
Cc [email protected]
Cc [email protected]
Signed-off-by Anshuman Khandual <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Will Deacon <[email protected]>

Quoted 2 lines

Stable-dep-of: 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer")
Signed-off-by Sasha Levin <[email protected]>

Got a compiler error when using Fedora's stable kernel config and compiling 6.5.8-rc1 for ARM64; not totally sure, but from the error msg I suspect it's caused by the change quoted above.

"""
+ /usr/bin/make -s 'HOSTCFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes' ARCH=arm64 'KCFLAGS= ' WITH_GCOV=0 -j4 vmlinuz.efi
drivers/perf/arm_pmu_acpi.c: In function 'arm_trbe_acpi_register_device':
drivers/perf/arm_pmu_acpi.c:164:19: error: implicit declaration of function 'arm_acpi_register_pmu_device'; did you mean 'arm_spe_acpi_register_device'? [-Werror=implicit-function-declaration]
164 | int ret = arm_acpi_register_pmu_device(&trbe_dev,
ACPI_MADT_GICC_TRBE,

      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                   arm_spe_acpi_register_device

cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:243: drivers/perf/arm_pmu_acpi.o]
Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:480: drivers/perf] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [scripts/Makefile.build:480: drivers] Error 2
make[1]: *** [/builddir/build/BUILD/kernel-6.5.8-rc1/linux-6.5.8-0.rc1.150.vanilla.fc37.aarch64/Makefile:2036:
.] Error 2
make: *** [Makefile:236: __sub-make] Error 2
"""

Ciao, Thorsten

Quoted 84 lines

---
 arch/arm64/include/asm/acpi.h |  3 +++
 drivers/perf/arm_pmu_acpi.c   | 35 +++++++++++++++++++++++++++++++++++
 include/linux/perf/arm_pmu.h  |  1 +
 3 files changed, 39 insertions(+)

arch/arm64/include/asm/acpi.h +3 -0

index bd68e1b7f29f3..4d537d56eb847 100644
@@ -42,6 +42,9 @@
 #define ACPI_MADT_GICC_SPE  (offsetof(struct acpi_madt_generic_interrupt, \
 	spe_interrupt) + sizeof(u16))
 
+#define ACPI_MADT_GICC_TRBE  (offsetof(struct acpi_madt_generic_interrupt, \
+	trbe_interrupt) + sizeof(u16))
+
 /* Basic configuration for ACPI */
 #ifdef	CONFIG_ACPI
 pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);

drivers/perf/arm_pmu_acpi.c +35 -0

index 90815ad762ebc..8baeeb369118e 100644
@@ -139,6 +139,40 @@ static inline void arm_spe_acpi_register_device(void)
 }
 #endif /* CONFIG_ARM_SPE_PMU */
 
+#if IS_ENABLED(CONFIG_CORESIGHT_TRBE)
+static struct resource trbe_resources[] = {
+	{
+		/* irq */
+		.flags          = IORESOURCE_IRQ,
+	}
+};
+
+static struct platform_device trbe_dev = {
+	.name = ARMV8_TRBE_PDEV_NAME,
+	.id = -1,
+	.resource = trbe_resources,
+	.num_resources = ARRAY_SIZE(trbe_resources)
+};
+
+static u16 arm_trbe_parse_gsi(struct acpi_madt_generic_interrupt *gicc)
+{
+	return gicc->trbe_interrupt;
+}
+
+static void arm_trbe_acpi_register_device(void)
+{
+	int ret = arm_acpi_register_pmu_device(&trbe_dev, ACPI_MADT_GICC_TRBE,
+					       arm_trbe_parse_gsi);
+	if (ret)
+		pr_warn("ACPI: TRBE: Unable to register device\n");
+}
+#else
+static inline void arm_trbe_acpi_register_device(void)
+{
+
+}
+#endif /* CONFIG_CORESIGHT_TRBE */
+
 static int arm_pmu_acpi_parse_irqs(void)
 {
 	int irq, cpu, irq_cpu, err;

@@ -374,6 +408,7 @@ static int arm_pmu_acpi_init(void)
 		return 0;
 
 	arm_spe_acpi_register_device();
+	arm_trbe_acpi_register_device();
 
 	return 0;
 }

include/linux/perf/arm_pmu.h +1 -0

index a0801f68762bf..143fbc10ecfe0 100644
@@ -187,5 +187,6 @@ void armpmu_free_irq(int irq, int cpu);
 #endif /* CONFIG_ARM_PMU */
 
 #define ARMV8_SPE_PDEV_NAME "arm,spe-v1"
+#define ARMV8_TRBE_PDEV_NAME "arm,trbe"
 
 #endif /* __ARM_PMU_H__ */

Greg Kroah-Hartman

author maintainer

2023-10-16 16:52 UTC #8 lore raw

Re: [PATCH 6.5 006/191] arm_pmu: acpi: Add a representative platform device for TRBE

Quoted 66 lines · Thorsten Leemhuis

Quoted 25 lines · Greg Kroah-Hartman
6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
[ Upstream commit 1aa3d0274a4aac338ee45a3dfc3b17c944bcc2bc ]
ACPI TRBE does not have a HID for identification which could create and add a platform device into the platform bus. Also without a platform device, it cannot be probed and bound to a platform driver.
This creates a dummy platform device for TRBE after ascertaining that ACPI provides required interrupts uniformly across all cpus on the system. This device gets created inside drivers/perf/arm_pmu_acpi.c to accommodate TRBE being built as a module.
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Mark Rutland <[email protected]>
Cc [email protected]
Cc [email protected]
Signed-off-by Anshuman Khandual <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Will Deacon <[email protected]>
Quoted 2 lines
Stable-dep-of: 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer")
Signed-off-by Sasha Levin <[email protected]>
Got a compiler error when using Fedora's stable kernel config and compiling 6.5.8-rc1 for ARM64; not totally sure, but from the error msg I suspect it's caused by the change quoted above.
"""
+ /usr/bin/make -s 'HOSTCFLAGS=-O2 -fexceptions -g
(quoted diff) +0 -9
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-mbranch-protection=standard -fasynchronous-unwind-tables
-fstack-clash-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
-specs=/usr/lib/rpm/redhat/redhat-package-notes' ARCH=arm64 'KCFLAGS= '
WITH_GCOV=0 -j4 vmlinuz.efi
drivers/perf/arm_pmu_acpi.c: In function 'arm_trbe_acpi_register_device':
drivers/perf/arm_pmu_acpi.c:164:19: error: implicit declaration of function 'arm_acpi_register_pmu_device'; did you mean 'arm_spe_acpi_register_device'? [-Werror=implicit-function-declaration]
164 | int ret = arm_acpi_register_pmu_device(&trbe_dev,
ACPI_MADT_GICC_TRBE,
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                   arm_spe_acpi_register_device
cc1: some warnings being treated as errors
make[4]: *** [scripts/Makefile.build:243: drivers/perf/arm_pmu_acpi.o]
Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:480: drivers/perf] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [scripts/Makefile.build:480: drivers] Error 2
make[1]: *** [/builddir/build/BUILD/kernel-6.5.8-rc1/linux-6.5.8-0.rc1.150.vanilla.fc37.aarch64/Makefile:2036:
.] Error 2
make: *** [Makefile:236: __sub-make] Error 2
"""

Quoted 2 lines

Full build log:
https://copr-be.cloud.fedoraproject.org/results/@kernel-vanilla/stable-rc/fedora-37-aarch64/06529454-stablerc-stablerc-releases/builder-live.log.gz

Thanks, I'll drop the offending commit and push out a -rc2.

greg k-h

Thorsten Leemhuis

2023-10-17 06:06 UTC #9 lore raw

Re: [PATCH 6.5 006/191] arm_pmu: acpi: Add a representative platform device for TRBE

Quoted 13 lines · Greg Kroah-Hartman

Quoted 12 lines · Thorsten Leemhuis
Quoted 11 lines · Greg Kroah-Hartman
6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
[ Upstream commit 1aa3d0274a4aac338ee45a3dfc3b17c944bcc2bc ]
ACPI TRBE does not have a HID for identification which could create and add a platform device into the platform bus. Also without a platform device, it cannot be probed and bound to a platform driver.

Quoted 6 lines

Quoted 4 lines
[...]
Got a compiler error when using Fedora's stable kernel config and compiling 6.5.8-rc1 for ARM64; not totally sure, but from the error msg I suspect it's caused by the change quoted above.
[...]
Thanks, I'll drop the offending commit and push out a -rc2.

Thx, that made things work! Ciao, Thorsten

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #10 lore raw

PATCH 7/191 cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oza Pawandeep <[email protected]>

[ Upstream commit 4785aa8028536c2be656d22c74ec1995b97056f3 ]

Arm® Functional Fixed Hardware Specification defines LPI states, which provide an architectural context loss flags field that can be used to describe the context that might be lost when an LPI state is entered.

- Core context Lost
- General purpose registers.
- Floating point and SIMD registers.
- System registers, include the System register based
- generic timer for the core.
- Debug register in the core power domain.
- PMU registers in the core power domain.
- Trace register in the core power domain.
- Trace context loss
- GICR
- GICD

Qualcomm's custom CPUs preserves the architectural state, including keeping the power domain for local timers active. when core is power gated, the local timers are sufficient to wake the core up without needing broadcast timer.

The patch fixes the evaluation of cpuidle arch_flags, and moves only to broadcast timer if core context lost is defined in ACPI LPI.

Fixes a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states")

Reviewed-by Sudeep Holla <[email protected]>

Acked-by Rafael J. Wysocki <[email protected]>

Signed-off-by Oza Pawandeep <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/include/asm/acpi.h | 19 +++++++++++++++++++
 drivers/acpi/processor_idle.c |  3 +--
 include/linux/acpi.h          |  9 +++++++++
 3 files changed, 29 insertions(+), 2 deletions(-)

arch/arm64/include/asm/acpi.h +19 -0

index 4d537d56eb847..6792a1f83f2ad 100644
@@ -9,6 +9,7 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
+#include <linux/cpuidle.h>
 #include <linux/efi.h>
 #include <linux/memblock.h>
 #include <linux/psci.h>

@@ -44,6 +45,24 @@
 
 #define ACPI_MADT_GICC_TRBE  (offsetof(struct acpi_madt_generic_interrupt, \
 	trbe_interrupt) + sizeof(u16))
+/*
+ * Arm® Functional Fixed Hardware Specification Version 1.2.
+ * Table 2: Arm Architecture context loss flags
+ */
+#define CPUIDLE_CORE_CTXT		BIT(0) /* Core context Lost */
+
+static inline unsigned int arch_get_idle_state_flags(u32 arch_flags)
+{
+	if (arch_flags & CPUIDLE_CORE_CTXT)
+		return CPUIDLE_FLAG_TIMER_STOP;
+
+	return 0;
+}
+#define arch_get_idle_state_flags arch_get_idle_state_flags
+
+#define CPUIDLE_TRACE_CTXT		BIT(1) /* Trace context loss */
+#define CPUIDLE_GICR_CTXT		BIT(2) /* GICR */
+#define CPUIDLE_GICD_CTXT		BIT(3) /* GICD */
 
 /* Basic configuration for ACPI */
 #ifdef	CONFIG_ACPI

drivers/acpi/processor_idle.c +1 -2

index dc615ef6550a1..3a34a8c425fe4 100644
@@ -1217,8 +1217,7 @@ static int acpi_processor_setup_lpi_states(struct acpi_processor *pr)
 		strscpy(state->desc, lpi->desc, CPUIDLE_DESC_LEN);
 		state->exit_latency = lpi->wake_latency;
 		state->target_residency = lpi->min_residency;
-		if (lpi->arch_flags)
-			state->flags |= CPUIDLE_FLAG_TIMER_STOP;
+		state->flags |= arch_get_idle_state_flags(lpi->arch_flags);
 		if (i != 0 && lpi->entry_method == ACPI_CSTATE_FFH)
 			state->flags |= CPUIDLE_FLAG_RCU_IDLE;
 		state->enter = acpi_idle_lpi_enter;

include/linux/acpi.h +9 -0

index 641dc48439873..42c22a6ff48d0 100644
@@ -1476,6 +1476,15 @@ static inline int lpit_read_residency_count_address(u64 *address)
 }
 #endif
 
+#ifdef CONFIG_ACPI_PROCESSOR_IDLE
+#ifndef arch_get_idle_state_flags
+static inline unsigned int arch_get_idle_state_flags(u32 arch_flags)
+{
+	return 0;
+}
+#endif
+#endif /* CONFIG_ACPI_PROCESSOR_IDLE */
+
 #ifdef CONFIG_ACPI_PPTT
 int acpi_pptt_cpu_is_thread(unsigned int cpu);
 int find_acpi_cpu_topology(unsigned int cpu, int level);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #11 lore raw

PATCH 8/191 drm/amdgpu: Fix a memory leak

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Luben Tuikov <[email protected]>

[ Upstream commit 5d061675b7538e25d060d13310880c01160207c4 ]

Fix a memory leak in amdgpu_fru_get_product_info().

Cc Alex Deucher <[email protected]>

Reported-by Yang Wang <[email protected]>

Fixes 0dbf2c562625 ("drm/amdgpu: Interpret IPMI data for product information (v2)")

Signed-off-by Luben Tuikov <[email protected]>

Reviewed-by Alex Deucher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 1 +
 1 file changed, 1 insertion(+)

drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c +1 -0

index 4620c4712ce32..1005edeea39e5 100644
@@ -169,6 +169,7 @@ int amdgpu_fru_get_product_info(struct amdgpu_device *adev)
 		csum += pia[size - 1];
 	if (csum) {
 		DRM_ERROR("Bad Product Info Area checksum: 0x%02x", csum);
+		kfree(pia);
 		return -EIO;
 	}

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #12 lore raw

PATCH 9/191 platform/x86: hp-wmi:: Mark driver struct with __refdata to prevent section mismatch warning

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Uwe Kleine-König <[email protected]>

[ Upstream commit 5b44abbc39ca15df80d0da4756078c98c831090f ]

As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent a section mismatch warning:

	WARNING: modpost: drivers/platform/x86/hp/hp-wmi: section mismatch in reference: hp_wmi_driver+0x8 (section: .data) -> hp_wmi_bios_remove (section: .exit.text)

Fixes c165b80cfecc ("hp-wmi: fix handling of platform device")

Signed-off-by Uwe Kleine-König <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by Hans de Goede <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/platform/x86/hp/hp-wmi.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/platform/x86/hp/hp-wmi.c +7 -1

index e76e5458db350..8ebb7be52ee72 100644
@@ -1548,7 +1548,13 @@ static const struct dev_pm_ops hp_wmi_pm_ops = {
 	.restore  = hp_wmi_resume_handler,
 };
 
-static struct platform_driver hp_wmi_driver = {
+/*
+ * hp_wmi_bios_remove() lives in .exit.text. For drivers registered via
+ * module_platform_driver_probe() this is ok because they cannot get unbound at
+ * runtime. So mark the driver struct with __refdata to prevent modpost
+ * triggering a section mismatch warning.
+ */
+static struct platform_driver hp_wmi_driver __refdata = {
 	.driver = {
 		.name = "hp-wmi",
 		.pm = &hp_wmi_pm_ops,

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 09:06 UTC #13 lore raw

PATCH 10/191 media: dt-bindings: imx7-csi: Make power-domains not required for imx8mq

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Fabio Estevam <[email protected]>

[ Upstream commit d7614a2733f5e354c075be178b068a241d5d8b11 ]

On i.MX8MQ the MIPI CSI block does have an associated power-domain, but the CSI bridge does not.

Remove the power-domains requirement from the i.MX8MQ CSI bridge to fix the following schema warning:

imx8mq-librem5-r4.dtb: csi@30a90000: 'power-domains' is a required property from schema $id: http://devicetree.org/schemas/media/nxp,imx7-csi.yaml#

Fixes de655386845a ("media: dt-bindings: media: imx7-csi: Document i.MX8M power-domains property")

Signed-off-by Fabio Estevam <[email protected]>

Acked-by Conor Dooley <[email protected]>

Reviewed-by Marek Vasut <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Rob Herring <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml | 1 -
 1 file changed, 1 deletion(-)

Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml +0 -1

index 358019e85d907..326284e151f66 100644
@@ -59,7 +59,6 @@ allOf:
         compatible:
           contains:
             enum:
-              - fsl,imx8mq-csi
               - fsl,imx8mm-csi
     then:
       required:

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 09:06 UTC #14 lore raw

PATCH 11/191 drm/amd/display: implement pipe type definition and adding accessors

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wenjing Liu <[email protected]>

commit 53f3288079460ec7c86a39871af5c8b2a5d48685 upstream.

[why]
There is a lack of encapsulation of pipe connection representation in pipe context. This has caused many challenging bugs and coding errors with repeated logic to identify the same pipe type.

[how]
Formally define pipe types and provide getters to identify a pipe type and find a pipe based on specific requirements. Update existing logic in non dcn specific files and dcn32 and future versions to use the new accessors.

Reviewed-by Jun Lei <[email protected]>

Acked-by Stylon Wang <[email protected]>

Signed-off-by Wenjing Liu <[email protected]>

Tested-by Daniel Wheeler <[email protected]>

[ Reduced to only introduce resource_is_pipe_type() to make candidate for stable 6.5.y. ]

Signed-off-by Mario Limonciello <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c |   35 +++++++
 drivers/gpu/drm/amd/display/dc/inc/resource.h     |  106 ++++++++++++++++++++++
 2 files changed, 141 insertions(+)

drivers/gpu/drm/amd/display/dc/core/dc_resource.c +35 -0

@@ -1348,6 +1348,41 @@ struct pipe_ctx *find_idle_secondary_pip
 	return secondary_pipe;
 }
 
+bool resource_is_pipe_type(const struct pipe_ctx *pipe_ctx, enum pipe_type type)
+{
+#ifdef DBG
+	if (pipe_ctx->stream == NULL) {
+		/* a free pipe with dangling states */
+		ASSERT(!pipe_ctx->plane_state);
+		ASSERT(!pipe_ctx->prev_odm_pipe);
+		ASSERT(!pipe_ctx->next_odm_pipe);
+		ASSERT(!pipe_ctx->top_pipe);
+		ASSERT(!pipe_ctx->bottom_pipe);
+	} else if (pipe_ctx->top_pipe) {
+		/* a secondary DPP pipe must be signed to a plane */
+		ASSERT(pipe_ctx->plane_state)
+	}
+	/* Add more checks here to prevent corrupted pipe ctx. It is very hard
+	* to debug this issue afterwards because we can't pinpoint the code
+	* location causing inconsistent pipe context states.
+	*/
+#endif
+	switch (type) {
+	case OTG_MASTER:
+		return !pipe_ctx->prev_odm_pipe &&
+				!pipe_ctx->top_pipe &&
+				pipe_ctx->stream;
+	case OPP_HEAD:
+		return !pipe_ctx->top_pipe && pipe_ctx->stream;
+	case DPP_PIPE:
+		return pipe_ctx->plane_state && pipe_ctx->stream;
+	case FREE_PIPE:
+		return !pipe_ctx->plane_state && !pipe_ctx->stream;
+	default:
+		return false;
+	}
+}
+
 struct pipe_ctx *resource_get_head_pipe_for_stream(
 		struct resource_context *res_ctx,
 		struct dc_stream_state *stream)

drivers/gpu/drm/amd/display/dc/inc/resource.h +106 -0

112 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2023-10-16 09:06 UTC #15 lore raw

PATCH 12/191 drm/amd/display: apply edge-case DISPCLK WDIVIDER changes to master OTG pipes only

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Samson Tam <[email protected]>

commit b206011bf05069797df1f4c5ce639398728978e2 upstream.

[Why]
The edge-case DISPCLK WDIVIDER changes call stream_enc functions. But with MPC pipes, downstream pipes have null stream_enc and will
cause crash.

[How]
Only call stream_enc functions for pipes that are OTG master.

Reviewed-by Alvin Lee <[email protected]>

Cc Mario Limonciello <[email protected]>

Cc Alex Deucher <[email protected]>

Acked-by Aurabindo Pillai <[email protected]>

Signed-off-by Samson Tam <[email protected]>

Tested-by Daniel Wheeler <[email protected]>

Signed-off-by Mario Limonciello <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c |    4 ++--
 drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c +2 -2

@@ -157,7 +157,7 @@ void dcn20_update_clocks_update_dentist(
 			int32_t N;
 			int32_t j;
 
-			if (!pipe_ctx->stream)
+			if (!resource_is_pipe_type(pipe_ctx, OTG_MASTER))
 				continue;
 			/* Virtual encoders don't have this function */
 			if (!stream_enc->funcs->get_fifo_cal_average_level)

@@ -188,7 +188,7 @@ void dcn20_update_clocks_update_dentist(
 			int32_t N;
 			int32_t j;
 
-			if (!pipe_ctx->stream)
+			if (!resource_is_pipe_type(pipe_ctx, OTG_MASTER))
 				continue;
 			/* Virtual encoders don't have this function */
 			if (!stream_enc->funcs->get_fifo_cal_average_level)

drivers/gpu/drm/amd/display/dc/clk_mgr/dcn32/dcn32_clk_mgr.c +2 -2

@@ -355,7 +355,7 @@ static void dcn32_update_clocks_update_d
 			int32_t N;
 			int32_t j;
 
-			if (!pipe_ctx->stream)
+			if (!resource_is_pipe_type(pipe_ctx, OTG_MASTER))
 				continue;
 			/* Virtual encoders don't have this function */
 			if (!stream_enc->funcs->get_fifo_cal_average_level)

@@ -401,7 +401,7 @@ static void dcn32_update_clocks_update_d
 			int32_t N;
 			int32_t j;
 
-			if (!pipe_ctx->stream)
+			if (!resource_is_pipe_type(pipe_ctx, OTG_MASTER))
 				continue;
 			/* Virtual encoders don't have this function */
 			if (!stream_enc->funcs->get_fifo_cal_average_level)

Greg Kroah-Hartman

author maintainer

2023-10-16 09:06 UTC #16 lore raw

PATCH 13/191 scsi: Do not rescan devices with a suspended queue

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Damien Le Moal <[email protected]>

commit 626b13f015e080e434b1dee9a0c116ddbf4fb695 upstream.

Commit ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices") modified scsi_rescan_device() to avoid attempting rescanning a suspended device. However, the modification added a check to verify that a SCSI device is in the running state without checking if the device request queue (in the case of block device) is also running, thus allowing the exectuion of internal requests. Without checking the device request queue, commit ff48b37802e5 fix is incomplete and deadlocks on resume can still happen. Use blk_queue_pm_only() to check if the device request queue allows executing commands in addition to checking the SCSI device state.

Reported-by Petr Tesarik <[email protected]>

Fixes ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices")

Tested-by Petr Tesarik <[email protected]>

Reviewed-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/scsi_scan.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

drivers/scsi/scsi_scan.c +6 -5

@@ -1627,12 +1627,13 @@ int scsi_rescan_device(struct scsi_devic
 	device_lock(dev);
 
 	/*
-	 * Bail out if the device is not running. Otherwise, the rescan may
-	 * block waiting for commands to be executed, with us holding the
-	 * device lock. This can result in a potential deadlock in the power
-	 * management core code when system resume is on-going.
+	 * Bail out if the device or its queue are not running. Otherwise,
+	 * the rescan may block waiting for commands to be executed, with us
+	 * holding the device lock. This can result in a potential deadlock
+	 * in the power management core code when system resume is on-going.
 	 */
-	if (sdev->sdev_state != SDEV_RUNNING) {
+	if (sdev->sdev_state != SDEV_RUNNING ||
+	    blk_queue_pm_only(sdev->request_queue)) {
 		ret = -EWOULDBLOCK;
 		goto unlock;
 	}

Greg Kroah-Hartman

author maintainer

2023-10-16 09:07 UTC #17 lore raw

PATCH 14/191 ata: pata_parport: fix pata_parport_devchk

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ondrej Zary <[email protected]>

commit b555aa66760f17df4a0a5e4b440816e390311a38 upstream.

There's a 'x' missing in 0x55 in pata_parport_devchk(), causing the detection to always fail. Fix it.

Fixes 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)")

Signed-off-by Ondrej Zary <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/ata/pata_parport/pata_parport.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/ata/pata_parport/pata_parport.c +1 -1

@@ -64,7 +64,7 @@ static bool pata_parport_devchk(struct a
 	pi->proto->write_regr(pi, 0, ATA_REG_NSECT, 0xaa);
 	pi->proto->write_regr(pi, 0, ATA_REG_LBAL, 0x55);
 
-	pi->proto->write_regr(pi, 0, ATA_REG_NSECT, 055);
+	pi->proto->write_regr(pi, 0, ATA_REG_NSECT, 0x55);
 	pi->proto->write_regr(pi, 0, ATA_REG_LBAL, 0xaa);
 
 	nsect = pi->proto->read_regr(pi, 0, ATA_REG_NSECT);

Greg Kroah-Hartman

author maintainer

2023-10-16 09:07 UTC #18 lore raw

PATCH 15/191 ata: pata_parport: implement set_devctl

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ondrej Zary <[email protected]>

commit d2302427c12277929c9f390adeda19fbf403c0bb upstream.

Add missing ops->sff_set_devctl implementation.

Fixes 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)")

Signed-off-by Ondrej Zary <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/ata/pata_parport/pata_parport.c | 8 ++++++++
 1 file changed, 8 insertions(+)

drivers/ata/pata_parport/pata_parport.c +8 -0

index 258d189f42e5..cf87bbb52f1f 100644
@@ -51,6 +51,13 @@ static void pata_parport_dev_select(struct ata_port *ap, unsigned int device)
 	ata_sff_pause(ap);
 }
 
+static void pata_parport_set_devctl(struct ata_port *ap, u8 ctl)
+{
+	struct pi_adapter *pi = ap->host->private_data;
+
+	pi->proto->write_regr(pi, 1, 6, ctl);
+}
+
 static bool pata_parport_devchk(struct ata_port *ap, unsigned int device)
 {
 	struct pi_adapter *pi = ap->host->private_data;

@@ -252,6 +259,7 @@ static struct ata_port_operations pata_parport_port_ops = {
 	.hardreset		= NULL,
 
 	.sff_dev_select		= pata_parport_dev_select,
+	.sff_set_devctl		= pata_parport_set_devctl,
 	.sff_check_status	= pata_parport_check_status,
 	.sff_check_altstatus	= pata_parport_check_altstatus,
 	.sff_tf_load		= pata_parport_tf_load,

Signature · 1 line

2.42.0

Greg Kroah-Hartman

author maintainer

2023-10-16 09:07 UTC #19 lore raw

PATCH 16/191 HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect

Link https://bugzilla.redhat.com/show_bug.cgi?id=2227221

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit dac501397b9d81e4782232c39f94f4307b137452 upstream.

hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself.

hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue.

This opens the following races (note the below code is simplified):

1. Retrieving + printing the protocol (harmless race):

	if (!hidpp->protocol_major) {
		hidpp_root_get_protocol_version()
		hidpp->protocol_major = response.rap.params[0];
	}

We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968:

[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.

Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them:

2. Updating the name to the HIDPP name (harmless race):

	if (hidpp->name == hdev->name) {
		...
		hidpp->name = new_name;
	}

3. Initializing the power_supply class for the battery (problematic!):

hidpp_initialize_battery()

{
        if (hidpp->battery.ps)
                return 0;

	probe_battery(); /* Blocks, threads take turns executing this */

	hidpp->battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp->battery.ps =
		devm_power_supply_register(&hidpp->hid_dev->dev,
					   &hidpp->battery.desc, cfg);
}

4. Creating delayed input_device (potentially problematic):

	if (hidpp->delayed_input)
		return;

	hidpp->delayed_input = hidpp_allocate_input(hdev);

The really big problem here is 3. Hitting the race leads to the following sequence:

	hidpp->battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp->battery.ps =
		devm_power_supply_register(&hidpp->hid_dev->dev,
					   &hidpp->battery.desc, cfg);

	...

	hidpp->battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp->battery.ps =
		devm_power_supply_register(&hidpp->hid_dev->dev,
					   &hidpp->battery.desc, cfg);

So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem.

Notice how:

1. This is all devm-maganaged
2. The hidpp->battery.desc struct is shared between the 2 power supplies
3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup()

This causes a use after free scenario on USB disconnect of the receiver:
1. The last registered power supply class device gets unregistered
2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory
3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data
4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one:

Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
...
Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
...
Sep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0
Sep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0
Sep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680
Sep 22 20:01:35 eric kernel:  power_supply_unregister+0x8e/0xa0
Sep 22 20:01:35 eric kernel:  release_nodes+0x3d/0xb0
Sep 22 20:01:35 eric kernel:  devres_release_group+0xfc/0x130
Sep 22 20:01:35 eric kernel:  hid_device_remove+0x56/0xa0
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
Sep 22 20:01:35 eric kernel:  logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4]
Sep 22 20:01:35 eric kernel:  hid_device_remove+0x44/0xa0
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
Sep 22 20:01:35 eric kernel:  usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3]
Sep 22 20:01:35 eric kernel:  usb_unbind_interface+0x90/0x270
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? kobject_put+0xa0/0x1d0
Sep 22 20:01:35 eric kernel:  usb_disable_device+0xcd/0x1e0
Sep 22 20:01:35 eric kernel:  usb_disconnect+0xde/0x2c0
Sep 22 20:01:35 eric kernel:  usb_disconnect+0xc3/0x2c0
Sep 22 20:01:35 eric kernel:  hub_event+0xe80/0x1c10

There have been quite a few bug reports (see Link tags) about this crash.

Fix all the TOCTOU issues, including the really bad power-supply related system crash on USB disconnect, by making probe() use the workqueue for running hidpp_connect_event() too, so that it can never run more then once.

Link https://bugzilla.redhat.com/show_bug.cgi?id=2227968

Link https://bugzilla.redhat.com/show_bug.cgi?id=2242189

Link https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Benjamin Tissoires <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hid-logitech-hidpp.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/hid/hid-logitech-hidpp.c +2 -1

@@ -4515,7 +4515,8 @@ static int hidpp_probe(struct hid_device
 			goto hid_hw_init_fail;
 	}
 
-	hidpp_connect_event(hidpp);
+	schedule_work(&hidpp->work);
+	flush_work(&hidpp->work);
 
 	if (will_restart) {
 		/* Reset the HID node state */

Greg Kroah-Hartman

author maintainer

2023-10-16 09:07 UTC #20 lore raw

PATCH 17/191 quota: Fix slow quotaoff

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit 869b6ea1609f655a43251bf41757aa44e5350a8f upstream.

Eric has reported that commit dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide") heavily increases runtime of generic/270 xfstest for ext4 in nojournal mode. The reason for this is that ext4 in nojournal mode leaves dquots dirty until the last dqput() and thus the cleanup done in quota_release_workfn() has to write them all. Due to the way quota_release_workfn() is written this results in synchronize_srcu() call for each dirty dquot which makes the dquot cleanup when turning quotas off extremely slow.

To be able to avoid synchronize_srcu() for each dirty dquot we need to rework how we track dquots to be cleaned up. Instead of keeping the last dquot reference while it is on releasing_dquots list, we drop it right away and mark the dquot with new DQ_RELEASING_B bit instead. This way we can we can remove dquot from releasing_dquots list when new reference to it is acquired and thus there's no need to call synchronize_srcu() each time we drop dq_list_lock.

References: https://lore.kernel.org/all/ZRytn6CxFK2oECUt@debian-BULLSEYE-live-builder-AMD64

Reported-by Eric Whitney <[email protected]>

Fixes dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")

CC [email protected]

Signed-off-by Jan Kara <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/quota/dquot.c         |   66 +++++++++++++++++++++++++++--------------------
 include/linux/quota.h    |    4 ++
 include/linux/quotaops.h |    2 -
 3 files changed, 43 insertions(+), 29 deletions(-)

fs/quota/dquot.c +39 ~~-27~~

@@ -233,19 +233,18 @@ static void put_quota_format(struct quot
  * All dquots are placed to the end of inuse_list when first created, and this
  * list is used for invalidate operation, which must look at every dquot.
  *
- * When the last reference of a dquot will be dropped, the dquot will be
- * added to releasing_dquots. We'd then queue work item which would call
+ * When the last reference of a dquot is dropped, the dquot is added to
+ * releasing_dquots. We'll then queue work item which will call
  * synchronize_srcu() and after that perform the final cleanup of all the
- * dquots on the list. Both releasing_dquots and free_dquots use the
- * dq_free list_head in the dquot struct. When a dquot is removed from
- * releasing_dquots, a reference count is always subtracted, and if
- * dq_count == 0 at that point, the dquot will be added to the free_dquots.
+ * dquots on the list. Each cleaned up dquot is moved to free_dquots list.
+ * Both releasing_dquots and free_dquots use the dq_free list_head in the dquot
+ * struct.
  *
- * Unused dquots (dq_count == 0) are added to the free_dquots list when freed,
- * and this list is searched whenever we need an available dquot.  Dquots are
- * removed from the list as soon as they are used again, and
- * dqstats.free_dquots gives the number of dquots on the list. When
- * dquot is invalidated it's completely released from memory.
+ * Unused and cleaned up dquots are in the free_dquots list and this list is
+ * searched whenever we need an available dquot. Dquots are removed from the
+ * list as soon as they are used again and dqstats.free_dquots gives the number
+ * of dquots on the list. When dquot is invalidated it's completely released
+ * from memory.
  *
  * Dirty dquots are added to the dqi_dirty_list of quota_info when mark
  * dirtied, and this list is searched when writing dirty dquots back to

@@ -321,6 +320,7 @@ static inline void put_dquot_last(struct
 static inline void put_releasing_dquots(struct dquot *dquot)
 {
 	list_add_tail(&dquot->dq_free, &releasing_dquots);
+	set_bit(DQ_RELEASING_B, &dquot->dq_flags);
 }
 
 static inline void remove_free_dquot(struct dquot *dquot)

@@ -328,8 +328,10 @@ static inline void remove_free_dquot(str
 	if (list_empty(&dquot->dq_free))
 		return;
 	list_del_init(&dquot->dq_free);
-	if (!atomic_read(&dquot->dq_count))
+	if (!test_bit(DQ_RELEASING_B, &dquot->dq_flags))
 		dqstats_dec(DQST_FREE_DQUOTS);
+	else
+		clear_bit(DQ_RELEASING_B, &dquot->dq_flags);
 }
 
 static inline void put_inuse(struct dquot *dquot)

@@ -581,12 +583,6 @@ restart:
 			continue;
 		/* Wait for dquot users */
 		if (atomic_read(&dquot->dq_count)) {
-			/* dquot in releasing_dquots, flush and retry */
-			if (!list_empty(&dquot->dq_free)) {
-				spin_unlock(&dq_list_lock);
-				goto restart;
-			}
-
 			atomic_inc(&dquot->dq_count);
 			spin_unlock(&dq_list_lock);
 			/*

@@ -606,6 +602,15 @@ restart:
 			goto restart;
 		}
 		/*
+		 * The last user already dropped its reference but dquot didn't
+		 * get fully cleaned up yet. Restart the scan which flushes the
+		 * work cleaning up released dquots.
+		 */
+		if (test_bit(DQ_RELEASING_B, &dquot->dq_flags)) {
+			spin_unlock(&dq_list_lock);
+			goto restart;
+		}
+		/*
 		 * Quota now has no users and it has been written on last
 		 * dqput()
 		 */

@@ -696,6 +701,13 @@ int dquot_writeback_dquots(struct super_
 						 dq_dirty);
 
 			WARN_ON(!dquot_active(dquot));
+			/* If the dquot is releasing we should not touch it */
+			if (test_bit(DQ_RELEASING_B, &dquot->dq_flags)) {
+				spin_unlock(&dq_list_lock);
+				flush_delayed_work(&quota_release_work);
+				spin_lock(&dq_list_lock);
+				continue;
+			}
 
 			/* Now we have active dquot from which someone is
  			 * holding reference so we can safely just increase

@@ -809,18 +821,18 @@ static void quota_release_workfn(struct
 	/* Exchange the list head to avoid livelock. */
 	list_replace_init(&releasing_dquots, &rls_head);
 	spin_unlock(&dq_list_lock);
+	synchronize_srcu(&dquot_srcu);
 
 restart:
-	synchronize_srcu(&dquot_srcu);
 	spin_lock(&dq_list_lock);
 	while (!list_empty(&rls_head)) {
 		dquot = list_first_entry(&rls_head, struct dquot, dq_free);
-		/* Dquot got used again? */
-		if (atomic_read(&dquot->dq_count) > 1) {
-			remove_free_dquot(dquot);
-			atomic_dec(&dquot->dq_count);
-			continue;
-		}
+		WARN_ON_ONCE(atomic_read(&dquot->dq_count));
+		/*
+		 * Note that DQ_RELEASING_B protects us from racing with
+		 * invalidate_dquots() calls so we are safe to work with the
+		 * dquot even after we drop dq_list_lock.
+		 */
 		if (dquot_dirty(dquot)) {
 			spin_unlock(&dq_list_lock);
 			/* Commit dquot before releasing */

@@ -834,7 +846,6 @@ restart:
 		}
 		/* Dquot is inactive and clean, now move it to free list */
 		remove_free_dquot(dquot);
-		atomic_dec(&dquot->dq_count);
 		put_dquot_last(dquot);
 	}
 	spin_unlock(&dq_list_lock);

@@ -875,6 +886,7 @@ void dqput(struct dquot *dquot)
 	BUG_ON(!list_empty(&dquot->dq_free));
 #endif
 	put_releasing_dquots(dquot);
+	atomic_dec(&dquot->dq_count);
 	spin_unlock(&dq_list_lock);
 	queue_delayed_work(system_unbound_wq, &quota_release_work, 1);
 }

@@ -963,7 +975,7 @@ we_slept:
 		dqstats_inc(DQST_LOOKUPS);
 	}
 	/* Wait for dq_lock - after this we know that either dquot_release() is
-	 * already finished or it will be canceled due to dq_count > 1 test */
+	 * already finished or it will be canceled due to dq_count > 0 test */
 	wait_on_dquot(dquot);
 	/* Read the dquot / allocate space in quota file */
 	if (!dquot_active(dquot)) {

include/linux/quota.h +3 -1

@@ -285,7 +285,9 @@ static inline void dqstats_dec(unsigned
 #define DQ_FAKE_B	3	/* no limits only usage */
 #define DQ_READ_B	4	/* dquot was read into memory */
 #define DQ_ACTIVE_B	5	/* dquot is active (dquot_release not called) */
-#define DQ_LASTSET_B	6	/* Following 6 bits (see QIF_) are reserved\
+#define DQ_RELEASING_B	6	/* dquot is in releasing_dquots list waiting
+				 * to be cleaned up */
+#define DQ_LASTSET_B	7	/* Following 6 bits (see QIF_) are reserved\
 				 * for the mask of entries set via SETQUOTA\
 				 * quotactl. They are set under dq_data_lock\
 				 * and the quota format handling dquot can\

include/linux/quotaops.h +1 -1

@@ -57,7 +57,7 @@ static inline bool dquot_is_busy(struct
 {
 	if (test_bit(DQ_MOD_B, &dquot->dq_flags))
 		return true;
-	if (atomic_read(&dquot->dq_count) > 1)
+	if (atomic_read(&dquot->dq_count) > 0)
 		return true;
 	return false;
 }

Greg Kroah-Hartman

author maintainer

2023-10-16 14:24 UTC #21 lore raw

PATCH 18/191 dm crypt: Fix reqsize in crypt_iv_eboiv_gen

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Herbert Xu <[email protected]>

commit 152d0bcdf1efcb54a4fa20f694e9c7bbb6d06cbf upstream.

A skcipher_request object is made up of struct skcipher_request followed by a variable-sized trailer. The allocation of the skcipher_request and IV in crypt_iv_eboiv_gen is missing the memory for struct skcipher_request. Fix it by adding it to reqsize.

Fixes e3023094dffb ("dm crypt: Avoid using MAX_CIPHER_BLOCKSIZE")

Cc <[email protected]> #6.5+

Reported-by Tatu Heikkilä <[email protected]>

Reviewed-by Mike Snitzer <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-crypt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/md/dm-crypt.c +2 -1

index f2662c21a6df..5315fd261c23 100644
@@ -753,7 +753,8 @@ static int crypt_iv_eboiv_gen(struct crypt_config *cc, u8 *iv,
 	int err;
 	u8 *buf;
 
-	reqsize = ALIGN(crypto_skcipher_reqsize(tfm), __alignof__(__le64));
+	reqsize = sizeof(*req) + crypto_skcipher_reqsize(tfm);
+	reqsize = ALIGN(reqsize, __alignof__(__le64));
 
 	req = kmalloc(reqsize + cc->iv_size, GFP_NOIO);
 	if (!req)

Signature · 1 line

2.42.0

Greg Kroah-Hartman

author maintainer

2023-10-16 14:24 UTC #22 lore raw

PATCH 19/191 ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sven Frotscher <[email protected]>

commit 1948fa64727685ac3f6584755212e2e738b6b051 upstream.

Like the Lenovo 82TL, 82V2, 82QF and 82UG, the 82YM (Yoga 7 14ARP8) requires an entry in the quirk list to enable the internal microphone. The latter two received similar fixes in commit 1263cc0f414d ("ASoC: amd: yc: Fix non-functional mic on Lenovo 82QF and 82UG").

Fixes c008323fe361 ("ASoC: amd: yc: Fix a non-functional mic on Lenovo 82SJ")

Signed-off-by Sven Frotscher <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/amd/yc/acp6x-mach.c |    7 +++++++
 1 file changed, 7 insertions(+)

sound/soc/amd/yc/acp6x-mach.c +7 -0

@@ -238,6 +238,13 @@ static const struct dmi_system_id yc_acp
 		.driver_data = &acp6x_card,
 		.matches = {
 			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "82YM"),
+		}
+	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
 			DMI_MATCH(DMI_PRODUCT_NAME, "82UG"),
 		}
 	},

Greg Kroah-Hartman

author maintainer

2023-10-16 14:24 UTC #23 lore raw

PATCH 20/191 ASoC: hdmi-codec: Fix broken channel map reporting

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matthias Reichl <[email protected]>

commit b84b53149476b22cc3b8677b771fb4cf06d1d455 upstream.

Commit 4e0871333661 ("ASoC: hdmi-codec: fix channel info for compressed formats") accidentally changed hcp->chmap_idx from ca_id, the CEA channel allocation ID, to idx, the index to the table of channel mappings ordered by preference.

This resulted in wrong channel maps being reported to userspace, eg for 5.1 "FL,FR,LFE,FC" was reported instead of the expected "FL,FR,LFE,FC,RL,RR":

~ # speaker-test -c 6 -t sine
...
0 - Front Left
3 - Front Center
1 - Front Right
2 - LFE
4 - Unknown
5 - Unknown

~ # amixer cget iface=PCM,name='Playback Channel Map' | grep ': values'
: values=3,4,8,7,0,0,0,0

Switch this back to ca_id in case of PCM audio so the correct channel map is reported again and set it to HDMI_CODEC_CHMAP_IDX_UNKNOWN in case of non-PCM audio so the PCM channel map control returns "Unknown" channels (value 0).

Fixes 4e0871333661 ("ASoC: hdmi-codec: fix channel info for compressed formats")

Signed-off-by Matthias Reichl <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/codecs/hdmi-codec.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

sound/soc/codecs/hdmi-codec.c +4 -1

@@ -531,7 +531,10 @@ static int hdmi_codec_fill_codec_params(
 	hp->sample_rate = sample_rate;
 	hp->channels = channels;
 
-	hcp->chmap_idx = idx;
+	if (pcm_audio)
+		hcp->chmap_idx = ca_id;
+	else
+		hcp->chmap_idx = HDMI_CODEC_CHMAP_IDX_UNKNOWN;
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2023-10-16 14:24 UTC #24 lore raw

PATCH 21/191 ata: libata-scsi: Disable scsi device manage_system_start_stop

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Damien Le Moal <[email protected]>

commit aa3998dbeb3abce63653b7f6d4542e7dcd022590 upstream.

The introduction of a device link to create a consumer/supplier relationship between the scsi device of an ATA device and the ATA port of that ATA device fixes the ordering of system suspend and resume operations. For suspend, the scsi device is suspended first and the ata port after it. This is fine as this allows the synchronize cache and START STOP UNIT commands issued by the scsi disk driver to be executed before the ata port is disabled.

For resume operations, the ata port is resumed first, followed by the scsi device. This allows having the request queue of the scsi device to be unfrozen after the ata port resume is scheduled in EH, thus avoiding to see new requests prematurely issued to the ATA device. Since libata sets manage_system_start_stop to 1, the scsi disk resume operation also results in issuing a START STOP UNIT command to the device being resumed so that the device exits standby power mode.

However, restoring the ATA device to the active power mode must be synchronized with libata EH processing of the port resume operation to avoid either 1) seeing the start stop unit command being received too early when the port is not yet resumed and ready to accept commands, or after the port resume process issues commands such as IDENTIFY to revalidate the device. In this last case, the risk is that the device revalidation fails with timeout errors as the drive is still spun down.

Commit 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume") disabled issuing the START STOP UNIT command to avoid issues with it. But this is incorrect as transitioning a device to the active power mode from the standby power mode set on suspend requires a media access command. The IDENTIFY, READ LOG and SET FEATURES commands executed in libata EH context triggered by the ata port resume operation may thus fail.

Fix these synchronization issues is by handling a device power mode transitions for system suspend and resume directly in libata EH context, without relying on the scsi disk driver management triggered with the manage_system_start_stop flag.

To do this, the following libata helper functions are introduced:

1) ata_dev_power_set_standby():

This function issues a STANDBY IMMEDIATE command to transitiom a device to the standby power mode. For HDDs, this spins down the disks. This function applies only to ATA and ZAC devices and does nothing otherwise. This function also does nothing for devices that have the ATA_FLAG_NO_POWEROFF_SPINDOWN or ATA_FLAG_NO_HIBERNATE_SPINDOWN flag set.

For suspend, call ata_dev_power_set_standby() in ata_eh_handle_port_suspend() before the port is disabled and frozen. ata_eh_unload() is also modified to transition all enabled devices to the standby power mode when the system is shutdown or devices removed.

2) ata_dev_power_set_active() and

This function applies to ATA or ZAC devices and issues a VERIFY command for 1 sector at LBA 0 to transition the device to the active power mode. For HDDs, since this function will complete only once the disk spin up. Its execution uses the same timeouts as for reset, to give the drive enough time to complete spinup without triggering a command timeout.

For resume, call ata_dev_power_set_active() in ata_eh_revalidate_and_attach() after the port has been enabled and before any other command is issued to the device.

With these changes, the manage_system_start_stop and no_start_on_resume scsi device flags do not need to be set in ata_scsi_dev_config(). The flag manage_runtime_start_stop is still set to allow the sd driver to spinup/spindown a disk through the sd runtime operations.

Fixes 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")

Reviewed-by Hannes Reinecke <[email protected]>

Tested-by Geert Uytterhoeven <[email protected]>

Reviewed-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/ata/libata-core.c |   90 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/ata/libata-eh.c   |   54 +++++++++++++++++++++++++++
 drivers/ata/libata-scsi.c |   16 +++-----
 drivers/ata/libata.h      |    2 +
 include/linux/libata.h    |    6 ++-
 5 files changed, 156 insertions(+), 12 deletions(-)

drivers/ata/libata-core.c +90 -0

@@ -1978,6 +1978,96 @@ retry:
 }
 
 /**
+ *	ata_dev_power_set_standby - Set a device power mode to standby
+ *	@dev: target device
+ *
+ *	Issue a STANDBY IMMEDIATE command to set a device power mode to standby.
+ *	For an HDD device, this spins down the disks.
+ *
+ *	LOCKING:
+ *	Kernel thread context (may sleep).
+ */
+void ata_dev_power_set_standby(struct ata_device *dev)
+{
+	unsigned long ap_flags = dev->link->ap->flags;
+	struct ata_taskfile tf;
+	unsigned int err_mask;
+
+	/* Issue STANDBY IMMEDIATE command only if supported by the device */
+	if (dev->class != ATA_DEV_ATA && dev->class != ATA_DEV_ZAC)
+		return;
+
+	/*
+	 * Some odd clown BIOSes issue spindown on power off (ACPI S4 or S5)
+	 * causing some drives to spin up and down again. For these, do nothing
+	 * if we are being called on shutdown.
+	 */
+	if ((ap_flags & ATA_FLAG_NO_POWEROFF_SPINDOWN) &&
+	    system_state == SYSTEM_POWER_OFF)
+		return;
+
+	if ((ap_flags & ATA_FLAG_NO_HIBERNATE_SPINDOWN) &&
+	    system_entering_hibernation())
+		return;
+
+	ata_tf_init(dev, &tf);
+	tf.flags |= ATA_TFLAG_DEVICE | ATA_TFLAG_ISADDR;
+	tf.protocol = ATA_PROT_NODATA;
+	tf.command = ATA_CMD_STANDBYNOW1;
+
+	ata_dev_notice(dev, "Entering standby power mode\n");
+
+	err_mask = ata_exec_internal(dev, &tf, NULL, DMA_NONE, NULL, 0, 0);
+	if (err_mask)
+		ata_dev_err(dev, "STANDBY IMMEDIATE failed (err_mask=0x%x)\n",
+			    err_mask);
+}
+
+/**
+ *	ata_dev_power_set_active -  Set a device power mode to active
+ *	@dev: target device
+ *
+ *	Issue a VERIFY command to enter to ensure that the device is in the
+ *	active power mode. For a spun-down HDD (standby or idle power mode),
+ *	the VERIFY command will complete after the disk spins up.
+ *
+ *	LOCKING:
+ *	Kernel thread context (may sleep).
+ */
+void ata_dev_power_set_active(struct ata_device *dev)
+{
+	struct ata_taskfile tf;
+	unsigned int err_mask;
+
+	/*
+	 * Issue READ VERIFY SECTORS command for 1 sector at lba=0 only
+	 * if supported by the device.
+	 */
+	if (dev->class != ATA_DEV_ATA && dev->class != ATA_DEV_ZAC)
+		return;
+
+	ata_tf_init(dev, &tf);
+	tf.flags |= ATA_TFLAG_DEVICE | ATA_TFLAG_ISADDR;
+	tf.protocol = ATA_PROT_NODATA;
+	tf.command = ATA_CMD_VERIFY;
+	tf.nsect = 1;
+	if (dev->flags & ATA_DFLAG_LBA) {
+		tf.flags |= ATA_TFLAG_LBA;
+		tf.device |= ATA_LBA;
+	} else {
+		/* CHS */
+		tf.lbal = 0x1; /* sect */
+	}
+
+	ata_dev_notice(dev, "Entering active power mode\n");
+
+	err_mask = ata_exec_internal(dev, &tf, NULL, DMA_NONE, NULL, 0, 0);
+	if (err_mask)
+		ata_dev_err(dev, "VERIFY failed (err_mask=0x%x)\n",
+			    err_mask);
+}
+
+/**
  *	ata_read_log_page - read a specific log page
  *	@dev: target device
  *	@log: log to read

drivers/ata/libata-eh.c +53 -1

114 lines not on this page · raw message

drivers/ata/libata-scsi.c +7 -9

@@ -1100,15 +1100,13 @@ int ata_scsi_dev_config(struct scsi_devi
 		}
 	} else {
 		sdev->sector_size = ata_id_logical_sector_size(dev->id);
+
 		/*
-		 * Stop the drive on suspend but do not issue START STOP UNIT
-		 * on resume as this is not necessary and may fail: the device
-		 * will be woken up by ata_port_pm_resume() with a port reset
-		 * and device revalidation.
+		 * Ask the sd driver to issue START STOP UNIT on runtime suspend
+		 * and resume only. For system level suspend/resume, devices
+		 * power state is handled directly by libata EH.
 		 */
-		sdev->manage_system_start_stop = true;
 		sdev->manage_runtime_start_stop = true;
-		sdev->no_start_on_resume = 1;
 	}
 
 	/*

@@ -1284,7 +1282,7 @@ static unsigned int ata_scsi_start_stop_
 	}
 
 	if (cdb[4] & 0x1) {
-		tf->nsect = 1;	/* 1 sector, lba=0 */
+		tf->nsect = 1;  /* 1 sector, lba=0 */
 
 		if (qc->dev->flags & ATA_DFLAG_LBA) {
 			tf->flags |= ATA_TFLAG_LBA;

@@ -1300,7 +1298,7 @@ static unsigned int ata_scsi_start_stop_
 			tf->lbah = 0x0; /* cyl high */
 		}
 
-		tf->command = ATA_CMD_VERIFY;	/* READ VERIFY */
+		tf->command = ATA_CMD_VERIFY;   /* READ VERIFY */
 	} else {
 		/* Some odd clown BIOSen issue spindown on power off (ACPI S4
 		 * or S5) causing some drives to spin up and down again.

@@ -1310,7 +1308,7 @@ static unsigned int ata_scsi_start_stop_
 			goto skip;
 
 		if ((qc->ap->flags & ATA_FLAG_NO_HIBERNATE_SPINDOWN) &&
-		     system_entering_hibernation())
+		    system_entering_hibernation())
 			goto skip;
 
 		/* Issue ATA STANDBY IMMEDIATE command */

drivers/ata/libata.h +2 -0

@@ -62,6 +62,8 @@ extern int ata_dev_reread_id(struct ata_
 extern int ata_dev_revalidate(struct ata_device *dev, unsigned int new_class,
 			      unsigned int readid_flags);
 extern int ata_dev_configure(struct ata_device *dev);
+extern void ata_dev_power_set_standby(struct ata_device *dev);
+extern void ata_dev_power_set_active(struct ata_device *dev);
 extern int sata_down_spd_limit(struct ata_link *link, u32 spd_limit);
 extern int ata_down_xfermask_limit(struct ata_device *dev, unsigned int sel);
 extern unsigned int ata_dev_set_feature(struct ata_device *dev,

include/linux/libata.h +4 -2

@@ -192,6 +192,7 @@ enum {
 	ATA_PFLAG_UNLOADING	= (1 << 9), /* driver is being unloaded */
 	ATA_PFLAG_UNLOADED	= (1 << 10), /* driver is unloaded */
 
+	ATA_PFLAG_RESUMING	= (1 << 16),  /* port is being resumed */
 	ATA_PFLAG_SUSPENDED	= (1 << 17), /* port is suspended (power) */
 	ATA_PFLAG_PM_PENDING	= (1 << 18), /* PM operation pending */
 	ATA_PFLAG_INIT_GTM_VALID = (1 << 19), /* initial gtm data valid */

@@ -318,9 +319,10 @@ enum {
 	ATA_EH_ENABLE_LINK	= (1 << 3),
 	ATA_EH_PARK		= (1 << 5), /* unload heads and stop I/O */
 	ATA_EH_GET_SUCCESS_SENSE = (1 << 6), /* Get sense data for successful cmd */
+	ATA_EH_SET_ACTIVE	= (1 << 7), /* Set a device to active power mode */
 
 	ATA_EH_PERDEV_MASK	= ATA_EH_REVALIDATE | ATA_EH_PARK |
-				  ATA_EH_GET_SUCCESS_SENSE,
+				  ATA_EH_GET_SUCCESS_SENSE | ATA_EH_SET_ACTIVE,
 	ATA_EH_ALL_ACTIONS	= ATA_EH_REVALIDATE | ATA_EH_RESET |
 				  ATA_EH_ENABLE_LINK,

@@ -358,7 +360,7 @@ enum {
 	/* This should match the actual table size of
 	 * ata_eh_cmd_timeout_table in libata-eh.c.
 	 */
-	ATA_EH_CMD_TIMEOUT_TABLE_SIZE = 7,
+	ATA_EH_CMD_TIMEOUT_TABLE_SIZE = 8,
 
 	/* Horkage types. May be set by libata or controller on drives
 	   (some horkage may be drive/controller pair dependent */

Greg Kroah-Hartman

author maintainer

2023-10-16 14:24 UTC #25 lore raw

PATCH 22/191 net: prevent address rewrite in kernel_bind()

Link https://lore.kernel.org/netdev/[email protected]/ open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jordan Rife <[email protected]>

commit c889a99a21bf124c3db08d09df919f0eccc5ea4c upstream.

Similar to the change in commit 0bdf399342c5("net: Avoid address overwrite in kernel_connect"), BPF hooks run on bind may rewrite the address passed to kernel_bind(). This change

1) Makes a copy of the bind address in kernel_bind() to insulate callers.
2) Replaces direct calls to sock->ops->bind() in net with kernel_bind()

Fixes 4fbac77d2d09 ("bpf: Hooks for sys_bind")

Reviewed-by Willem de Bruijn <[email protected]>

Signed-off-by Jordan Rife <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/netfilter/ipvs/ip_vs_sync.c |    4 ++--
 net/rds/tcp_connect.c           |    2 +-
 net/rds/tcp_listen.c            |    2 +-
 net/socket.c                    |    6 +++++-
 4 files changed, 9 insertions(+), 5 deletions(-)

net/netfilter/ipvs/ip_vs_sync.c +2 -2

@@ -1441,7 +1441,7 @@ static int bind_mcastif_addr(struct sock
 	sin.sin_addr.s_addr  = addr;
 	sin.sin_port         = 0;
 
-	return sock->ops->bind(sock, (struct sockaddr*)&sin, sizeof(sin));
+	return kernel_bind(sock, (struct sockaddr *)&sin, sizeof(sin));
 }
 
 static void get_mcast_sockaddr(union ipvs_sockaddr *sa, int *salen,

@@ -1548,7 +1548,7 @@ static int make_receive_sock(struct netn
 
 	get_mcast_sockaddr(&mcast_addr, &salen, &ipvs->bcfg, id);
 	sock->sk->sk_bound_dev_if = dev->ifindex;
-	result = sock->ops->bind(sock, (struct sockaddr *)&mcast_addr, salen);
+	result = kernel_bind(sock, (struct sockaddr *)&mcast_addr, salen);
 	if (result < 0) {
 		pr_err("Error binding to the multicast addr\n");
 		goto error;

net/rds/tcp_connect.c +1 -1

@@ -145,7 +145,7 @@ int rds_tcp_conn_path_connect(struct rds
 		addrlen = sizeof(sin);
 	}
 
-	ret = sock->ops->bind(sock, addr, addrlen);
+	ret = kernel_bind(sock, addr, addrlen);
 	if (ret) {
 		rdsdebug("bind failed with %d at address %pI6c\n",
 			 ret, &conn->c_laddr);

net/rds/tcp_listen.c +1 -1

@@ -306,7 +306,7 @@ struct socket *rds_tcp_listen_init(struc
 		addr_len = sizeof(*sin);
 	}
 
-	ret = sock->ops->bind(sock, (struct sockaddr *)&ss, addr_len);
+	ret = kernel_bind(sock, (struct sockaddr *)&ss, addr_len);
 	if (ret < 0) {
 		rdsdebug("could not bind %s listener socket: %d\n",
 			 isv6 ? "IPv6" : "IPv4", ret);

net/socket.c +5 -1

@@ -3467,7 +3467,11 @@ static long compat_sock_ioctl(struct fil
 
 int kernel_bind(struct socket *sock, struct sockaddr *addr, int addrlen)
 {
-	return sock->ops->bind(sock, addr, addrlen);
+	struct sockaddr_storage address;
+
+	memcpy(&address, addr, addrlen);
+
+	return sock->ops->bind(sock, (struct sockaddr *)&address, addrlen);
 }
 EXPORT_SYMBOL(kernel_bind);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:24 UTC #26 lore raw

PATCH 23/191 arm64: dts: qcom: sm8150: extend the size of the PDC resource

Link https://lore.kernel.org/r/20230905-topic-sm8x50-upstream-pdc-ver-v4-2-fc633c7df84b@linaro.org open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dmitry Baryshkov <[email protected]>

commit cf5716acbfc6190b3f97f4614affdf5991aed7b2 upstream.

Follow the example of other platforms and extend the PDC resource region to 0x30000, so that the PDC driver can read the PDC_VERSION register.

Fixes 397ad94668c1 ("arm64: dts: qcom: sm8150: Add pdc interrupt controller node")

Reviewed-by Konrad Dybcio <[email protected]>

Signed-off-by Dmitry Baryshkov <[email protected]>

Reviewed-by Neil Armstrong <[email protected]>

Signed-off-by Neil Armstrong <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/boot/dts/qcom/sm8150.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/boot/dts/qcom/sm8150.dtsi +1 -1

@@ -3958,7 +3958,7 @@
 
 		pdc: interrupt-controller@b220000 {
 			compatible = "qcom,sm8150-pdc", "qcom,pdc";
-			reg = <0 0x0b220000 0 0x400>;
+			reg = <0 0x0b220000 0 0x30000>;
 			qcom,pdc-ranges = <0 480 94>, <94 609 31>,
 					  <125 63 1>;
 			#interrupt-cells = <2>;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #27 lore raw

PATCH 24/191 dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Update description for #interrupt-cells property

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lad Prabhakar <[email protected]>

commit cfa1f9db6d6088118ef311c0927c66072665b47e upstream.

Update description for '#interrupt-cells' property to utilize the RZG2L_{NMI,IRQX} for the first cell defined in the include/dt-bindings/interrupt-controller/irqc-rzg2l.h file.

Signed-off-by Lad Prabhakar <[email protected]>

Fixes 96fed779d3d4cb3c ("dt-bindings: interrupt-controller: Add Renesas RZ/G2L Interrupt Controller")

Signed-off-by Marc Zyngier <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml +3 -2

@@ -31,8 +31,9 @@ properties:
       - const: renesas,rzg2l-irqc
 
   '#interrupt-cells':
-    description: The first cell should contain external interrupt number (IRQ0-7) and the
-                 second cell is used to specify the flag.
+    description: The first cell should contain a macro RZG2L_{NMI,IRQX} included in the
+                 include/dt-bindings/interrupt-controller/irqc-rzg2l.h and the second
+                 cell is used to specify the flag.
     const: 2
 
   '#address-cells':

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #28 lore raw

PATCH 25/191 irqchip: renesas-rzg2l: Fix logic to clear TINT interrupt source

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Biju Das <[email protected]>

commit 9b8df572ba3f4e544366196820a719a40774433e upstream.

The logic to clear the TINT interrupt source in rzg2l_irqc_irq_disable() is wrong as the mask is correct only for LSB on the TSSR register. This issue is found when testing with two TINT interrupt sources. So fix the logic for all TINTs by using the macro TSSEL_SHIFT() to multiply tssr_offset with 8.

Fixes 3fed09559cd8 ("irqchip: Add RZ/G2L IA55 Interrupt Controller driver")

Signed-off-by Biju Das <[email protected]>

Tested-by Claudiu Beznea <[email protected]>

Reviewed-by Claudiu Beznea <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/irqchip/irq-renesas-rzg2l.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/irqchip/irq-renesas-rzg2l.c +1 -1

@@ -118,7 +118,7 @@ static void rzg2l_irqc_irq_disable(struc
 
 		raw_spin_lock(&priv->lock);
 		reg = readl_relaxed(priv->base + TSSR(tssr_index));
-		reg &= ~(TSSEL_MASK << tssr_offset);
+		reg &= ~(TSSEL_MASK << TSSEL_SHIFT(tssr_offset));
 		writel_relaxed(reg, priv->base + TSSR(tssr_index));
 		raw_spin_unlock(&priv->lock);
 	}

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #29 lore raw

PATCH 26/191 KEYS: trusted: Remove redundant static calls usage

Link https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sumit Garg <[email protected]>

commit 01bbafc63b65689cb179ca537971286bc27f3b74 upstream.

Static calls invocations aren't well supported from module __init and __exit functions. Especially the static call from cleanup_trusted() led to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y.

However, the usage of static call invocations for trusted_key_init() and trusted_key_exit() don't add any value from either a performance or security perspective. Hence switch to use indirect function calls instead.

Note here that although it will fix the current crash report, ultimately the static call infrastructure should be fixed to either support its future usage from module __init and __exit functions or not.

Reported-and-tested-by Hyeonggon Yoo <[email protected]>

Fixes 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")

Signed-off-by Sumit Garg <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 security/keys/trusted-keys/trusted_core.c |   13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

security/keys/trusted-keys/trusted_core.c +5 -8

@@ -44,13 +44,12 @@ static const struct trusted_key_source t
 #endif
 };
 
-DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
 DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal);
 DEFINE_STATIC_CALL_NULL(trusted_key_unseal,
 			*trusted_key_sources[0].ops->unseal);
 DEFINE_STATIC_CALL_NULL(trusted_key_get_random,
 			*trusted_key_sources[0].ops->get_random);
-DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit);
+static void (*trusted_key_exit)(void);
 static unsigned char migratable;
 
 enum {

@@ -359,19 +358,16 @@ static int __init init_trusted(void)
 		if (!get_random)
 			get_random = kernel_get_random;
 
-		static_call_update(trusted_key_init,
-				   trusted_key_sources[i].ops->init);
 		static_call_update(trusted_key_seal,
 				   trusted_key_sources[i].ops->seal);
 		static_call_update(trusted_key_unseal,
 				   trusted_key_sources[i].ops->unseal);
 		static_call_update(trusted_key_get_random,
 				   get_random);
-		static_call_update(trusted_key_exit,
-				   trusted_key_sources[i].ops->exit);
+		trusted_key_exit = trusted_key_sources[i].ops->exit;
 		migratable = trusted_key_sources[i].ops->migratable;
 
-		ret = static_call(trusted_key_init)();
+		ret = trusted_key_sources[i].ops->init();
 		if (!ret)
 			break;
 	}

@@ -388,7 +384,8 @@ static int __init init_trusted(void)
 
 static void __exit cleanup_trusted(void)
 {
-	static_call_cond(trusted_key_exit)();
+	if (trusted_key_exit)
+		(*trusted_key_exit)();
 }
 
 late_initcall(init_trusted);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #30 lore raw

PATCH 27/191 ALSA: usb-audio: Fix microphone sound on Opencomm2 Headset

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: WhaleChang <[email protected]>

commit 6a83d6f3bb3c329a73e3483651fb77b78bac1878 upstream.

When a Opencomm2 Headset is connected to a Bluetooth USB dongle, the audio playback functions properly, but the microphone does not work.

In the dmesg logs, there are messages indicating that the init_pitch function fails when the capture process begins.

The microphone only functions when the ep pitch control is not set.

Toggling the pitch control off bypasses the init_piatch function and allows the microphone to work.

Signed-off-by WhaleChang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/usb/quirks.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

sound/usb/quirks.c +5 -1

@@ -1994,7 +1994,11 @@ void snd_usb_audioformat_attributes_quir
 		/* mic works only when ep packet size is set to wMaxPacketSize */
 		fp->attributes |= UAC_EP_CS_ATTR_FILL_MAX;
 		break;
-
+	case USB_ID(0x3511, 0x2b1e): /* Opencomm2 UC USB Bluetooth dongle */
+		/* mic works only when ep pitch control is not set */
+		if (stream == SNDRV_PCM_STREAM_CAPTURE)
+			fp->attributes &= ~UAC_EP_CS_ATTR_PITCH_CONTROL;
+		break;
 	}
 }

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #31 lore raw

PATCH 28/191 ALSA: usb-audio: Fix microphone sound on Nexigo webcam.

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christos Skevis <[email protected]>

commit 4a63e68a295187ae3c1cb3fa0c583c96a959714f upstream.

I own an external usb Webcam, model NexiGo N930AF, which had low mic volume and inconsistent sound quality. Video works as expected.

(snip)

[  +0.047857] usb 5-1: new high-speed USB device number 2 using xhci_hcd
[  +0.003406] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17
[  +0.000007] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam
[  +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD
[  +0.000004] usb 5-1: SerialNumber: 20201217011
[  +0.003900] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283)
[  +0.025726] usb 5-1: 3:1: cannot get usb sound sample rate freq at ep 0x86
[  +0.071482] usb 5-1: 3:2: cannot get usb sound sample rate freq at ep 0x86
[  +0.004679] usb 5-1: 3:3: cannot get usb sound sample rate freq at ep 0x86
[  +0.051607] usb 5-1: Warning! Unlikely big volume range (=4096), cval->res is probably wrong.
[  +0.000005] usb 5-1: [7] FU [Mic Capture Volume] ch = 1, val = 0/4096/1

Set up quirk cval->res to 16 for 256 levels,
Set GET_SAMPLE_RATE quirk flag to stop trying to get the sample rate. Confirmed that happened anyway later due to the backoff mechanism, after 3 failures

All audio stream on device interfaces share the same values, apart from wMaxPacketSize and tSamFreq :

(snip)
Interface Descriptor:

      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       3
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0
      iInterface              0

AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 8
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 44100
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x005c 1x 92 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
(snip)

Based on the usb data about manufacturer, SPCA2281B3 is the most likely controller IC Manufacturer does not provide link for datasheet nor detailed specs.
No way to confirm if the firmware supports any other way of getting the sample rate.

Testing patch provides consistent good sound recording quality and volume range.

(snip)

[  +0.045764] usb 5-1: new high-speed USB device number 2 using xhci_hcd
[  +0.106290] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17
[  +0.000006] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam
[  +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD
[  +0.000004] usb 5-1: SerialNumber: 20201217011
[  +0.043700] usb 5-1: set resolution quirk: cval->res = 16
[  +0.002585] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283)

Signed-off-by Christos Skevis <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/usb/mixer.c  |    7 +++++++
 sound/usb/quirks.c |    2 ++
 2 files changed, 9 insertions(+)

sound/usb/mixer.c +7 -0

@@ -1204,6 +1204,13 @@ static void volume_control_quirks(struct
 			cval->res = 16;
 		}
 		break;
+	case USB_ID(0x1bcf, 0x2283): /* NexiGo N930AF FHD Webcam */
+		if (!strcmp(kctl->id.name, "Mic Capture Volume")) {
+			usb_audio_info(chip,
+				"set resolution quirk: cval->res = 16\n");
+			cval->res = 16;
+		}
+		break;
 	}
 }

sound/usb/quirks.c +2 -0

@@ -2177,6 +2177,8 @@ static const struct usb_audio_quirk_flag
 		   QUIRK_FLAG_FIXED_RATE),
 	DEVICE_FLG(0x0ecb, 0x2069, /* JBL Quantum810 Wireless */
 		   QUIRK_FLAG_FIXED_RATE),
+	DEVICE_FLG(0x1bcf, 0x2283, /* NexiGo N930AF FHD Webcam */
+		   QUIRK_FLAG_GET_SAMPLE_RATE),
 
 	/* Vendor matches */
 	VENDOR_FLG(0x045e, /* MS Lifecam */

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #32 lore raw

PATCH 29/191 ALSA: hda: cs35l41: Cleanup and fix double free in firmware request

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefan Binding <[email protected]>

commit 5d542b850d40cb08a38ad4bb2a944dbf1b7b0683 upstream.

There is an unlikely but possible double free when loading firmware, and a missing free calls if a firmware is successfully requested but the coefficient file request fails, leading to the fallback firmware request occurring without clearing the previously loaded firmware.

Fixes cd40dad2ca91 ("ALSA: hda: cs35l41: Ensure firmware/tuning pairs are always loaded")

Reported-by kernel test robot <[email protected]>

Reported-by Dan Carpenter <[email protected]>

Closes https://lore.kernel.org/r/[email protected]/ open here

Signed-off-by Stefan Binding <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/cs35l41_hda.c |  115 ++++++++++++++++++++++++++++++--------------
 1 file changed, 79 insertions(+), 36 deletions(-)

sound/pci/hda/cs35l41_hda.c +79 ~~-36~~

@@ -178,10 +178,14 @@ static int cs35l41_request_firmware_file
 					    cs35l41->speaker_id, "wmfw");
 	if (!ret) {
 		/* try cirrus/part-dspN-fwtype-sub<-spkidN><-ampname>.bin */
-		return cs35l41_request_firmware_file(cs35l41, coeff_firmware, coeff_filename,
-						     CS35L41_FIRMWARE_ROOT,
-						     cs35l41->acpi_subsystem_id, cs35l41->amp_name,
-						     cs35l41->speaker_id, "bin");
+		ret = cs35l41_request_firmware_file(cs35l41, coeff_firmware, coeff_filename,
+						    CS35L41_FIRMWARE_ROOT,
+						    cs35l41->acpi_subsystem_id, cs35l41->amp_name,
+						    cs35l41->speaker_id, "bin");
+		if (ret)
+			goto coeff_err;
+
+		return 0;
 	}
 
 	/* try cirrus/part-dspN-fwtype-sub<-ampname>.wmfw */

@@ -190,10 +194,14 @@ static int cs35l41_request_firmware_file
 					    cs35l41->amp_name, -1, "wmfw");
 	if (!ret) {
 		/* try cirrus/part-dspN-fwtype-sub<-spkidN><-ampname>.bin */
-		return cs35l41_request_firmware_file(cs35l41, coeff_firmware, coeff_filename,
-						     CS35L41_FIRMWARE_ROOT,
-						     cs35l41->acpi_subsystem_id, cs35l41->amp_name,
-						     cs35l41->speaker_id, "bin");
+		ret = cs35l41_request_firmware_file(cs35l41, coeff_firmware, coeff_filename,
+						    CS35L41_FIRMWARE_ROOT,
+						    cs35l41->acpi_subsystem_id, cs35l41->amp_name,
+						    cs35l41->speaker_id, "bin");
+		if (ret)
+			goto coeff_err;
+
+		return 0;
 	}
 
 	/* try cirrus/part-dspN-fwtype-sub<-spkidN>.wmfw */

@@ -208,10 +216,14 @@ static int cs35l41_request_firmware_file
 						    cs35l41->amp_name, cs35l41->speaker_id, "bin");
 		if (ret)
 			/* try cirrus/part-dspN-fwtype-sub<-spkidN>.bin */
-			return cs35l41_request_firmware_file(cs35l41, coeff_firmware,
-							     coeff_filename, CS35L41_FIRMWARE_ROOT,
-							     cs35l41->acpi_subsystem_id, NULL,
-							     cs35l41->speaker_id, "bin");
+			ret = cs35l41_request_firmware_file(cs35l41, coeff_firmware,
+							    coeff_filename, CS35L41_FIRMWARE_ROOT,
+							    cs35l41->acpi_subsystem_id, NULL,
+							    cs35l41->speaker_id, "bin");
+		if (ret)
+			goto coeff_err;
+
+		return 0;
 	}
 
 	/* try cirrus/part-dspN-fwtype-sub.wmfw */

@@ -226,13 +238,51 @@ static int cs35l41_request_firmware_file
 						    cs35l41->speaker_id, "bin");
 		if (ret)
 			/* try cirrus/part-dspN-fwtype-sub<-spkidN>.bin */
-			return cs35l41_request_firmware_file(cs35l41, coeff_firmware,
-							     coeff_filename, CS35L41_FIRMWARE_ROOT,
-							     cs35l41->acpi_subsystem_id, NULL,
-							     cs35l41->speaker_id, "bin");
+			ret = cs35l41_request_firmware_file(cs35l41, coeff_firmware,
+							    coeff_filename, CS35L41_FIRMWARE_ROOT,
+							    cs35l41->acpi_subsystem_id, NULL,
+							    cs35l41->speaker_id, "bin");
+		if (ret)
+			goto coeff_err;
 	}
 
 	return ret;
+coeff_err:
+	release_firmware(*wmfw_firmware);
+	kfree(*wmfw_filename);
+	return ret;
+}
+
+static int cs35l41_fallback_firmware_file(struct cs35l41_hda *cs35l41,
+					  const struct firmware **wmfw_firmware,
+					  char **wmfw_filename,
+					  const struct firmware **coeff_firmware,
+					  char **coeff_filename)
+{
+	int ret;
+
+	/* Handle fallback */
+	dev_warn(cs35l41->dev, "Falling back to default firmware.\n");
+
+	/* fallback try cirrus/part-dspN-fwtype.wmfw */
+	ret = cs35l41_request_firmware_file(cs35l41, wmfw_firmware, wmfw_filename,
+					    CS35L41_FIRMWARE_ROOT, NULL, NULL, -1, "wmfw");
+	if (ret)
+		goto err;
+
+	/* fallback try cirrus/part-dspN-fwtype.bin */
+	ret = cs35l41_request_firmware_file(cs35l41, coeff_firmware, coeff_filename,
+					    CS35L41_FIRMWARE_ROOT, NULL, NULL, -1, "bin");
+	if (ret) {
+		release_firmware(*wmfw_firmware);
+		kfree(*wmfw_filename);
+		goto err;
+	}
+	return 0;
+
+err:
+	dev_warn(cs35l41->dev, "Unable to find firmware and tuning\n");
+	return ret;
 }
 
 static int cs35l41_request_firmware_files(struct cs35l41_hda *cs35l41,

@@ -247,7 +297,6 @@ static int cs35l41_request_firmware_file
 		ret = cs35l41_request_firmware_files_spkid(cs35l41, wmfw_firmware, wmfw_filename,
 							   coeff_firmware, coeff_filename);
 		goto out;
-
 	}
 
 	/* try cirrus/part-dspN-fwtype-sub<-ampname>.wmfw */

@@ -260,6 +309,9 @@ static int cs35l41_request_firmware_file
 						    CS35L41_FIRMWARE_ROOT,
 						    cs35l41->acpi_subsystem_id, cs35l41->amp_name,
 						    -1, "bin");
+		if (ret)
+			goto coeff_err;
+
 		goto out;
 	}

@@ -279,32 +331,23 @@ static int cs35l41_request_firmware_file
 							    CS35L41_FIRMWARE_ROOT,
 							    cs35l41->acpi_subsystem_id, NULL, -1,
 							    "bin");
+		if (ret)
+			goto coeff_err;
 	}
 
 out:
-	if (!ret)
-		return 0;
+	if (ret)
+		/* if all attempts at finding firmware fail, try fallback */
+		goto fallback;
 
-	/* Handle fallback */
-	dev_warn(cs35l41->dev, "Falling back to default firmware.\n");
+	return 0;
 
+coeff_err:
 	release_firmware(*wmfw_firmware);
 	kfree(*wmfw_filename);
-
-	/* fallback try cirrus/part-dspN-fwtype.wmfw */
-	ret = cs35l41_request_firmware_file(cs35l41, wmfw_firmware, wmfw_filename,
-					    CS35L41_FIRMWARE_ROOT, NULL, NULL, -1, "wmfw");
-	if (!ret)
-		/* fallback try cirrus/part-dspN-fwtype.bin */
-		ret = cs35l41_request_firmware_file(cs35l41, coeff_firmware, coeff_filename,
-						    CS35L41_FIRMWARE_ROOT, NULL, NULL, -1, "bin");
-
-	if (ret) {
-		release_firmware(*wmfw_firmware);
-		kfree(*wmfw_filename);
-		dev_warn(cs35l41->dev, "Unable to find firmware and tuning\n");
-	}
-	return ret;
+fallback:
+	return cs35l41_fallback_firmware_file(cs35l41, wmfw_firmware, wmfw_filename,
+					      coeff_firmware, coeff_filename);
 }
 
 #if IS_ENABLED(CONFIG_EFI)

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #33 lore raw

PATCH 30/191 ALSA: hda/realtek: Change model for Intel RVP board

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kailang Yang <[email protected]>

commit ccbd88be057a38531f835e8a04948ebf80cb0c5d upstream.

Intel RVP board (0x12cc) has Headset Mic issue for reboot. If system plugged headset when system reboot the headset Mic was gone.

Fixes 1a93f10c5b12 ("ALSA: hda/realtek: Add "Intel Reference board" and "NUC 13" SSID in the ALC256")

Signed-off-by Kailang Yang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/pci/hda/patch_realtek.c +2 -2

@@ -9720,7 +9720,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x10ec, 0x124c, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
 	SND_PCI_QUIRK(0x10ec, 0x1252, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
 	SND_PCI_QUIRK(0x10ec, 0x1254, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
-	SND_PCI_QUIRK(0x10ec, 0x12cc, "Intel Reference board", ALC225_FIXUP_HEADSET_JACK),
+	SND_PCI_QUIRK(0x10ec, 0x12cc, "Intel Reference board", ALC295_FIXUP_CHROME_BOOK),
 	SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6", ALC269_FIXUP_HEADSET_MODE),
 	SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", ALC269_FIXUP_INV_DMIC),
 	SND_PCI_QUIRK(0x144d, 0xc169, "Samsung Notebook 9 Pen (NP930SBE-K01US)", ALC298_FIXUP_SAMSUNG_AMP),

@@ -9943,7 +9943,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
 	SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
 	SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
-	SND_PCI_QUIRK(0x8086, 0x3038, "Intel NUC 13", ALC225_FIXUP_HEADSET_JACK),
+	SND_PCI_QUIRK(0x8086, 0x3038, "Intel NUC 13", ALC295_FIXUP_CHROME_BOOK),
 	SND_PCI_QUIRK(0xf111, 0x0001, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 
 #if 0

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #34 lore raw

PATCH 31/191 ASoC: SOF: amd: fix for firmware reload failure after playback

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vijendar Mukunda <[email protected]>

commit 7e1fe5d9e7eae67e218f878195d1d348d01f9af7 upstream.

Setting ACP ACLK as clock source when ACP enters D0 state causing firmware load failure as mentioned in below scenario.

- Load snd_sof_amd_rembrandt
- Play or Record audio
- Stop audio
- Unload snd_sof_amd_rembrandt
- Reload snd_sof_amd_rembrandt

If acp_clkmux_sel register field is set, then clock source will be set to ACP ACLK when ACP enters D0 state.

During stream stop, if there is no active stream is running then acp firmware will set the ACP ACLK value to zero.

When driver is reloaded and clock source is selected as ACP ACLK, as ACP ACLK is programmed to zero, firmware loading will fail.

For RMB platform, remove the clock mux selection field so that ACP will use internal clock source when ACP enters D0 state.

Fixes 41cb85bc4b52 ("ASoC: SOF: amd: Add support for Rembrandt plaform.")

Reported-by coolstar <[email protected]>

Closes https://github.com/thesofproject/sof/issues/8137

Signed-off-by Vijendar Mukunda <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/sof/amd/pci-rmb.c |    1 -
 1 file changed, 1 deletion(-)

sound/soc/sof/amd/pci-rmb.c +0 -1

@@ -34,7 +34,6 @@ static const struct sof_amd_acp_desc rem
 	.dsp_intr_base	= ACP6X_DSP_SW_INTR_BASE,
 	.sram_pte_offset = ACP6X_SRAM_PTE_OFFSET,
 	.hw_semaphore_offset = ACP6X_AXI2DAGB_SEM_0,
-	.acp_clkmux_sel = ACP6X_CLKMUX_SEL,
 	.fusion_dsp_offset = ACP6X_DSP_FUSION_RUNSTALL,
 };

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #35 lore raw

PATCH 32/191 ASoC: simple-card-utils: fixup simple_util_startup() error handling

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kuninori Morimoto <[email protected]>

commit 69cf63b6560205a390a736b88d112374655adb28 upstream.

It should use "goto" instead of "return"

Fixes 5ca2ab459817 ("ASoC: simple-card-utils: Add new system-clock-fixed flag")

Reported-by kernel test robot <[email protected]>

Reported-by Dan Carpenter <[email protected]>

Closes https://lore.kernel.org/all/[email protected]/ open here

Signed-off-by Kuninori Morimoto <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/generic/simple-card-utils.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/soc/generic/simple-card-utils.c +2 -1

@@ -310,7 +310,8 @@ int asoc_simple_startup(struct snd_pcm_s
 		if (fixed_sysclk % props->mclk_fs) {
 			dev_err(rtd->dev, "fixed sysclk %u not divisible by mclk_fs %u\n",
 				fixed_sysclk, props->mclk_fs);
-			return -EINVAL;
+			ret = -EINVAL;
+			goto codec_err;
 		}
 		ret = snd_pcm_hw_constraint_minmax(substream->runtime, SNDRV_PCM_HW_PARAM_RATE,
 			fixed_rate, fixed_rate);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #36 lore raw

PATCH 33/191 ASoC: Intel: soc-acpi: fix Dell SKU 0B34

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pierre-Louis Bossart <[email protected]>

commit b399f9706a1cbae42731cc420a46cfb9c3c6b10f upstream.

The rule for the SoundWire tables is that the platforms with more devices need to be added first. We broke that rule with the Dell SKU 0B34, and caused the second amplifier for SKU 0AF3 to be ignored.

The fix is simple, we need to move the single-amplifier entry after the two-amplifier one.

Fixes b62a1a839b48 ("ASoC: Intel: soc-acpi: add tables for Dell SKU 0B34")

Closes https://github.com/thesofproject/linux/issues/4559

Signed-off-by Pierre-Louis Bossart <[email protected]>

Reviewed-by Chao Song <[email protected]>

Signed-off-by Bard Liao <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/intel/common/soc-acpi-intel-adl-match.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

sound/soc/intel/common/soc-acpi-intel-adl-match.c +6 -6

@@ -649,18 +649,18 @@ struct snd_soc_acpi_mach snd_soc_acpi_in
 		.sof_tplg_filename = "sof-adl-rt1316-l2-mono-rt714-l3.tplg",
 	},
 	{
-		.link_mask = 0x3, /* rt1316 on link1 & rt714 on link0 */
-		.links = adl_sdw_rt1316_link1_rt714_link0,
-		.drv_name = "sof_sdw",
-		.sof_tplg_filename = "sof-adl-rt1316-l1-mono-rt714-l0.tplg",
-	},
-	{
 		.link_mask = 0x7, /* rt714 on link0 & two rt1316s on link1 and link2 */
 		.links = adl_sdw_rt1316_link12_rt714_link0,
 		.drv_name = "sof_sdw",
 		.sof_tplg_filename = "sof-adl-rt1316-l12-rt714-l0.tplg",
 	},
 	{
+		.link_mask = 0x3, /* rt1316 on link1 & rt714 on link0 */
+		.links = adl_sdw_rt1316_link1_rt714_link0,
+		.drv_name = "sof_sdw",
+		.sof_tplg_filename = "sof-adl-rt1316-l1-mono-rt714-l0.tplg",
+	},
+	{
 		.link_mask = 0x5, /* 2 active links required */
 		.links = adl_sdw_rt1316_link2_rt714_link0,
 		.drv_name = "sof_sdw",

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #37 lore raw

PATCH 34/191 ASoC: Intel: soc-acpi: Add entry for HDMI_In capture support in MTL match table

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Balamurugan C <[email protected]>

commit d1f67278d4b2de3bf544ea9bcd9f64d03584df87 upstream.

Adding HDMI-In capture via I2S feature support in MTL platform.

Signed-off-by Balamurugan C <[email protected]>

Reviewed-by Pierre-Louis Bossart <[email protected]>

Signed-off-by Bard Liao <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/intel/boards/sof_es8336.c               |   10 ++++++++++
 sound/soc/intel/common/soc-acpi-intel-mtl-match.c |   12 ++++++++++++
 2 files changed, 22 insertions(+)

sound/soc/intel/boards/sof_es8336.c +10 -0

@@ -798,6 +798,16 @@ static const struct platform_device_id b
 					SOF_ES8336_SPEAKERS_EN_GPIO1_QUIRK |
 					SOF_ES8336_JD_INVERTED),
 	},
+	{
+		.name = "mtl_es83x6_c1_h02",
+		.driver_data = (kernel_ulong_t)(SOF_ES8336_SSP_CODEC(1) |
+					SOF_NO_OF_HDMI_CAPTURE_SSP(2) |
+					SOF_HDMI_CAPTURE_1_SSP(0) |
+					SOF_HDMI_CAPTURE_2_SSP(2) |
+					SOF_SSP_HDMI_CAPTURE_PRESENT |
+					SOF_ES8336_SPEAKERS_EN_GPIO1_QUIRK |
+					SOF_ES8336_JD_INVERTED),
+	},
 	{ }
 };
 MODULE_DEVICE_TABLE(platform, board_ids);

sound/soc/intel/common/soc-acpi-intel-mtl-match.c +12 -0

@@ -30,6 +30,11 @@ static const struct snd_soc_acpi_codecs
 	.codecs = {"10EC5682", "RTL5682"},
 };
 
+static const struct snd_soc_acpi_codecs mtl_lt6911_hdmi = {
+	.num_codecs = 1,
+	.codecs = {"INTC10B0"}
+};
+
 struct snd_soc_acpi_mach snd_soc_acpi_intel_mtl_machines[] = {
 	{
 		.comp_ids = &mtl_rt5682_rt5682s_hp,

@@ -46,6 +51,13 @@ struct snd_soc_acpi_mach snd_soc_acpi_in
 		.sof_tplg_filename = "sof-mtl-max98360a-rt5682.tplg",
 	},
 	{
+		.comp_ids = &mtl_essx_83x6,
+		.drv_name = "mtl_es83x6_c1_h02",
+		.machine_quirk = snd_soc_acpi_codec_list,
+		.quirk_data = &mtl_lt6911_hdmi,
+		.sof_tplg_filename = "sof-mtl-es83x6-ssp1-hdmi-ssp02.tplg",
+	},
+	{
 		.comp_ids = &mtl_rt5682_rt5682s_hp,
 		.drv_name = "mtl_rt1019_rt5682",
 		.machine_quirk = snd_soc_acpi_codec_list,

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #38 lore raw

PATCH 35/191 ASoC: fsl_sai: Dont disable bitclock for i.MX8MP

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shengjiu Wang <[email protected]>

commit 197c53c8ecb34f2cd5922f4bdcffa8f701a134eb upstream.

On i.MX8MP, the BCE and TERE bit are binding with mclk enablement, if BCE and TERE are cleared the MCLK also be disabled on output pin, that cause the external codec (wm8960) in wrong state.

Codec (wm8960) is using the mclk to generate PLL clock, if mclk is disabled before disabling PLL, the codec (wm8960) won't generate bclk and frameclk when sysclk switch to MCLK source in next test case.

The test case:
$aplay -r44100 test1.wav (PLL source)
$aplay -r48000 test2.wav (MCLK source)
aplay: pcm_write:2127: write error: Input/output error

Fixes 269f399dc19f ("ASoC: fsl_sai: Disable bit clock with transmitter")

Signed-off-by Shengjiu Wang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/fsl/fsl_sai.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

sound/soc/fsl/fsl_sai.c +7 -2

@@ -710,10 +710,15 @@ static void fsl_sai_config_disable(struc
 {
 	unsigned int ofs = sai->soc_data->reg_offset;
 	bool tx = dir == TX;
-	u32 xcsr, count = 100;
+	u32 xcsr, count = 100, mask;
+
+	if (sai->soc_data->mclk_with_tere && sai->mclk_direction_output)
+		mask = FSL_SAI_CSR_TERE;
+	else
+		mask = FSL_SAI_CSR_TERE | FSL_SAI_CSR_BCE;
 
 	regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx, ofs),
-			   FSL_SAI_CSR_TERE | FSL_SAI_CSR_BCE, 0);
+			   mask, 0);
 
 	/* TERE will remain set till the end of current frame */
 	do {

Greg Kroah-Hartman

author maintainer

2023-10-16 14:25 UTC #39 lore raw

PATCH 36/191 ASoC: Intel: sof_sdw: add support for SKU 0B14

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pierre-Louis Bossart <[email protected]>

commit fb0b8d299781be8d46b3612aa96cef28da0d93f4 upstream.

One more missing SKU in the list.

Closes https://github.com/thesofproject/linux/issues/4543

Signed-off-by Pierre-Louis Bossart <[email protected]>

Reviewed-by Chao Song <[email protected]>

Signed-off-by Bard Liao <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/intel/boards/sof_sdw.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

sound/soc/intel/boards/sof_sdw.c +10 -0

@@ -388,6 +388,16 @@ static const struct dmi_system_id sof_sd
 	{
 		.callback = sof_sdw_quirk_cb,
 		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
+			DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "0B14"),
+		},
+		/* No Jack */
+		.driver_data = (void *)SOF_SDW_TGL_HDMI,
+	},
+
+	{
+		.callback = sof_sdw_quirk_cb,
+		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
 			DMI_MATCH(DMI_PRODUCT_NAME, "OMEN by HP Gaming Laptop 16-k0xxx"),
 		},

Greg Kroah-Hartman

author maintainer

2023-10-16 14:26 UTC #40 lore raw

PATCH 37/191 ASoC: Intel: soc-acpi: Add entry for sof_es8336 in MTL match table.

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Balamurugan C <[email protected]>

commit 381ddcd5875e496f2eae06bb65853271b7150fee upstream.

Adding support for ES83x6 codec in MTL match table.

Signed-off-by Balamurugan C <[email protected]>

Reviewed-by Pierre-Louis Bossart <[email protected]>

Signed-off-by Bard Liao <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/intel/common/soc-acpi-intel-mtl-match.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

sound/soc/intel/common/soc-acpi-intel-mtl-match.c +13 -0

@@ -35,6 +35,11 @@ static const struct snd_soc_acpi_codecs
 	.codecs = {"INTC10B0"}
 };
 
+static const struct snd_soc_acpi_codecs mtl_essx_83x6 = {
+	.num_codecs = 3,
+	.codecs = { "ESSX8316", "ESSX8326", "ESSX8336"},
+};
+
 struct snd_soc_acpi_mach snd_soc_acpi_intel_mtl_machines[] = {
 	{
 		.comp_ids = &mtl_rt5682_rt5682s_hp,

@@ -64,6 +69,14 @@ struct snd_soc_acpi_mach snd_soc_acpi_in
 		.quirk_data = &mtl_rt1019p_amp,
 		.sof_tplg_filename = "sof-mtl-rt1019-rt5682.tplg",
 	},
+	{
+		.comp_ids = &mtl_essx_83x6,
+		.drv_name = "sof-essx8336",
+		.sof_tplg_filename = "sof-mtl-es8336", /* the tplg suffix is added at run time */
+		.tplg_quirk_mask = SND_SOC_ACPI_TPLG_INTEL_SSP_NUMBER |
+					SND_SOC_ACPI_TPLG_INTEL_SSP_MSB |
+					SND_SOC_ACPI_TPLG_INTEL_DMIC_NUMBER,
+	},
 	{},
 };
 EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_mtl_machines);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:26 UTC #41 lore raw

PATCH 38/191 ALSA: hda/realtek: Add quirk for HP Victus 16-d1xxx to enable mute LED

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: SungHwan Jung <[email protected]>

[ Upstream commit 93dc18e11b1ab2d485b69f91c973e6b83e47ebd0 ]

This quirk enables mute LED on HP Victus 16-d1xxx (8A25) laptops, which use ALC245 codec.

Signed-off-by SungHwan Jung <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP")

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/hda/patch_realtek.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

sound/pci/hda/patch_realtek.c +22 -0

index 333c3664082c7..39e3810f75222 100644
@@ -4639,6 +4639,22 @@ static void alc236_fixup_hp_mute_led_coefbit2(struct hda_codec *codec,
 	}
 }
 
+static void alc245_fixup_hp_mute_led_coefbit(struct hda_codec *codec,
+					  const struct hda_fixup *fix,
+					  int action)
+{
+	struct alc_spec *spec = codec->spec;
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE) {
+		spec->mute_led_polarity = 0;
+		spec->mute_led_coef.idx = 0x0b;
+		spec->mute_led_coef.mask = 3 << 2;
+		spec->mute_led_coef.on = 2 << 2;
+		spec->mute_led_coef.off = 1 << 2;
+		snd_hda_gen_add_mute_led_cdev(codec, coef_mute_led_set);
+	}
+}
+
 /* turn on/off mic-mute LED per capture hook by coef bit */
 static int coef_micmute_led_set(struct led_classdev *led_cdev,
 				enum led_brightness brightness)

@@ -7231,6 +7247,7 @@ enum {
 	ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS,
 	ALC236_FIXUP_DELL_DUAL_CODECS,
 	ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI,
+	ALC245_FIXUP_HP_MUTE_LED_COEFBIT,
 };
 
 /* A special fixup for Lenovo C940 and Yoga Duet 7;

@@ -9309,6 +9326,10 @@ static const struct hda_fixup alc269_fixups[] = {
 		.chained = true,
 		.chain_id = ALC269_FIXUP_THINKPAD_ACPI,
 	},
+	[ALC245_FIXUP_HP_MUTE_LED_COEFBIT] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc245_fixup_hp_mute_led_coefbit,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -9582,6 +9603,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x89c6, "Zbook Fury 17 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x89ca, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x89d3, "HP EliteBook 645 G9 (MB 89D2)", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+	SND_PCI_QUIRK(0x103c, 0x8a25, "HP Victus 16-d1xxx (MB 8A25)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT),
 	SND_PCI_QUIRK(0x103c, 0x8a78, "HP Dev One", ALC285_FIXUP_HP_LIMIT_INT_MIC_BOOST),
 	SND_PCI_QUIRK(0x103c, 0x8aa0, "HP ProBook 440 G9 (MB 8A9E)", ALC236_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x8aa3, "HP ProBook 450 G9 (MB 8AA1)", ALC236_FIXUP_HP_GPIO_LED),

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:26 UTC #42 lore raw

PATCH 39/191 ALSA: hda/realtek: Add quirk for mute LEDs on HP ENVY x360 15-eu0xxx

Link https://lore.kernel.org/r/2693091.mvXUDI8C0e@fabians-envy open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Fabian Vogt <[email protected]>

[ Upstream commit c99c26b16c1544534ebd6a5f27a034f3e44d2597 ]

The LED for the mic mute button is controlled by GPIO2.
The mute button LED is slightly more complex, it's controlled by two bits in coeff 0x0b.

Signed-off-by Fabian Vogt <[email protected]>

Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP")

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/hda/patch_realtek.c | 8 ++++++++
 1 file changed, 8 insertions(+)

sound/pci/hda/patch_realtek.c +8 -0

index 39e3810f75222..bcb48449608a0 100644
@@ -7248,6 +7248,7 @@ enum {
 	ALC236_FIXUP_DELL_DUAL_CODECS,
 	ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI,
 	ALC245_FIXUP_HP_MUTE_LED_COEFBIT,
+	ALC245_FIXUP_HP_X360_MUTE_LEDS,
 };
 
 /* A special fixup for Lenovo C940 and Yoga Duet 7;

@@ -9330,6 +9331,12 @@ static const struct hda_fixup alc269_fixups[] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc245_fixup_hp_mute_led_coefbit,
 	},
+	[ALC245_FIXUP_HP_X360_MUTE_LEDS] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc245_fixup_hp_mute_led_coefbit,
+		.chained = true,
+		.chain_id = ALC245_FIXUP_HP_GPIO_LED
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -9572,6 +9579,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8870, "HP ZBook Fury 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
 	SND_PCI_QUIRK(0x103c, 0x8873, "HP ZBook Studio 15.6 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
 	SND_PCI_QUIRK(0x103c, 0x887a, "HP Laptop 15s-eq2xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
+	SND_PCI_QUIRK(0x103c, 0x888a, "HP ENVY x360 Convertible 15-eu0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
 	SND_PCI_QUIRK(0x103c, 0x888d, "HP ZBook Power 15.6 inch G8 Mobile Workstation PC", ALC236_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x8895, "HP EliteBook 855 G8 Notebook PC", ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8896, "HP EliteBook 855 G8 Notebook PC", ALC285_FIXUP_HP_MUTE_LED),

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:45 UTC #43 lore raw

PATCH 40/191 ALSA: hda/realtek - ALC287 I2S speaker platform support

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kailang Yang <[email protected]>

[ Upstream commit e43252db7e207a2e194e6a4883a43a31a776a968 ]

0x17 was only speaker pin, DAC assigned will be 0x03. Headphone assigned to 0x02.
Playback via headphone will get EQ filter processing. So,it needs to swap DAC.

Tested-by Mark Pearson <[email protected]>

Signed-off-by Kailang Yang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP")

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/hda/patch_realtek.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

sound/pci/hda/patch_realtek.c +30 -0

index bcb48449608a0..963465286bdc6 100644
@@ -6988,6 +6988,27 @@ static void alc295_fixup_dell_inspiron_top_speakers(struct hda_codec *codec,
 	}
 }
 
+/* Forcibly assign NID 0x03 to HP while NID 0x02 to SPK */
+static void alc287_fixup_bind_dacs(struct hda_codec *codec,
+				    const struct hda_fixup *fix, int action)
+{
+	struct alc_spec *spec = codec->spec;
+	static const hda_nid_t conn[] = { 0x02, 0x03 }; /* exclude 0x06 */
+	static const hda_nid_t preferred_pairs[] = {
+		0x17, 0x02, 0x21, 0x03, 0
+	};
+
+	if (action != HDA_FIXUP_ACT_PRE_PROBE)
+		return;
+
+	snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn), conn);
+	spec->gen.preferred_dacs = preferred_pairs;
+	spec->gen.auto_mute_via_amp = 1;
+	snd_hda_codec_write_cache(codec, 0x14, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
+			    0x0); /* Make sure 0x14 was disable */
+}
+
+
 enum {
 	ALC269_FIXUP_GPIO2,
 	ALC269_FIXUP_SONY_VAIO,

@@ -7249,6 +7270,7 @@ enum {
 	ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI,
 	ALC245_FIXUP_HP_MUTE_LED_COEFBIT,
 	ALC245_FIXUP_HP_X360_MUTE_LEDS,
+	ALC287_FIXUP_THINKPAD_I2S_SPK,
 };
 
 /* A special fixup for Lenovo C940 and Yoga Duet 7;

@@ -9337,6 +9359,10 @@ static const struct hda_fixup alc269_fixups[] = {
 		.chained = true,
 		.chain_id = ALC245_FIXUP_HP_GPIO_LED
 	},
+	[ALC287_FIXUP_THINKPAD_I2S_SPK] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc287_fixup_bind_dacs,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -10455,6 +10481,10 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = {
 		{0x17, 0x90170111},
 		{0x19, 0x03a11030},
 		{0x21, 0x03211020}),
+	SND_HDA_PIN_QUIRK(0x10ec0287, 0x17aa, "Lenovo", ALC287_FIXUP_THINKPAD_I2S_SPK,
+		{0x17, 0x90170110},
+		{0x19, 0x03a11030},
+		{0x21, 0x03211020}),
 	SND_HDA_PIN_QUIRK(0x10ec0286, 0x1025, "Acer", ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
 		{0x12, 0x90a60130},
 		{0x17, 0x90170110},

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:45 UTC #44 lore raw

PATCH 41/191 ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kailang Yang <[email protected]>

[ Upstream commit d93eeca627db512a56145285dc94feac5b88a1d4 ]

This is merge model ALC287_FIXUP_THINKPAD_I2S_SPK and ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI.

Signed-off-by Kailang Yang <[email protected]>

Fixes f7b069cf0881 ("ALSA: hda/realtek: Fix generic fixup definition for cs35l41 amp")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/hda/patch_realtek.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

sound/pci/hda/patch_realtek.c +15 -8

index 963465286bdc6..a505be0fed961 100644
@@ -7271,6 +7271,7 @@ enum {
 	ALC245_FIXUP_HP_MUTE_LED_COEFBIT,
 	ALC245_FIXUP_HP_X360_MUTE_LEDS,
 	ALC287_FIXUP_THINKPAD_I2S_SPK,
+	ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD,
 };
 
 /* A special fixup for Lenovo C940 and Yoga Duet 7;

@@ -9363,6 +9364,12 @@ static const struct hda_fixup alc269_fixups[] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc287_fixup_bind_dacs,
 	},
+	[ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc287_fixup_bind_dacs,
+		.chained = true,
+		.chain_id = ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI,
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -9910,14 +9917,14 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x22be, "Thinkpad X1 Carbon 8th", ALC285_FIXUP_THINKPAD_HEADSET_JACK),
 	SND_PCI_QUIRK(0x17aa, 0x22c1, "Thinkpad P1 Gen 3", ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK),
 	SND_PCI_QUIRK(0x17aa, 0x22c2, "Thinkpad X1 Extreme Gen 3", ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK),
-	SND_PCI_QUIRK(0x17aa, 0x22f1, "Thinkpad", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
-	SND_PCI_QUIRK(0x17aa, 0x22f2, "Thinkpad", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
-	SND_PCI_QUIRK(0x17aa, 0x22f3, "Thinkpad", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
-	SND_PCI_QUIRK(0x17aa, 0x2316, "Thinkpad P1 Gen 6", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
-	SND_PCI_QUIRK(0x17aa, 0x2317, "Thinkpad P1 Gen 6", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
-	SND_PCI_QUIRK(0x17aa, 0x2318, "Thinkpad Z13 Gen2", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
-	SND_PCI_QUIRK(0x17aa, 0x2319, "Thinkpad Z16 Gen2", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
-	SND_PCI_QUIRK(0x17aa, 0x231a, "Thinkpad Z16 Gen2", ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI),
+	SND_PCI_QUIRK(0x17aa, 0x22f1, "Thinkpad", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x22f2, "Thinkpad", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x22f3, "Thinkpad", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x2316, "Thinkpad P1 Gen 6", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x2317, "Thinkpad P1 Gen 6", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x2318, "Thinkpad Z13 Gen2", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x2319, "Thinkpad Z16 Gen2", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x231a, "Thinkpad Z16 Gen2", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
 	SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
 	SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
 	SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:45 UTC #45 lore raw

PATCH 42/191 pinctrl: nuvoton: wpcm450: fix out of bounds write

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mikhail Kobuk <[email protected]>

[ Upstream commit 87d315a34133edcb29c4cadbf196ec6c30dfd47b ]

Write into 'pctrl->gpio_bank' happens before the check for GPIO index validity, so out of bounds write may happen.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes a1d1e0e3d80a ("pinctrl: nuvoton: Add driver for WPCM450")

Signed-off-by Mikhail Kobuk <[email protected]>

Reviewed-by Alexey Khoroshilov <[email protected]>

Reviewed-by Jonathan Neuschäfer <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Linus Walleij <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pinctrl/nuvoton/pinctrl-wpcm450.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/pinctrl/nuvoton/pinctrl-wpcm450.c +3 -3

index 2d1c1652cfd9d..8a9961ac87128 100644
@@ -1062,13 +1062,13 @@ static int wpcm450_gpio_register(struct platform_device *pdev,
 		if (ret < 0)
 			return ret;
 
-		gpio = &pctrl->gpio_bank[reg];
-		gpio->pctrl = pctrl;
-
 		if (reg >= WPCM450_NUM_BANKS)
 			return dev_err_probe(dev, -EINVAL,
 					     "GPIO index %d out of range!\n", reg);
 
+		gpio = &pctrl->gpio_bank[reg];
+		gpio->pctrl = pctrl;
+
 		bank = &wpcm450_banks[reg];
 		gpio->bank = bank;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:45 UTC #46 lore raw

PATCH 43/191 pinctrl: starfive: jh7110: Fix failure to set irq after CONFIG_PM is enabled

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hal Feng <[email protected]>

[ Upstream commit 8406d6b5916663b4edc604b3effbf4935b61c2da ]

The issue was found when we enabled CONFIG_PM and tested edge events using libgpiod.

Quoted 2 lines

# gpiomon -r gpiochip0 55
gpiomon: error waiting for events: Permission denied

gpiomon will call irq_chip_pm_get() and then call pm_runtime_resume_and_get() if (IS_ENABLED(CONFIG_PM) && sfp->gc.irq.domain->pm_dev). pm_runtime_resume_and_get() will fail if the runtime pm of pinctrl device is disabled.

As we expect the pinctrl driver can be always working and never suspend during runtime, unset sfp->gc.irq.domain->pm_dev to make sure pm_runtime_resume_and_get() won't be called when setting irq.

Fixes 447976ab62c5 ("pinctrl: starfive: Add StarFive JH7110 sys controller driver")

Signed-off-by Hal Feng <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Linus Walleij <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c | 2 --
 1 file changed, 2 deletions(-)

drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c +0 -2

index 5fe729b4a03de..72747ad497b5e 100644
@@ -968,8 +968,6 @@ int jh7110_pinctrl_probe(struct platform_device *pdev)
 	if (ret)
 		return dev_err_probe(dev, ret, "could not register gpiochip\n");
 
-	irq_domain_set_pm_device(sfp->gc.irq.domain, dev);
-
 	dev_info(dev, "StarFive GPIO chip registered %d GPIOs\n", sfp->gc.ngpio);
 
 	return pinctrl_enable(sfp->pctl);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #47 lore raw

PATCH 44/191 drm/msm/dp: do not reinitialize phy unless retry during link training

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kuogee Hsieh <[email protected]>

[ Upstream commit 0c1a2e69bcb506f48ebf94bd199bab0b93f66da2 ]

DP PHY re-initialization done using dp_ctrl_reinitialize_mainlink() will cause PLL unlocked initially and then PLL gets locked at the end of initialization. PLL_UNLOCKED interrupt will fire during this time if the interrupt mask is enabled.

However currently DP driver link training implementation incorrectly re-initializes PHY unconditionally during link training as the PHY was already configured in dp_ctrl_enable_mainlink_clocks().

Fix this by re-initializing the PHY only if the previous link training failed.

[drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy

Fixes c943b4948b58 ("drm/msm/dp: add displayPort driver support")

Closes https://gitlab.freedesktop.org/drm/msm/-/issues/30

Signed-off-by Kuogee Hsieh <[email protected]>

Tested-by Abhinav Kumar <[email protected]> # sc7280

Reviewed-by Abhinav Kumar <[email protected]>

Reviewed-by Stephen Boyd <[email protected]>

Tested-by Dmitry Baryshkov <[email protected]>

Patchwork: https://patchwork.freedesktop.org/patch/551847/

Link https://lore.kernel.org/r/[email protected] open here

[[email protected]: added line break in commit text]

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/dp/dp_ctrl.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

drivers/gpu/drm/msm/dp/dp_ctrl.c +6 -7

index a7a5c7e0ab923..77a8d9366ed7b 100644
@@ -1774,13 +1774,6 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
 		return rc;
 
 	while (--link_train_max_retries) {
-		rc = dp_ctrl_reinitialize_mainlink(ctrl);
-		if (rc) {
-			DRM_ERROR("Failed to reinitialize mainlink. rc=%d\n",
-					rc);
-			break;
-		}
-
 		training_step = DP_TRAINING_NONE;
 		rc = dp_ctrl_setup_main_link(ctrl, &training_step);
 		if (rc == 0) {

@@ -1832,6 +1825,12 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
 			/* stop link training before start re training  */
 			dp_ctrl_clear_training_pattern(ctrl);
 		}
+
+		rc = dp_ctrl_reinitialize_mainlink(ctrl);
+		if (rc) {
+			DRM_ERROR("Failed to reinitialize mainlink. rc=%d\n", rc);
+			break;
+		}
 	}
 
 	if (ctrl->link->sink_request & DP_TEST_LINK_PHY_TEST_PATTERN)

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #48 lore raw

PATCH 45/191 drm/msm/dsi: skip the wait for video mode done if not applicable

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Abhinav Kumar <[email protected]>

[ Upstream commit ab483e3adcc178254eb1ce0fbdfbea65f86f1006 ]

dsi_wait4video_done() API waits for the DSI video mode engine to become idle so that we can transmit the DCS commands in the beginning of BLLP. However, with the current sequence, the MDP timing engine is turned on after the panel's pre_enable() callback which can send out the DCS commands needed to power up the panel.

During those cases, this API will always timeout and print out the error spam leading to long bootup times and log flooding.

Fix this by checking if the DSI video engine was actually busy before waiting for it to become idle otherwise this is a redundant wait.

changes in v2:
- move the reg read below the video mode check
- minor fixes in commit text

Closes https://gitlab.freedesktop.org/drm/msm/-/issues/34

Fixes a689554ba6ed ("drm/msm: Initial add DSI connector support")

Patchwork: https://patchwork.freedesktop.org/patch/557853/

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/gpu/drm/msm/dsi/dsi_host.c +12 -0

index 3f6dfb4f9d5a6..ee91bad0d5880 100644
@@ -1075,9 +1075,21 @@ static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
 
 static void dsi_wait4video_eng_busy(struct msm_dsi_host *msm_host)
 {
+	u32 data;
+
 	if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
 		return;
 
+	data = dsi_read(msm_host, REG_DSI_STATUS0);
+
+	/* if video mode engine is not busy, its because
+	 * either timing engine was not turned on or the
+	 * DSI controller has finished transmitting the video
+	 * data already, so no need to wait in those cases
+	 */
+	if (!(data & DSI_STATUS0_VIDEO_MODE_ENGINE_BUSY))
+		return;
+
 	if (msm_host->power_on && msm_host->enabled) {
 		dsi_wait4video_done(msm_host);
 		/* delay 4 ms to skip BLLP */

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #49 lore raw

PATCH 46/191 drm/msm/dsi: fix irq_of_parse_and_map() error checking

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit 6a1d4c7976dd1ee7c9f80bc8e62801ec7b1f2f58 ]

The irq_of_parse_and_map() function returns zero on error. It never returns negative error codes. Fix the check.

Fixes a689554ba6ed ("drm/msm: Initial add DSI connector support")

Reviewed-by Konrad Dybcio <[email protected]>

Reviewed-by Abhinav Kumar <[email protected]>

Patchwork: https://patchwork.freedesktop.org/patch/557715/

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

drivers/gpu/drm/msm/dsi/dsi_host.c +3 -4

index ee91bad0d5880..9ac62651eb756 100644
@@ -1899,10 +1899,9 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
 	}
 
 	msm_host->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
-	if (msm_host->irq < 0) {
-		ret = msm_host->irq;
-		dev_err(&pdev->dev, "failed to get irq: %d\n", ret);
-		return ret;
+	if (!msm_host->irq) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		return -EINVAL;
 	}
 
 	/* do not autoenable, will be enabled later */

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #50 lore raw

PATCH 47/191 drm/msm/dpu: change _dpu_plane_calc_bw() to use u64 to avoid overflow

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Abhinav Kumar <[email protected]>

[ Upstream commit 95e681ca3b65e4ce3d2537b47672d787b7d30375 ]

_dpu_plane_calc_bw() uses integer variables to calculate the bandwidth used during plane bandwidth calculations. However for high resolution displays this overflows easily and leads to below errors

[dpu error]crtc83 failed performance check -7

Promote the intermediate variables to u64 to avoid overflow.

changes in v2:
- change to u64 where actually needed in the math

Fixes c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")

Reported-by Nia Espera <[email protected]>

Closes https://gitlab.freedesktop.org/drm/msm/-/issues/32

Tested-by Nia Espera <[email protected]>

Patchwork: https://patchwork.freedesktop.org/patch/556288/

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +6 -6

index c2aaaded07ed6..98c1b22e9bca0 100644
@@ -119,6 +119,7 @@ static u64 _dpu_plane_calc_bw(const struct dpu_mdss_cfg *catalog,
 	struct dpu_sw_pipe_cfg *pipe_cfg)
 {
 	int src_width, src_height, dst_height, fps;
+	u64 plane_pixel_rate, plane_bit_rate;
 	u64 plane_prefill_bw;
 	u64 plane_bw;
 	u32 hw_latency_lines;

@@ -136,13 +137,12 @@ static u64 _dpu_plane_calc_bw(const struct dpu_mdss_cfg *catalog,
 	scale_factor = src_height > dst_height ?
 		mult_frac(src_height, 1, dst_height) : 1;
 
-	plane_bw =
-		src_width * mode->vtotal * fps * fmt->bpp *
-		scale_factor;
+	plane_pixel_rate = src_width * mode->vtotal * fps;
+	plane_bit_rate = plane_pixel_rate * fmt->bpp;
 
-	plane_prefill_bw =
-		src_width * hw_latency_lines * fps * fmt->bpp *
-		scale_factor * mode->vtotal;
+	plane_bw = plane_bit_rate * scale_factor;
+
+	plane_prefill_bw = plane_bw * hw_latency_lines;
 
 	if ((vbp+vpw) > hw_latency_lines)
 		do_div(plane_prefill_bw, (vbp+vpw));

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #51 lore raw

PATCH 48/191 drm/msm/dp: Add newlines to debug printks

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stephen Boyd <[email protected]>

[ Upstream commit eba8c99a0fc45da1c8d5b5f5bd1dc2e79229a767 ]

These debug printks are missing newlines, causing drm debug logs to be hard to read. Add newlines so that the messages are on their own line.

Cc Kuogee Hsieh <[email protected]>

Cc Vinod Polimera <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Fixes 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of debugging")

Fixes cd779808cccd ("drm/msm/dp: Add basic PSR support for eDP")

Reviewed-by Abhinav Kumar <[email protected]>

Patchwork: https://patchwork.freedesktop.org/patch/554533/

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/dp/dp_link.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/msm/dp/dp_link.c +2 -2

index 42427129acea8..6375daaeb98e1 100644
@@ -1090,7 +1090,7 @@ int dp_link_process_request(struct dp_link *dp_link)
 	} else if (dp_link_read_psr_error_status(link)) {
 		DRM_ERROR("PSR IRQ_HPD received\n");
 	} else if (dp_link_psr_capability_changed(link)) {
-		drm_dbg_dp(link->drm_dev, "PSR Capability changed");
+		drm_dbg_dp(link->drm_dev, "PSR Capability changed\n");
 	} else {
 		ret = dp_link_process_link_status_update(link);
 		if (!ret) {

@@ -1107,7 +1107,7 @@ int dp_link_process_request(struct dp_link *dp_link)
 		}
 	}
 
-	drm_dbg_dp(link->drm_dev, "sink request=%#x",
+	drm_dbg_dp(link->drm_dev, "sink request=%#x\n",
 				dp_link->sink_request);
 	return ret;
 }

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #52 lore raw

PATCH 49/191 drm/msm/dpu: fail dpu_plane_atomic_check() based on mdp clk limits

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Abhinav Kumar <[email protected]>

[ Upstream commit 10f20628c9b8e924b8046e63b36b2cea4d2c85e4 ]

Currently, dpu_plane_atomic_check() does not check whether the plane can process the image without exceeding the per chipset limits for MDP clock. This leads to underflow issues because the SSPP is not able to complete the processing for the data rate of the display.

Fail the dpu_plane_atomic_check() if the SSPP cannot process the image without exceeding the MDP clock limits.

changes in v2:
- use crtc_state's adjusted_mode instead of mode

Fixes 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

Patchwork: https://patchwork.freedesktop.org/patch/556819/

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +12 -3

index 98c1b22e9bca0..0be195f9149c5 100644
@@ -733,9 +733,11 @@ static int dpu_plane_check_inline_rotation(struct dpu_plane *pdpu,
 static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
 		struct dpu_sw_pipe *pipe,
 		struct dpu_sw_pipe_cfg *pipe_cfg,
-		const struct dpu_format *fmt)
+		const struct dpu_format *fmt,
+		const struct drm_display_mode *mode)
 {
 	uint32_t min_src_size;
+	struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
 
 	min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;

@@ -774,6 +776,12 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
 		return -EINVAL;
 	}
 
+	/* max clk check */
+	if (_dpu_plane_calc_clk(mode, pipe_cfg) > kms->perf.max_core_clk_rate) {
+		DPU_DEBUG_PLANE(pdpu, "plane exceeds max mdp core clk limits\n");
+		return -E2BIG;
+	}
+
 	return 0;
 }

@@ -899,12 +907,13 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
 		r_pipe_cfg->dst_rect.x1 = pipe_cfg->dst_rect.x2;
 	}
 
-	ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt);
+	ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt, &crtc_state->adjusted_mode);
 	if (ret)
 		return ret;
 
 	if (r_pipe->sspp) {
-		ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg, fmt);
+		ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg, fmt,
+						  &crtc_state->adjusted_mode);
 		if (ret)
 			return ret;
 	}

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #53 lore raw

PATCH 50/191 phy: lynx-28g: cancel the CDR check work item on the remove path

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ioana Ciornei <[email protected]>

[ Upstream commit f200bab3756fe81493a1b280180dafa1d9ccdcf7 ]

The blamed commit added the CDR check work item but didn't cancel it on the remove path. Fix this by adding a remove function which takes care of it.

Fixes 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G")

Signed-off-by Ioana Ciornei <[email protected]>

Signed-off-by Vladimir Oltean <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/phy/freescale/phy-fsl-lynx-28g.c | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/phy/freescale/phy-fsl-lynx-28g.c +9 -0

index 569f12af2aafa..9d55dbee2e0a5 100644
@@ -603,6 +603,14 @@ static int lynx_28g_probe(struct platform_device *pdev)
 	return PTR_ERR_OR_ZERO(provider);
 }
 
+static void lynx_28g_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct lynx_28g_priv *priv = dev_get_drvdata(dev);
+
+	cancel_delayed_work_sync(&priv->cdr_check);
+}
+
 static const struct of_device_id lynx_28g_of_match_table[] = {
 	{ .compatible = "fsl,lynx-28g" },
 	{ },

@@ -611,6 +619,7 @@ MODULE_DEVICE_TABLE(of, lynx_28g_of_match_table);
 
 static struct platform_driver lynx_28g_driver = {
 	.probe	= lynx_28g_probe,
+	.remove_new = lynx_28g_remove,
 	.driver	= {
 		.name = "lynx-28g",
 		.of_match_table = lynx_28g_of_match_table,

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #54 lore raw

PATCH 51/191 phy: lynx-28g: lock PHY while performing CDR lock workaround

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vladimir Oltean <[email protected]>

[ Upstream commit 0ac87fe54a171d18c5fb5345e3ee8d14e1b06f4b ]

lynx_28g_cdr_lock_check() runs once per second in a workqueue to reset the lane receiver if the CDR has not locked onto bit transitions in the RX stream. But the PHY consumer may do stuff with the PHY simultaneously, and that isn't okay. Block concurrent generic PHY calls by holding the PHY mutex from this workqueue.

Fixes 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G")

Signed-off-by Vladimir Oltean <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/phy/freescale/phy-fsl-lynx-28g.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

drivers/phy/freescale/phy-fsl-lynx-28g.c +6 -3

index 9d55dbee2e0a5..d49aa59c7d812 100644
@@ -507,11 +507,12 @@ static void lynx_28g_cdr_lock_check(struct work_struct *work)
 	for (i = 0; i < LYNX_28G_NUM_LANE; i++) {
 		lane = &priv->lane[i];
 
-		if (!lane->init)
-			continue;
+		mutex_lock(&lane->phy->mutex);
 
-		if (!lane->powered_up)
+		if (!lane->init || !lane->powered_up) {
+			mutex_unlock(&lane->phy->mutex);
 			continue;
+		}
 
 		rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
 		if (!(rrstctl & LYNX_28G_LNaRRSTCTL_CDR_LOCK)) {

@@ -520,6 +521,8 @@ static void lynx_28g_cdr_lock_check(struct work_struct *work)
 				rrstctl = lynx_28g_lane_read(lane, LNaRRSTCTL);
 			} while (!(rrstctl & LYNX_28G_LNaRRSTCTL_RST_DONE));
 		}
+
+		mutex_unlock(&lane->phy->mutex);
 	}
 	queue_delayed_work(system_power_efficient_wq, &priv->cdr_check,
 			   msecs_to_jiffies(1000));

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #55 lore raw

PATCH 52/191 phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vladimir Oltean <[email protected]>

[ Upstream commit 139ad1143151a07be93bf741d4ea7c89e59f89ce ]

The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking.

Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers.

Fixes 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G")

Signed-off-by Vladimir Oltean <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/phy/freescale/phy-fsl-lynx-28g.c | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/phy/freescale/phy-fsl-lynx-28g.c +9 -0

index d49aa59c7d812..0a8b40edc3f31 100644
@@ -126,6 +126,10 @@ struct lynx_28g_lane {
 struct lynx_28g_priv {
 	void __iomem *base;
 	struct device *dev;
+	/* Serialize concurrent access to registers shared between lanes,
+	 * like PCCn
+	 */
+	spinlock_t pcc_lock;
 	struct lynx_28g_pll pll[LYNX_28G_NUM_PLL];
 	struct lynx_28g_lane lane[LYNX_28G_NUM_LANE];

@@ -396,6 +400,8 @@ static int lynx_28g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
 	if (powered_up)
 		lynx_28g_power_off(phy);
 
+	spin_lock(&priv->pcc_lock);
+
 	switch (submode) {
 	case PHY_INTERFACE_MODE_SGMII:
 	case PHY_INTERFACE_MODE_1000BASEX:

@@ -412,6 +418,8 @@ static int lynx_28g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
 	lane->interface = submode;
 
 out:
+	spin_unlock(&priv->pcc_lock);
+
 	/* Power up the lane if necessary */
 	if (powered_up)
 		lynx_28g_power_on(phy);

@@ -595,6 +603,7 @@ static int lynx_28g_probe(struct platform_device *pdev)
 
 	dev_set_drvdata(dev, priv);
 
+	spin_lock_init(&priv->pcc_lock);
 	INIT_DELAYED_WORK(&priv->cdr_check, lynx_28g_cdr_lock_check);
 
 	queue_delayed_work(system_power_efficient_wq, &priv->cdr_check,

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #56 lore raw

PATCH 53/191 net: dsa: qca8k: fix regmap bulk read/write methods on big endian systems

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marek Behún <[email protected]>

[ Upstream commit 5652d1741574eb89cc02576e50ee3e348bd6dd77 ]

Commit c766e077d927 ("net: dsa: qca8k: convert to regmap read/write API") introduced bulk read/write methods to qca8k's regmap.

The regmap bulk read/write methods get the register address in a buffer passed as a void pointer parameter (the same buffer contains also the read/written values). The register address occupies only as many bytes as it requires at the beginning of this buffer. For example if the .reg_bits member in regmap_config is 16 (as is the case for this driver), the register address occupies only the first 2 bytes in this buffer, so it can be cast to u16.

But the original commit implementing these bulk read/write methods cast the buffer to u32:
u32 reg = *(u32 *)reg_buf & U16_MAX;
taking the first 4 bytes. This works on little endian systems where the first 2 bytes of the buffer correspond to the low 16-bits, but it obviously cannot work on big endian systems.

Fix this by casting the beginning of the buffer to u16 as
u32 reg = *(u16 *)reg_buf;

Fixes c766e077d927 ("net: dsa: qca8k: convert to regmap read/write API")

Signed-off-by Marek Behún <[email protected]>

Tested-by Christian Marangi <[email protected]>

Reviewed-by Christian Marangi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/dsa/qca/qca8k-8xxx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/dsa/qca/qca8k-8xxx.c +2 -2

index efe9380d4a15d..8e1574c63954e 100644
@@ -505,8 +505,8 @@ qca8k_bulk_read(void *ctx, const void *reg_buf, size_t reg_len,
 		void *val_buf, size_t val_len)
 {
 	int i, count = val_len / sizeof(u32), ret;
-	u32 reg = *(u32 *)reg_buf & U16_MAX;
 	struct qca8k_priv *priv = ctx;
+	u32 reg = *(u16 *)reg_buf;
 
 	if (priv->mgmt_master &&
 	    !qca8k_read_eth(priv, reg, val_buf, val_len))

@@ -527,8 +527,8 @@ qca8k_bulk_gather_write(void *ctx, const void *reg_buf, size_t reg_len,
 			const void *val_buf, size_t val_len)
 {
 	int i, count = val_len / sizeof(u32), ret;
-	u32 reg = *(u32 *)reg_buf & U16_MAX;
 	struct qca8k_priv *priv = ctx;
+	u32 reg = *(u16 *)reg_buf;
 	u32 *val = (u32 *)val_buf;
 
 	if (priv->mgmt_master &&

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:46 UTC #57 lore raw

PATCH 54/191 net: dsa: qca8k: fix potential MDIO bus conflict when accessing internal PHYs via management frames

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marek Behún <[email protected]>

[ Upstream commit 526c8ee04bdbd4d8d19a583b1f3b06700229a815 ]

Besides the QCA8337 switch the Turris 1.x device has on it's MDIO bus also Micron ethernet PHY (dedicated to the WAN port).

We've been experiencing a strange behavior of the WAN ethernet interface, wherein the WAN PHY started timing out the MDIO accesses, for example when the interface was brought down and then back up.

Bisecting led to commit 2cd548566384 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet"), which added support to access the QCA8337 switch's internal PHYs via management ethernet frames.

Connecting the MDIO bus pins onto an oscilloscope, I was able to see that the MDIO bus was active whenever a request to read/write an internal PHY register was done via an management ethernet frame.

My theory is that when the switch core always communicates with the internal PHYs via the MDIO bus, even when externally we request the access via ethernet. This MDIO bus is the same one via which the switch and internal PHYs are accessible to the board, and the board may have other devices connected on this bus. An ASCII illustration may give more insight:

           +---------+
      +----|         |
      |    | WAN PHY |
      | +--|         |
      | |  +---------+
      | |
      | |  +----------------------------------+
      | |  | QCA8337                          |
MDC   | |  |                        +-------+ |
------o-+--|--------o------------o--|       | |
MDIO    |  |        |            |  | PHY 1 |-|--to RJ45
--------o--|---o----+---------o--+--|       | |
           |   |    |         |  |  +-------+ |
	   | +-------------+  |  o--|       | |
	   | | MDIO MDC    |  |  |  | PHY 2 |-|--to RJ45
eth1	   | |             |  o--+--|       | |
-----------|-|port0        |  |  |  +-------+ |
           | |             |  |  o--|       | |
	   | | switch core |  |  |  | PHY 3 |-|--to RJ45
           | +-------------+  o--+--|       | |
	   |                  |  |  +-------+ |
	   |                  |  o--|  ...  | |
	   +----------------------------------+

When we send a request to read an internal PHY register via an ethernet management frame via eth1, the switch core receives the ethernet frame on port 0 and then communicates with the internal PHY via MDIO. At this time, other potential devices, such as the WAN PHY on Turris 1.x, cannot use the MDIO bus, since it may cause a bus conflict.

Fix this issue by locking the MDIO bus even when we are accessing the PHY registers via ethernet management frames.

Fixes 2cd548566384 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet")

Signed-off-by Marek Behún <[email protected]>

Reviewed-by Christian Marangi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/dsa/qca/qca8k-8xxx.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/net/dsa/qca/qca8k-8xxx.c +11 -0

index 8e1574c63954e..252089929eb92 100644
@@ -666,6 +666,15 @@ qca8k_phy_eth_command(struct qca8k_priv *priv, bool read, int phy,
 		goto err_read_skb;
 	}
 
+	/* It seems that accessing the switch's internal PHYs via management
+	 * packets still uses the MDIO bus within the switch internally, and
+	 * these accesses can conflict with external MDIO accesses to other
+	 * devices on the MDIO bus.
+	 * We therefore need to lock the MDIO bus onto which the switch is
+	 * connected.
+	 */
+	mutex_lock(&priv->bus->mdio_lock);
+
 	/* Actually start the request:
 	 * 1. Send mdio master packet
 	 * 2. Busy Wait for mdio master command

@@ -678,6 +687,7 @@ qca8k_phy_eth_command(struct qca8k_priv *priv, bool read, int phy,
 	mgmt_master = priv->mgmt_master;
 	if (!mgmt_master) {
 		mutex_unlock(&mgmt_eth_data->mutex);
+		mutex_unlock(&priv->bus->mdio_lock);
 		ret = -EINVAL;
 		goto err_mgmt_master;
 	}

@@ -765,6 +775,7 @@ qca8k_phy_eth_command(struct qca8k_priv *priv, bool read, int phy,
 				    QCA8K_ETHERNET_TIMEOUT);
 
 	mutex_unlock(&mgmt_eth_data->mutex);
+	mutex_unlock(&priv->bus->mdio_lock);
 
 	return ret;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #58 lore raw

PATCH 55/191 can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior

[1] https://lore.kernel.org/all/[email protected]

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lukas Magel <[email protected]>

[ Upstream commit d9c2ba65e651467de739324d978b04ed8729f483 ]

With patch [1], isotp_poll was updated to also queue the poller in the so->wait queue, which is used for send state changes. Since the queue now also contains polling tasks that are not interested in sending, the queue fill state can no longer be used as an indication of send readiness. As a consequence, nonblocking writes can lead to a race and lock-up of the socket if there is a second task polling the socket in parallel.

With this patch, isotp_sendmsg does not consult wq_has_sleepers but instead tries to atomically set so->tx.state and waits on so->wait if it is unable to do so. This behavior is in alignment with isotp_poll, which also checks so->tx.state to determine send readiness.

V2:
- Revert direct exit to goto err_event_drop

Reported-by Maxime Jayat <[email protected]>

Closes https://lore.kernel.org/linux-can/[email protected]/ open here

Signed-off-by Lukas Magel <[email protected]>

Reviewed-by Oliver Hartkopp <[email protected]>

Fixes 79e19fa79cb5 ("can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events")

Link https://github.com/pylessard/python-udsoncan/issues/178#issuecomment-1743786590

Link https://lore.kernel.org/all/[email protected] open here

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/can/isotp.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

net/can/isotp.c +8 ~~-11~~

index f02b5d3e47335..d1c6f206f4295 100644
@@ -948,21 +948,18 @@ static int isotp_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
 	if (!so->bound || so->tx.state == ISOTP_SHUTDOWN)
 		return -EADDRNOTAVAIL;
 
-wait_free_buffer:
-	/* we do not support multiple buffers - for now */
-	if (wq_has_sleeper(&so->wait) && (msg->msg_flags & MSG_DONTWAIT))
-		return -EAGAIN;
+	while (cmpxchg(&so->tx.state, ISOTP_IDLE, ISOTP_SENDING) != ISOTP_IDLE) {
+		/* we do not support multiple buffers - for now */
+		if (msg->msg_flags & MSG_DONTWAIT)
+			return -EAGAIN;
 
-	/* wait for complete transmission of current pdu */
-	err = wait_event_interruptible(so->wait, so->tx.state == ISOTP_IDLE);
-	if (err)
-		goto err_event_drop;
-
-	if (cmpxchg(&so->tx.state, ISOTP_IDLE, ISOTP_SENDING) != ISOTP_IDLE) {
 		if (so->tx.state == ISOTP_SHUTDOWN)
 			return -EADDRNOTAVAIL;
 
-		goto wait_free_buffer;
+		/* wait for complete transmission of current pdu */
+		err = wait_event_interruptible(so->wait, so->tx.state == ISOTP_IDLE);
+		if (err)
+			goto err_event_drop;
 	}
 
 	/* PDU size > default => try max_pdu_size */

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #59 lore raw

PATCH 56/191 can: sun4i_can: Only show Kconfig if ARCH_SUNXI is set

Closes https://lore.kernel.org/linux-sunxi/CAMuHMdV2m54UAH0X2dG7stEg=grFihrdsz4+o7=_DpBMhjTbkw@mail.gmail.com/ open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: John Watts <[email protected]>

[ Upstream commit 1f223208ebdef84f21c15e9958c005a93c871aa2 ]

When adding the RISCV option I didn't gate it behind ARCH_SUNXI. As a result this option shows up with Allwinner support isn't enabled. Fix that by requiring ARCH_SUNXI to be set if RISCV is set.

Fixes 8abb95250ae6 ("can: sun4i_can: Add support for the Allwinner D1")

Reported-by Geert Uytterhoeven <[email protected]>

Signed-off-by John Watts <[email protected]>

Link https://lore.kernel.org/all/[email protected] open here

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/can/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/can/Kconfig +1 -1

index e626de33e735d..716bba8cc2017 100644
@@ -185,7 +185,7 @@ config CAN_SLCAN
 
 config CAN_SUN4I
 	tristate "Allwinner A10 CAN controller"
-	depends on MACH_SUN4I || MACH_SUN7I || RISCV || COMPILE_TEST
+	depends on MACH_SUN4I || MACH_SUN7I || (RISCV && ARCH_SUNXI) || COMPILE_TEST
 	help
 	  Say Y here if you want to use CAN controller found on Allwinner
 	  A10/A20/D1 SoCs.

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #60 lore raw

PATCH 57/191 arm64: dts: mediatek: fix t-phy unit name

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eugen Hristev <[email protected]>

[ Upstream commit 963c3b0c47ec29b4c49c9f45965cd066f419d17f ]

dtbs_check throws a warning at t-phy nodes:
Warning (unit_address_vs_reg): /t-phy@1a243000: node has a unit name, but no reg or ranges property Warning (unit_address_vs_reg): /soc/t-phy@11c00000: node has a unit name, but no reg or ranges property

The ranges is empty thus removing the @1a243000, @11c00000 from the node name.

Fixes 6029cae696c8 ("arm64: dts: mediatek: mt7622: harmonize node names and compatibles")

Fixes 918aed7abd2d ("arm64: dts: mt7986: add pcie related device nodes")

Signed-off-by Eugen Hristev <[email protected]>

Reviewed-by AngeloGioacchino Del Regno <[email protected]>

Signed-off-by AngeloGioacchino Del Regno <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi  | 2 +-
 arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/arm64/boot/dts/mediatek/mt7622.dtsi +1 -1

index 36ef2dbe8add4..3ee9266fa8e98 100644
@@ -905,7 +905,7 @@ sata: sata@1a200000 {
 		status = "disabled";
 	};
 
-	sata_phy: t-phy@1a243000 {
+	sata_phy: t-phy {
 		compatible = "mediatek,mt7622-tphy",
 			     "mediatek,generic-tphy-v1";
 		#address-cells = <2>;

arch/arm64/boot/dts/mediatek/mt7986a.dtsi +1 -1

index 68539ea788dfc..24eda00e320d3 100644
@@ -434,7 +434,7 @@ pcie_intc: interrupt-controller {
 			};
 		};
 
-		pcie_phy: t-phy@11c00000 {
+		pcie_phy: t-phy {
 			compatible = "mediatek,mt7986-tphy",
 				     "mediatek,generic-tphy-v2";
 			#address-cells = <2>;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #61 lore raw

PATCH 58/191 arm64: dts: mediatek: mt8195: Set DSU PMU status to fail

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nícolas F. R. A. Prado <[email protected]>

[ Upstream commit d192615c307ec9f74cd0582880ece698533eb99b ]

The DSU PMU allows monitoring performance events in the DSU cluster, which is done by configuring and reading back values from the DSU PMU system registers. However, for write-access to be allowed by ELs lower than EL3, the EL3 firmware needs to update the setting on the ACTLR3_EL3 register, as it is disallowed by default.

That configuration is not done on the firmware used by the MT8195 SoC, as a consequence, booting a MT8195-based machine like mt8195-cherry-tomato-r2 with CONFIG_ARM_DSU_PMU enabled hangs the kernel just as it writes to the CLUSTERPMOVSCLR_EL1 register, since the instruction faults to EL3, and BL31 apparently just re-runs the instruction over and over.

Mark the DSU PMU node in the Devicetree with status "fail", as the machine doesn't have a suitable firmware to make use of it from the kernel, and allowing its driver to probe would hang the kernel.

Fixes 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")

Signed-off-by Nícolas F. R. A. Prado <[email protected]>

Reviewed-by AngeloGioacchino Del Regno <[email protected]>

Signed-off-by AngeloGioacchino Del Regno <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/boot/dts/mediatek/mt8195.dtsi | 1 +
 1 file changed, 1 insertion(+)

arch/arm64/boot/dts/mediatek/mt8195.dtsi +1 -0

index 4dbbf8fdab758..43011bc41da77 100644
@@ -313,6 +313,7 @@ dsu-pmu {
 		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>;
 		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
 		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+		status = "fail";
 	};
 
 	dmic_codec: dmic-codec {

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #62 lore raw

PATCH 59/191 devlink: Hold devlink lock on health reporter dump get

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Moshe Shemesh <[email protected]>

[ Upstream commit aba0e909dc20eceb1de985474af459f82e7b0b82 ]

Devlink health dump get callback should take devlink lock as any other devlink callback. Otherwise, since devlink_mutex was removed, this callback is not protected from a race of the reporter being destroyed while handling the callback.

Add devlink lock to the callback and to any call for devlink_health_do_dump(). This should be safe as non of the drivers dump callback implementation takes devlink lock.

As devlink lock is added to any callback of dump, the reporter dump_lock is now redundant and can be removed.

Fixes d3efc2a6a6d8 ("net: devlink: remove devlink_mutex")

Signed-off-by Moshe Shemesh <[email protected]>

Reviewed-by Jiri Pirko <[email protected]>

Reviewed-by Przemek Kitszel <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/devlink/health.c | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

net/devlink/health.c +16 ~~-14~~

index 194340a8bb863..8c6a2e5140d4d 100644
@@ -58,7 +58,6 @@ struct devlink_health_reporter {
 	struct devlink *devlink;
 	struct devlink_port *devlink_port;
 	struct devlink_fmsg *dump_fmsg;
-	struct mutex dump_lock; /* lock parallel read/write from dump buffers */
 	u64 graceful_period;
 	bool auto_recover;
 	bool auto_dump;

@@ -125,7 +124,6 @@ __devlink_health_reporter_create(struct devlink *devlink,
 	reporter->graceful_period = graceful_period;
 	reporter->auto_recover = !!ops->recover;
 	reporter->auto_dump = !!ops->dump;
-	mutex_init(&reporter->dump_lock);
 	return reporter;
 }

@@ -226,7 +224,6 @@ EXPORT_SYMBOL_GPL(devlink_health_reporter_create);
 static void
 devlink_health_reporter_free(struct devlink_health_reporter *reporter)
 {
-	mutex_destroy(&reporter->dump_lock);
 	if (reporter->dump_fmsg)
 		devlink_fmsg_free(reporter->dump_fmsg);
 	kfree(reporter);

@@ -609,10 +606,10 @@ int devlink_health_report(struct devlink_health_reporter *reporter,
 	}
 
 	if (reporter->auto_dump) {
-		mutex_lock(&reporter->dump_lock);
+		devl_lock(devlink);
 		/* store current dump of current error, for later analysis */
 		devlink_health_do_dump(reporter, priv_ctx, NULL);
-		mutex_unlock(&reporter->dump_lock);
+		devl_unlock(devlink);
 	}
 
 	if (!reporter->auto_recover)

@@ -1246,7 +1243,7 @@ int devlink_nl_cmd_health_reporter_diagnose_doit(struct sk_buff *skb,
 }
 
 static struct devlink_health_reporter *
-devlink_health_reporter_get_from_cb(struct netlink_callback *cb)
+devlink_health_reporter_get_from_cb_lock(struct netlink_callback *cb)
 {
 	const struct genl_dumpit_info *info = genl_dumpit_info(cb);
 	struct devlink_health_reporter *reporter;

@@ -1256,10 +1253,12 @@ devlink_health_reporter_get_from_cb(struct netlink_callback *cb)
 	devlink = devlink_get_from_attrs_lock(sock_net(cb->skb->sk), attrs);
 	if (IS_ERR(devlink))
 		return NULL;
-	devl_unlock(devlink);
 
 	reporter = devlink_health_reporter_get_from_attrs(devlink, attrs);
-	devlink_put(devlink);
+	if (!reporter) {
+		devl_unlock(devlink);
+		devlink_put(devlink);
+	}
 	return reporter;
 }

@@ -1268,16 +1267,20 @@ int devlink_nl_cmd_health_reporter_dump_get_dumpit(struct sk_buff *skb,
 {
 	struct devlink_nl_dump_state *state = devlink_dump_state(cb);
 	struct devlink_health_reporter *reporter;
+	struct devlink *devlink;
 	int err;
 
-	reporter = devlink_health_reporter_get_from_cb(cb);
+	reporter = devlink_health_reporter_get_from_cb_lock(cb);
 	if (!reporter)
 		return -EINVAL;
 
-	if (!reporter->ops->dump)
+	devlink = reporter->devlink;
+	if (!reporter->ops->dump) {
+		devl_unlock(devlink);
+		devlink_put(devlink);
 		return -EOPNOTSUPP;
+	}
 
-	mutex_lock(&reporter->dump_lock);
 	if (!state->idx) {
 		err = devlink_health_do_dump(reporter, NULL, cb->extack);
 		if (err)

@@ -1293,7 +1296,8 @@ int devlink_nl_cmd_health_reporter_dump_get_dumpit(struct sk_buff *skb,
 	err = devlink_fmsg_dumpit(reporter->dump_fmsg, skb, cb,
 				  DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET);
 unlock:
-	mutex_unlock(&reporter->dump_lock);
+	devl_unlock(devlink);
+	devlink_put(devlink);
 	return err;
 }

@@ -1310,9 +1314,7 @@ int devlink_nl_cmd_health_reporter_dump_clear_doit(struct sk_buff *skb,
 	if (!reporter->ops->dump)
 		return -EOPNOTSUPP;
 
-	mutex_lock(&reporter->dump_lock);
 	devlink_health_dump_clear(reporter);
-	mutex_unlock(&reporter->dump_lock);
 	return 0;
 }

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #63 lore raw

PATCH 60/191 ravb: Fix up dma_free_coherent() call in ravb_remove()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit e6864af61493113558c502b5cd0d754c19b93277 ]

In ravb_remove(), dma_free_coherent() should be call after unregister_netdev(). Otherwise, this controller is possible to use the freed buffer.

Fixes c156633f1353 ("Renesas Ethernet AVB driver proper")

Signed-off-by Yoshihiro Shimoda <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/renesas/ravb_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/renesas/ravb_main.c +2 -2

index 4d6b3b7d6abb3..49726183d264b 100644
@@ -2892,8 +2892,6 @@ static int ravb_remove(struct platform_device *pdev)
 	clk_disable_unprepare(priv->gptp_clk);
 	clk_disable_unprepare(priv->refclk);
 
-	dma_free_coherent(ndev->dev.parent, priv->desc_bat_size, priv->desc_bat,
-			  priv->desc_bat_dma);
 	/* Set reset mode */
 	ravb_write(ndev, CCC_OPC_RESET, CCC);
 	unregister_netdev(ndev);

@@ -2901,6 +2899,8 @@ static int ravb_remove(struct platform_device *pdev)
 		netif_napi_del(&priv->napi[RAVB_NC]);
 	netif_napi_del(&priv->napi[RAVB_BE]);
 	ravb_mdio_release(priv);
+	dma_free_coherent(ndev->dev.parent, priv->desc_bat_size, priv->desc_bat,
+			  priv->desc_bat_dma);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	reset_control_assert(priv->rstc);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #64 lore raw

PATCH 61/191 ravb: Fix use-after-free issue in ravb_tx_timeout_work()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit 3971442870713de527684398416970cf025b4f89 ]

The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below:

CPU0 CPU1
ravb_tx_timeout()
ravb_remove()
unregister_netdev()
free_netdev(ndev)
// free priv

			ravb_tx_timeout_work()
			// use priv

unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop().

Fixes c156633f1353 ("Renesas Ethernet AVB driver proper")

Reported-by Zheng Wang <[email protected]>

Closes https://lore.kernel.org/netdev/[email protected]/ open here

Signed-off-by Yoshihiro Shimoda <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/renesas/ravb_main.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/net/ethernet/renesas/ravb_main.c +2 -0

index 49726183d264b..ef8f205f8ce1f 100644
@@ -2168,6 +2168,8 @@ static int ravb_close(struct net_device *ndev)
 			of_phy_deregister_fixed_link(np);
 	}
 
+	cancel_work_sync(&priv->work);
+
 	if (info->multi_irqs) {
 		free_irq(priv->tx_irqs[RAVB_NC], ndev);
 		free_irq(priv->rx_irqs[RAVB_NC], ndev);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #65 lore raw

PATCH 62/191 ieee802154: ca8210: Fix a potential UAF in ca8210_probe

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dinghao Liu <[email protected]>

[ Upstream commit f990874b1c98fe8e57ee9385669f501822979258 ]

If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister().

Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().

Fixes ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")

Signed-off-by Dinghao Liu <[email protected]>

Message-ID: <[email protected]>

Signed-off-by Stefan Schmidt <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ieee802154/ca8210.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

drivers/net/ieee802154/ca8210.c +3 ~~-14~~

index f9b10e84de067..9cb99dc65db34 100644
@@ -2741,7 +2741,6 @@ static int ca8210_register_ext_clock(struct spi_device *spi)
 	struct device_node *np = spi->dev.of_node;
 	struct ca8210_priv *priv = spi_get_drvdata(spi);
 	struct ca8210_platform_data *pdata = spi->dev.platform_data;
-	int ret = 0;
 
 	if (!np)
 		return -EFAULT;

@@ -2758,18 +2757,8 @@ static int ca8210_register_ext_clock(struct spi_device *spi)
 		dev_crit(&spi->dev, "Failed to register external clk\n");
 		return PTR_ERR(priv->clk);
 	}
-	ret = of_clk_add_provider(np, of_clk_src_simple_get, priv->clk);
-	if (ret) {
-		clk_unregister(priv->clk);
-		dev_crit(
-			&spi->dev,
-			"Failed to register external clock as clock provider\n"
-		);
-	} else {
-		dev_info(&spi->dev, "External clock set as clock provider\n");
-	}
 
-	return ret;
+	return of_clk_add_provider(np, of_clk_src_simple_get, priv->clk);
 }
 
 /**

@@ -2781,8 +2770,8 @@ static void ca8210_unregister_ext_clock(struct spi_device *spi)
 {
 	struct ca8210_priv *priv = spi_get_drvdata(spi);
 
-	if (!priv->clk)
-		return
+	if (IS_ERR_OR_NULL(priv->clk))
+		return;
 
 	of_clk_del_provider(spi->dev.of_node);
 	clk_unregister(priv->clk);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #66 lore raw

PATCH 63/191 mlxsw: fix mlxsw_sp2_nve_vxlan_learning_set() return type

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit 1e0b72a2a6432c0ef67ee5ce8d9172a7c20bba25 ]

The mlxsw_sp2_nve_vxlan_learning_set() function is supposed to return zero on success or negative error codes. So it needs to be type int instead of bool.

Fixes 4ee70efab68d ("mlxsw: spectrum_nve: Add support for VXLAN on Spectrum-2")

Reviewed-by Petr Machata <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_nve_vxlan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/mellanox/mlxsw/spectrum_nve_vxlan.c +2 -2

index bb8eeb86edf75..52c2fe3644d4b 100644
@@ -310,8 +310,8 @@ const struct mlxsw_sp_nve_ops mlxsw_sp1_nve_vxlan_ops = {
 	.fdb_clear_offload = mlxsw_sp_nve_vxlan_clear_offload,
 };
 
-static bool mlxsw_sp2_nve_vxlan_learning_set(struct mlxsw_sp *mlxsw_sp,
-					     bool learning_en)
+static int mlxsw_sp2_nve_vxlan_learning_set(struct mlxsw_sp *mlxsw_sp,
+					    bool learning_en)
 {
 	char tnpc_pl[MLXSW_REG_TNPC_LEN];

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #67 lore raw

PATCH 64/191 xen-netback: use default TX queue size for vifs

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Roger Pau Monne <[email protected]>

[ Upstream commit 66cf7435a26917c0c4d6245ad9137e7606e84fdf ]

Do not set netback interfaces (vifs) default TX queue size to the ring size. The TX queue size is not related to the ring size, and using the ring size (32) as the queue size can lead to packet drops. Note the TX side of the vif interface in the netback domain is the one receiving packets to be injected to the guest.

Do not explicitly set the TX queue length to any value when creating the interface, and instead use the system default. Note that the queue length can also be adjusted at runtime.

Fixes f942dc2552b8 ('xen network backend driver')

Signed-off-by Roger Pau Monné <[email protected]>

Reviewed-by Ross Lagerwall <[email protected]>

Acked-by Wei Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/xen-netback/interface.c | 4 ----
 1 file changed, 4 deletions(-)

drivers/net/xen-netback/interface.c +0 -4

index f3f2c07423a6a..fc3bb63b9ac3e 100644
@@ -41,8 +41,6 @@
 #include <asm/xen/hypercall.h>
 #include <xen/balloon.h>
 
-#define XENVIF_QUEUE_LENGTH 32
-
 /* Number of bytes allowed on the internal guest Rx queue. */
 #define XENVIF_RX_QUEUE_BYTES (XEN_NETIF_RX_RING_SIZE/2 * PAGE_SIZE)

@@ -530,8 +528,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	dev->features = dev->hw_features | NETIF_F_RXCSUM;
 	dev->ethtool_ops = &xenvif_ethtool_ops;
 
-	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
-
 	dev->min_mtu = ETH_MIN_MTU;
 	dev->max_mtu = ETH_MAX_MTU - VLAN_ETH_HLEN;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #68 lore raw

PATCH 65/191 riscv, bpf: Sign-extend return values

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Björn Töpel <[email protected]>

[ Upstream commit 2f1b0d3d733169eb11680bfa97c266ae5e757148 ]

The RISC-V architecture does not expose sub-registers, and hold all 32-bit values in a sign-extended format [1] [2]:

  | The compiler and calling convention maintain an invariant that all
  | 32-bit values are held in a sign-extended format in 64-bit
  | registers. Even 32-bit unsigned integers extend bit 31 into bits
  | 63 through 32. Consequently, conversion between unsigned and
  | signed 32-bit integers is a no-op, as is conversion from a signed
  | 32-bit integer to a signed 64-bit integer.

While BPF, on the other hand, exposes sub-registers, and use zero-extension (similar to arm64/x86).

This has led to some subtle bugs, where a BPF JITted program has not sign-extended the a0 register (return value in RISC-V land), passed the return value up the kernel, e.g.:

  | int from_bpf(void);
  |
  | long foo(void)
  | {
  |    return from_bpf();
  | }

Here, a0 would be 0xffff_ffff, instead of the expected 0xffff_ffff_ffff_ffff.

Internally, the RISC-V JIT uses a5 as a dedicated register for BPF return values.

Keep a5 zero-extended, but explicitly sign-extend a0 (which is used outside BPF land). Now that a0 (RISC-V ABI) and a5 (BPF ABI) differs, a0 is only moved to a5 for non-BPF native calls (BPF_PSEUDO_CALL).

Fixes 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G")

Signed-off-by Björn Töpel <[email protected]>

Link https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf # [2]

Link https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/draft-20230929-e5c800e661a53efe3c2678d71a306323b60eb13b/riscv-abi.pdf # [2]

Link https://lore.kernel.org/bpf/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/riscv/net/bpf_jit_comp64.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

arch/riscv/net/bpf_jit_comp64.c +3 -2

index c648864c8cd1a..3a3631bae05c1 100644
@@ -239,7 +239,7 @@ static void __build_epilogue(bool is_tail_call, struct rv_jit_context *ctx)
 	emit_addi(RV_REG_SP, RV_REG_SP, stack_adjust, ctx);
 	/* Set return value. */
 	if (!is_tail_call)
-		emit_mv(RV_REG_A0, RV_REG_A5, ctx);
+		emit_addiw(RV_REG_A0, RV_REG_A5, 0, ctx);
 	emit_jalr(RV_REG_ZERO, is_tail_call ? RV_REG_T3 : RV_REG_RA,
 		  is_tail_call ? 20 : 0, /* skip reserved nops and TCC init */
 		  ctx);

@@ -1436,7 +1436,8 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
 		if (ret)
 			return ret;
 
-		emit_mv(bpf_to_rv_reg(BPF_REG_0, ctx), RV_REG_A0, ctx);
+		if (insn->src_reg != BPF_PSEUDO_CALL)
+			emit_mv(bpf_to_rv_reg(BPF_REG_0, ctx), RV_REG_A0, ctx);
 		break;
 	}
 	/* tail call */

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #69 lore raw

PATCH 66/191 riscv, bpf: Track both a0 (RISC-V ABI) and a5 (BPF) return values

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Björn Töpel <[email protected]>

[ Upstream commit 7112cd26e606c7ba51f9cc5c1905f06039f6f379 ]

The RISC-V BPF uses a5 for BPF return values, which are zero-extended, whereas the RISC-V ABI uses a0 which is sign-extended. In other words, a5 and a0 can differ, and are used in different context.

The BPF trampoline are used for both BPF programs, and regular kernel functions.

Make sure that the RISC-V BPF trampoline saves, and restores both a0 and a5.

Fixes 49b5e77ae3e2 ("riscv, bpf: Add bpf trampoline support for RV64")

Signed-off-by Björn Töpel <[email protected]>

Link https://lore.kernel.org/bpf/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/riscv/net/bpf_jit_comp64.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

arch/riscv/net/bpf_jit_comp64.c +9 -4

index 3a3631bae05c1..3b4cb713e3684 100644
@@ -757,8 +757,10 @@ static int invoke_bpf_prog(struct bpf_tramp_link *l, int args_off, int retval_of
 	if (ret)
 		return ret;
 
-	if (save_ret)
-		emit_sd(RV_REG_FP, -retval_off, regmap[BPF_REG_0], ctx);
+	if (save_ret) {
+		emit_sd(RV_REG_FP, -retval_off, RV_REG_A0, ctx);
+		emit_sd(RV_REG_FP, -(retval_off - 8), regmap[BPF_REG_0], ctx);
+	}
 
 	/* update branch with beqz */
 	if (ctx->insns) {

@@ -844,7 +846,7 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 
 	save_ret = flags & (BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_RET_FENTRY_RET);
 	if (save_ret) {
-		stack_size += 8;
+		stack_size += 16; /* Save both A5 (BPF R0) and A0 */
 		retval_off = stack_size;
 	}

@@ -931,6 +933,7 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 		if (ret)
 			goto out;
 		emit_sd(RV_REG_FP, -retval_off, RV_REG_A0, ctx);
+		emit_sd(RV_REG_FP, -(retval_off - 8), regmap[BPF_REG_0], ctx);
 		im->ip_after_call = ctx->insns + ctx->ninsns;
 		/* 2 nops reserved for auipc+jalr pair */
 		emit(rv_nop(), ctx);

@@ -962,8 +965,10 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 	if (flags & BPF_TRAMP_F_RESTORE_REGS)
 		restore_args(nregs, args_off, ctx);
 
-	if (save_ret)
+	if (save_ret) {
 		emit_ld(RV_REG_A0, -retval_off, RV_REG_FP, ctx);
+		emit_ld(regmap[BPF_REG_0], -(retval_off - 8), RV_REG_FP, ctx);
+	}
 
 	emit_ld(RV_REG_S1, -sreg_off, RV_REG_FP, ctx);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #70 lore raw

PATCH 67/191 xdp: Fix zero-size allocation warning in xskq_create()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andrew Kanner <[email protected]>

[ Upstream commit a12bbb3cccf03b12847de0f7a6772127f90936ac ]

Syzkaller reported the following issue:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 2807 at mm/vmalloc.c:3247 __vmalloc_node_range (mm/vmalloc.c:3361)
  Modules linked in:
  CPU: 0 PID: 2807 Comm: repro Not tainted 6.6.0-rc2+ #12
  Hardware name: Generic DT based system
  unwind_backtrace from show_stack (arch/arm/kernel/traps.c:258)
  show_stack from dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
  dump_stack_lvl from __warn (kernel/panic.c:633 kernel/panic.c:680)
  __warn from warn_slowpath_fmt (./include/linux/context_tracking.h:153 kernel/panic.c:700)
  warn_slowpath_fmt from __vmalloc_node_range (mm/vmalloc.c:3361 (discriminator 3))
  __vmalloc_node_range from vmalloc_user (mm/vmalloc.c:3478)
  vmalloc_user from xskq_create (net/xdp/xsk_queue.c:40)
  xskq_create from xsk_setsockopt (net/xdp/xsk.c:953 net/xdp/xsk.c:1286)
  xsk_setsockopt from __sys_setsockopt (net/socket.c:2308)
  __sys_setsockopt from ret_fast_syscall (arch/arm/kernel/entry-common.S:68)

xskq_get_ring_size() uses struct_size() macro to safely calculate the size of struct xsk_queue and q->nentries of desc members. But the syzkaller repro was able to set q->nentries with the value initially taken from copy_from_sockptr() high enough to return SIZE_MAX by struct_size(). The next PAGE_ALIGN(size) is such case will overflow the size_t value and set it to 0. This will trigger WARN_ON_ONCE in vmalloc_user() -> __vmalloc_node_range().

The issue is reproducible on 32-bit arm kernel.

Fixes 9f78bf330a66 ("xsk: support use vaddr as ring")

Reported-by [email protected]

Closes https://lore.kernel.org/all/[email protected]/T/ open here

Reported-by [email protected]

Closes https://lore.kernel.org/all/[email protected]/T/ open here

Signed-off-by Andrew Kanner <[email protected]>

Link https://syzkaller.appspot.com/bug?extid=fae676d3cf469331fc89

Tested-by [email protected]

Acked-by Magnus Karlsson <[email protected]>

Link https://lore.kernel.org/bpf/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/xdp/xsk_queue.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

net/xdp/xsk_queue.c +10 -0

index f8905400ee07a..d2c2640300171 100644
@@ -34,6 +34,16 @@ struct xsk_queue *xskq_create(u32 nentries, bool umem_queue)
 	q->ring_mask = nentries - 1;
 
 	size = xskq_get_ring_size(q, umem_queue);
+
+	/* size which is overflowing or close to SIZE_MAX will become 0 in
+	 * PAGE_ALIGN(), checking SIZE_MAX is enough due to the previous
+	 * is_power_of_2(), the rest will be handled by vmalloc_user()
+	 */
+	if (unlikely(size == SIZE_MAX)) {
+		kfree(q);
+		return NULL;
+	}
+
 	size = PAGE_ALIGN(size);
 
 	q->ring = vmalloc_user(size);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #71 lore raw

PATCH 68/191 drm/vmwgfx: fix typo of sizeof argument

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Konstantin Meskhidze <[email protected]>

[ Upstream commit 39465cac283702a7d4a507a558db81898029c6d3 ]

Since size of 'header' pointer and '*header' structure is equal on 64-bit machines issue probably didn't cause any wrong behavior. But anyway, fixing typo is required.

Fixes 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.")

Co-developed-by Ivanov Mikhail <[email protected]>

Signed-off-by Konstantin Meskhidze <[email protected]>

Reviewed-by Zack Rusin <[email protected]>

Signed-off-by Zack Rusin <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +1 -1

index 98e0723ca6f5e..cc3f301ca1639 100644
@@ -1619,7 +1619,7 @@ static int vmw_cmd_tex_state(struct vmw_private *dev_priv,
 {
 	VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdSetTextureState);
 	SVGA3dTextureState *last_state = (SVGA3dTextureState *)
-	  ((unsigned long) header + header->size + sizeof(header));
+	  ((unsigned long) header + header->size + sizeof(*header));
 	SVGA3dTextureState *cur_state = (SVGA3dTextureState *)
 		((unsigned long) header + sizeof(*cmd));
 	struct vmw_resource *ctx;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #72 lore raw

PATCH 69/191 bpf: Fix verifier log for async callback return values

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Vernet <[email protected]>

[ Upstream commit 829955981c557c7fc7416581c4cd68a8a0c28620 ]

The verifier, as part of check_return_code(), verifies that async callbacks such as from e.g. timers, will return 0. It does this by correctly checking that R0->var_off is in tnum_const(0), which effectively checks that it's in a range of 0. If this condition fails, however, it prints an error message which says that the value should have been in (0x0; 0x1). This results in possibly confusing output such as the following in which an async callback returns 1:

At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x1)

The fix is easy -- we should just pass the tnum_const(0) as the correct range to verbose_invalid_scalar(), which will then print the following:

At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x0)

Fixes bfc6bb74e4f1 ("bpf: Implement verifier support for validation of async callbacks.")

Signed-off-by David Vernet <[email protected]>

Link https://lore.kernel.org/bpf/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 kernel/bpf/verifier.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

kernel/bpf/verifier.c +3 -3

index 93fd32f2957b7..104681258d24f 100644
@@ -14255,7 +14255,7 @@ static int check_return_code(struct bpf_verifier_env *env)
 	struct tnum enforce_attach_type_range = tnum_unknown;
 	const struct bpf_prog *prog = env->prog;
 	struct bpf_reg_state *reg;
-	struct tnum range = tnum_range(0, 1);
+	struct tnum range = tnum_range(0, 1), const_0 = tnum_const(0);
 	enum bpf_prog_type prog_type = resolve_prog_type(env->prog);
 	int err;
 	struct bpf_func_state *frame = env->cur_state->frame[0];

@@ -14303,8 +14303,8 @@ static int check_return_code(struct bpf_verifier_env *env)
 			return -EINVAL;
 		}
 
-		if (!tnum_in(tnum_const(0), reg->var_off)) {
-			verbose_invalid_scalar(env, reg, &range, "async callback", "R0");
+		if (!tnum_in(const_0, reg->var_off)) {
+			verbose_invalid_scalar(env, reg, &const_0, "async callback", "R0");
 			return -EINVAL;
 		}
 		return 0;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:47 UTC #73 lore raw

PATCH 70/191 net: refine debug info in skb_checksum_help()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

[ Upstream commit 26c29961b142444cd99361644c30fa1e9b3da6be ]

syzbot uses panic_on_warn.

This means that the skb_dump() I added in the blamed commit are not even called.

Rewrite this so that we get the needed skb dump before syzbot crashes.

Fixes eeee4b77dc52 ("net: add more debug info in skb_checksum_help()")

Signed-off-by Eric Dumazet <[email protected]>

Reported-by Willem de Bruijn <[email protected]>

Reviewed-by Willem de Bruijn <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/core/dev.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

net/core/dev.c +6 -2

index 69a3e544676c4..968be1c20ca1f 100644
@@ -3285,15 +3285,19 @@ int skb_checksum_help(struct sk_buff *skb)
 
 	offset = skb_checksum_start_offset(skb);
 	ret = -EINVAL;
-	if (WARN_ON_ONCE(offset >= skb_headlen(skb))) {
+	if (unlikely(offset >= skb_headlen(skb))) {
 		DO_ONCE_LITE(skb_dump, KERN_ERR, skb, false);
+		WARN_ONCE(true, "offset (%d) >= skb_headlen() (%u)\n",
+			  offset, skb_headlen(skb));
 		goto out;
 	}
 	csum = skb_checksum(skb, offset, skb->len - offset, 0);
 
 	offset += skb->csum_offset;
-	if (WARN_ON_ONCE(offset + sizeof(__sum16) > skb_headlen(skb))) {
+	if (unlikely(offset + sizeof(__sum16) > skb_headlen(skb))) {
 		DO_ONCE_LITE(skb_dump, KERN_ERR, skb, false);
+		WARN_ONCE(true, "offset+2 (%zu) > skb_headlen() (%u)\n",
+			  offset + sizeof(__sum16), skb_headlen(skb));
 		goto out;
 	}
 	ret = skb_ensure_writable(skb, offset + sizeof(__sum16));

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #74 lore raw

PATCH 71/191 octeontx2-pf: mcs: update PN only when update_pn is true

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Radu Pirea (NXP OSS) <[email protected]>

[ Upstream commit 4dcf38ae3ca16b8872f151d46ba5ac28dd580b60 ]

When updating SA, update the PN only when the update_pn flag is true. Otherwise, the PN will be reset to its previous value using the following command and this should not happen:

$ ip macsec set macsec0 tx sa 0 on

Fixes c54ffc73601c ("octeontx2-pf: mcs: Introduce MACSEC hardware offloading")

Signed-off-by Radu Pirea (NXP OSS) <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 .../ethernet/marvell/octeontx2/nic/cn10k_macsec.c   | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

drivers/net/ethernet/marvell/octeontx2/nic/cn10k_macsec.c +9 -4

index 59b138214af2f..6cc7a78968fc1 100644
@@ -1357,10 +1357,12 @@ static int cn10k_mdo_upd_txsa(struct macsec_context *ctx)
 
 	if (netif_running(secy->netdev)) {
 		/* Keys cannot be changed after creation */
-		err = cn10k_write_tx_sa_pn(pfvf, txsc, sa_num,
-					   sw_tx_sa->next_pn);
-		if (err)
-			return err;
+		if (ctx->sa.update_pn) {
+			err = cn10k_write_tx_sa_pn(pfvf, txsc, sa_num,
+						   sw_tx_sa->next_pn);
+			if (err)
+				return err;
+		}
 
 		err = cn10k_mcs_link_tx_sa2sc(pfvf, secy, txsc,
 					      sa_num, sw_tx_sa->active);

@@ -1529,6 +1531,9 @@ static int cn10k_mdo_upd_rxsa(struct macsec_context *ctx)
 		if (err)
 			return err;
 
+		if (!ctx->sa.update_pn)
+			return 0;
+
 		err = cn10k_mcs_write_rx_sa_pn(pfvf, rxsc, sa_num,
 					       rx_sa->next_pn);
 		if (err)

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #75 lore raw

PATCH 72/191 net: macsec: indicate next pn update when offloading

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Radu Pirea (NXP OSS) <[email protected]>

[ Upstream commit 0412cc846a1ef38697c3f321f9b174da91ecd3b5 ]

Indicate next PN update using update_pn flag in macsec_context. Offloaded MACsec implementations does not know whether or not the MACSEC_SA_ATTR_PN attribute was passed for an SA update and assume that next PN should always updated, but this is not always true.

The PN can be reset to its initial value using the following command:

$ ip macsec set macsec0 tx sa 0 off #octeontx2-pf case

Or, the update PN command will succeed even if the driver does not support PN updates.

$ ip macsec set macsec0 tx sa 0 pn 1 on #mscc phy driver case

Comparing the initial PN with the new PN value is not a solution. When the user updates the PN using its initial value the command will succeed, even if the driver does not support it. Like this:

$ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \
ead3664f508eb06c40ac7104cdae4ce5
$ ip macsec set macsec0 tx sa 0 pn 1 on #mlx5 case

Signed-off-by Radu Pirea (NXP OSS) <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Stable-dep-of: e0a8c918daa5 ("net: phy: mscc: macsec: reject PN update requests")

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/macsec.c | 2 ++
 include/net/macsec.h | 1 +
 2 files changed, 3 insertions(+)

drivers/net/macsec.c +2 -0

index 2d64650f4eb3c..1c60548c1ddde 100644
@@ -2394,6 +2394,7 @@ static int macsec_upd_txsa(struct sk_buff *skb, struct genl_info *info)
 
 		ctx.sa.assoc_num = assoc_num;
 		ctx.sa.tx_sa = tx_sa;
+		ctx.sa.update_pn = !!prev_pn.full64;
 		ctx.secy = secy;
 
 		ret = macsec_offload(ops->mdo_upd_txsa, &ctx);

@@ -2487,6 +2488,7 @@ static int macsec_upd_rxsa(struct sk_buff *skb, struct genl_info *info)
 
 		ctx.sa.assoc_num = assoc_num;
 		ctx.sa.rx_sa = rx_sa;
+		ctx.sa.update_pn = !!prev_pn.full64;
 		ctx.secy = secy;
 
 		ret = macsec_offload(ops->mdo_upd_rxsa, &ctx);

include/net/macsec.h +1 -0

index 441ed8fd4b5f6..41c1884a3e419 100644
@@ -258,6 +258,7 @@ struct macsec_context {
 	struct macsec_secy *secy;
 	struct macsec_rx_sc *rx_sc;
 	struct {
+		bool update_pn;
 		unsigned char assoc_num;
 		u8 key[MACSEC_MAX_KEY_LEN];
 		union {

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #76 lore raw

PATCH 73/191 net: phy: mscc: macsec: reject PN update requests

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Radu Pirea (NXP OSS) <[email protected]>

[ Upstream commit e0a8c918daa58700609ebd45e3fcd49965be8bbc ]

Updating the PN is not supported.
Return -EINVAL if update_pn is true.

The following command succeeded, but it should fail because the driver does not update the PN:
ip macsec set macsec0 tx sa 0 pn 232 on

Fixes 28c5107aa904 ("net: phy: mscc: macsec support")

Signed-off-by Radu Pirea (NXP OSS) <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/phy/mscc/mscc_macsec.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/net/phy/mscc/mscc_macsec.c +6 -0

index 018253a573b88..4f39ba63a9a91 100644
@@ -849,6 +849,9 @@ static int vsc8584_macsec_upd_rxsa(struct macsec_context *ctx)
 	struct macsec_flow *flow;
 	int ret;
 
+	if (ctx->sa.update_pn)
+		return -EINVAL;
+
 	flow = vsc8584_macsec_find_flow(ctx, MACSEC_INGR);
 	if (IS_ERR(flow))
 		return PTR_ERR(flow);

@@ -900,6 +903,9 @@ static int vsc8584_macsec_upd_txsa(struct macsec_context *ctx)
 	struct macsec_flow *flow;
 	int ret;
 
+	if (ctx->sa.update_pn)
+		return -EINVAL;
+
 	flow = vsc8584_macsec_find_flow(ctx, MACSEC_EGR);
 	if (IS_ERR(flow))
 		return PTR_ERR(flow);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #77 lore raw

PATCH 74/191 net/mlx5e: macsec: use update_pn flag instead of PN comparation

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Radu Pirea (NXP OSS) <[email protected]>

[ Upstream commit fde2f2d7f23d39f2fc699ba6d91ac3f4a2e637ca ]

When updating the SA, use the new update_pn flags instead of comparing the new PN with the initial one.

Comparing the initial PN value with the new value will allow the user to update the SA using the initial PN value as a parameter like this:

$ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \
ead3664f508eb06c40ac7104cdae4ce5
$ ip macsec set macsec0 tx sa 0 pn 1 off

Fixes 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support")

Fixes aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support")

Signed-off-by Radu Pirea (NXP OSS) <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c +2 -2

index 592b165530ffa..6bce55978aa72 100644
@@ -612,7 +612,7 @@ static int mlx5e_macsec_upd_txsa(struct macsec_context *ctx)
 		goto out;
 	}
 
-	if (tx_sa->next_pn != ctx_tx_sa->next_pn_halves.lower) {
+	if (ctx->sa.update_pn) {
 		netdev_err(netdev, "MACsec offload: update TX sa %d PN isn't supported\n",
 			   assoc_num);
 		err = -EINVAL;

@@ -1017,7 +1017,7 @@ static int mlx5e_macsec_upd_rxsa(struct macsec_context *ctx)
 		goto out;
 	}
 
-	if (rx_sa->next_pn != ctx_rx_sa->next_pn_halves.lower) {
+	if (ctx->sa.update_pn) {
 		netdev_err(ctx->netdev,
 			   "MACsec offload update RX sa %d PN isn't supported\n",
 			   assoc_num);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #78 lore raw

PATCH 75/191 drm/panel: boe-tv101wum-nl6: Completely pull GPW to VGL before TP term

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ruihai Zhou <[email protected]>

[ Upstream commit 258dd5e6e65995ee85a941eed9a06708a36b1bfe ]

The sta_himax83102 panel sometimes shows abnormally flickering horizontal lines. The front gate output will precharge the X point of the next pole circuit before TP(TouchPanel Enable) term starts, and wait until the end of the TP term to resume the CLK. For this reason, the X point must be maintained during the TP term. In abnormal case, we measured a slight leakage at point X. This because during the TP term, the GPW does not fully pull the VGL low, causing the TFT to not be closed tightly.

To fix this, we completely pull GPW to VGL before entering the TP term. This will ensure that the TFT is closed tightly and prevent the abnormal display.

Fixes 1bc2ef065f13 ("drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel")

Signed-off-by Ruihai Zhou <[email protected]>

Reviewed-by Neil Armstrong <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Neil Armstrong <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c +1 -3

index dc276c346fd1a..dcc5e79cfe879 100644
@@ -1343,9 +1343,7 @@ static const struct panel_init_cmd starry_himax83102_j02_init_cmd[] = {
 	_INIT_DCS_CMD(0xB1, 0x01, 0xBF, 0x11),
 	_INIT_DCS_CMD(0xCB, 0x86),
 	_INIT_DCS_CMD(0xD2, 0x3C, 0xFA),
-	_INIT_DCS_CMD(0xE9, 0xC5),
-	_INIT_DCS_CMD(0xD3, 0x00, 0x00, 0x00, 0x00, 0x80, 0x0C, 0x01),
-	_INIT_DCS_CMD(0xE9, 0x3F),
+	_INIT_DCS_CMD(0xD3, 0x00, 0x00, 0x44, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x0C, 0x01),
 	_INIT_DCS_CMD(0xE7, 0x02, 0x00, 0x28, 0x01, 0x7E, 0x0F, 0x7E, 0x10, 0xA0, 0x00, 0x00, 0x20, 0x40, 0x50, 0x40),
 	_INIT_DCS_CMD(0xBD, 0x02),
 	_INIT_DCS_CMD(0xD8, 0xFF, 0xFF, 0xBF, 0xFE, 0xAA, 0xA0, 0xFF, 0xFF, 0xBF, 0xFE, 0xAA, 0xA0),

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #79 lore raw

PATCH 76/191 ixgbe: fix crash with empty VF macvlan list

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit 7b5add9af567c44e12196107f0fe106e194034fd ]

The adapter->vf_mvs.l list needs to be initialized even if the list is empty. Otherwise it will lead to crashes.

Fixes a1cbb15c1397 ("ixgbe: Add macvlan support for VF")

Link https://lore.kernel.org/r/ZSADNdIw8zFx1xw2@kadam open here

Reviewed-by Jesse Brandeburg <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c +3 -2

index 29cc609880712..ea88ac04ab9ad 100644
@@ -28,6 +28,9 @@ static inline void ixgbe_alloc_vf_macvlans(struct ixgbe_adapter *adapter,
 	struct vf_macvlans *mv_list;
 	int num_vf_macvlans, i;
 
+	/* Initialize list of VF macvlans */
+	INIT_LIST_HEAD(&adapter->vf_mvs.l);
+
 	num_vf_macvlans = hw->mac.num_rar_entries -
 			  (IXGBE_MAX_PF_MACVLANS + 1 + num_vfs);
 	if (!num_vf_macvlans)

@@ -36,8 +39,6 @@ static inline void ixgbe_alloc_vf_macvlans(struct ixgbe_adapter *adapter,
 	mv_list = kcalloc(num_vf_macvlans, sizeof(struct vf_macvlans),
 			  GFP_KERNEL);
 	if (mv_list) {
-		/* Initialize list of VF macvlans */
-		INIT_LIST_HEAD(&adapter->vf_mvs.l);
 		for (i = 0; i < num_vf_macvlans; i++) {
 			mv_list[i].vf = -1;
 			mv_list[i].free = true;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #80 lore raw

PATCH 77/191 net/smc: Fix dependency of SMC on ISM

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gerd Bayer <[email protected]>

[ Upstream commit a72178cfe855c283224f393d94a1332b90d1483e ]

When the SMC protocol is built into the kernel proper while ISM is configured to be built as module, linking the kernel fails due to unresolved dependencies out of net/smc/smc_ism.o to ism_get_smcd_ops, ism_register_client, and ism_unregister_client as reported via the linux-next test automation (see link). This however is a bug introduced a while ago.

Correct the dependency list in ISM's and SMC's Kconfig to reflect the dependencies that are actually inverted. With this you cannot build a kernel with CONFIG_SMC=y and CONFIG_ISM=m. Either ISM needs to be 'y', too - or a 'n'. That way, SMC can still be configured on non-s390 architectures that do not have (nor need) an ISM driver.

Fixes 89e7d2ba61b7 ("net/ism: Add new API for client registration")

Reported-by Randy Dunlap <[email protected]>

Closes https://lore.kernel.org/linux-next/[email protected]/ open here

Co-developed-by Wenjia Zhang <[email protected]>

Signed-off-by Wenjia Zhang <[email protected]>

Signed-off-by Gerd Bayer <[email protected]>

Tested-by Simon Horman <[email protected]> # build-tested

Acked-by Randy Dunlap <[email protected]>

Tested-by Randy Dunlap <[email protected]> # build-tested

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/s390/net/Kconfig | 2 +-
 net/smc/Kconfig          | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

drivers/s390/net/Kconfig +1 -1

index 9c67b97faba2b..610ad8a801a57 100644
@@ -103,7 +103,7 @@ config CCWGROUP
 
 config ISM
 	tristate "Support for ISM vPCI Adapter"
-	depends on PCI && SMC
+	depends on PCI
 	default n
 	help
 	  Select this option if you want to use the Internal Shared Memory

net/smc/Kconfig +1 -0

index 1ab3c5a2c5ada..746be39967683 100644
@@ -2,6 +2,7 @@
 config SMC
 	tristate "SMC socket protocol family"
 	depends on INET && INFINIBAND
+	depends on m || ISM != m
 	help
 	  SMC-R provides a "sockets over RDMA" solution making use of
 	  RDMA over Converged Ethernet (RoCE) technology to upgrade

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #81 lore raw

PATCH 78/191 net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestamp

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Will Mortensen <[email protected]>

[ Upstream commit da6192ca72d5ad913d109d43dc896290ad05d98f ]

Commit 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change") seems to have accidentally inverted the logic added in commit 0bc73ad46a76 ("net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp").

The impact of this is a little unclear since it seems the FCS scattered with RX-FCS is (usually?) correct regardless.

Fixes 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change")

Tested-by Charlotte Tan <[email protected]>

Reviewed-by Charlotte Tan <[email protected]>

Cc Adham Faris <[email protected]>

Cc Aya Levin <[email protected]>

Cc Tariq Toukan <[email protected]>

Cc Moshe Shemesh <[email protected]>

Cc Saeed Mahameed <[email protected]>

Signed-off-by Will Mortensen <[email protected]>

Reviewed-by Tariq Toukan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/net/ethernet/mellanox/mlx5/core/en_main.c +2 -1

index f7b494125eee8..0cbe822ab084f 100644
@@ -3952,13 +3952,14 @@ static int set_feature_rx_fcs(struct net_device *netdev, bool enable)
 	struct mlx5e_channels *chs = &priv->channels;
 	struct mlx5e_params new_params;
 	int err;
+	bool rx_ts_over_crc = !enable;
 
 	mutex_lock(&priv->state_lock);
 
 	new_params = chs->params;
 	new_params.scatter_fcs_en = enable;
 	err = mlx5e_safe_switch_params(priv, &new_params, mlx5e_set_rx_port_ts_wrap,
-				       &new_params.scatter_fcs_en, true);
+				       &rx_ts_over_crc, true);
 	mutex_unlock(&priv->state_lock);
 	return err;
 }

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #82 lore raw

PATCH 79/191 s390/bpf: Fix clobbering the callers backchain in the trampoline

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ilya Leoshkevich <[email protected]>

[ Upstream commit ce10fc0604bc6a0d626ed8e5d69088057edc71ab ]

One of the first things that s390x kernel functions do is storing the the caller's frame address (backchain) on stack. This makes unwinding possible. The backchain is always stored at frame offset 152, which is inside the 160-byte stack area, that the functions allocate for their callees. The callees must preserve the backchain; the remaining 152 bytes they may use as they please.

Currently the trampoline uses all 160 bytes, clobbering the backchain. This causes kernel panics when using __builtin_return_address() in functions called by the trampoline.

Fix by reducing the usage of the caller-reserved stack area by 8 bytes in the trampoline.

Fixes 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()")

Reported-by Song Liu <[email protected]>

Signed-off-by Ilya Leoshkevich <[email protected]>

Link https://lore.kernel.org/bpf/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/s390/net/bpf_jit_comp.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

arch/s390/net/bpf_jit_comp.c +6 -2

index 2861e3360affc..9a9733e4bc801 100644
@@ -2260,8 +2260,12 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 	tjit->run_ctx_off = alloc_stack(tjit,
 					sizeof(struct bpf_tramp_run_ctx));
 	tjit->tccnt_off = alloc_stack(tjit, sizeof(u64));
-	/* The caller has already reserved STACK_FRAME_OVERHEAD bytes. */
-	tjit->stack_size -= STACK_FRAME_OVERHEAD;
+	/*
+	 * In accordance with the s390x ABI, the caller has allocated
+	 * STACK_FRAME_OVERHEAD bytes for us. 8 of them contain the caller's
+	 * backchain, and the rest we can use.
+	 */
+	tjit->stack_size -= STACK_FRAME_OVERHEAD - sizeof(u64);
 	tjit->orig_stack_args_off = tjit->stack_size + STACK_FRAME_OVERHEAD;
 
 	/* aghi %r15,-stack_size */

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:48 UTC #83 lore raw

PATCH 80/191 s390/bpf: Fix unwinding past the trampoline

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ilya Leoshkevich <[email protected]>

[ Upstream commit 5356ba1ff4f2417e1aebcf99aab35c1ea94dd6d7 ]

When functions called by the trampoline panic, the backtrace that is printed stops at the trampoline, because the trampoline does not store its caller's frame address (backchain) on stack; it also stores the return address at a wrong location.

Store both the same way as is already done for the regular eBPF programs.

Fixes 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()")

Signed-off-by Ilya Leoshkevich <[email protected]>

Link https://lore.kernel.org/bpf/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/s390/net/bpf_jit_comp.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

arch/s390/net/bpf_jit_comp.c +14 -3

index 9a9733e4bc801..e507692e51e71 100644
@@ -2066,6 +2066,7 @@ struct bpf_tramp_jit {
 				 * func_addr's original caller
 				 */
 	int stack_size;		/* Trampoline stack size */
+	int backchain_off;	/* Offset of backchain */
 	int stack_args_off;	/* Offset of stack arguments for calling
 				 * func_addr, has to be at the top
 				 */

@@ -2086,9 +2087,10 @@ struct bpf_tramp_jit {
 				 * for __bpf_prog_enter() return value and
 				 * func_addr respectively
 				 */
-	int r14_off;		/* Offset of saved %r14 */
 	int run_ctx_off;	/* Offset of struct bpf_tramp_run_ctx */
 	int tccnt_off;		/* Offset of saved tailcall counter */
+	int r14_off;		/* Offset of saved %r14, has to be at the
+				 * bottom */
 	int do_fexit;		/* do_fexit: label */
 };

@@ -2247,8 +2249,12 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 	 * Calculate the stack layout.
 	 */
 
-	/* Reserve STACK_FRAME_OVERHEAD bytes for the callees. */
+	/*
+	 * Allocate STACK_FRAME_OVERHEAD bytes for the callees. As the s390x
+	 * ABI requires, put our backchain at the end of the allocated memory.
+	 */
 	tjit->stack_size = STACK_FRAME_OVERHEAD;
+	tjit->backchain_off = tjit->stack_size - sizeof(u64);
 	tjit->stack_args_off = alloc_stack(tjit, nr_stack_args * sizeof(u64));
 	tjit->reg_args_off = alloc_stack(tjit, nr_reg_args * sizeof(u64));
 	tjit->ip_off = alloc_stack(tjit, sizeof(u64));

@@ -2256,10 +2262,10 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 	tjit->bpf_args_off = alloc_stack(tjit, nr_bpf_args * sizeof(u64));
 	tjit->retval_off = alloc_stack(tjit, sizeof(u64));
 	tjit->r7_r8_off = alloc_stack(tjit, 2 * sizeof(u64));
-	tjit->r14_off = alloc_stack(tjit, sizeof(u64));
 	tjit->run_ctx_off = alloc_stack(tjit,
 					sizeof(struct bpf_tramp_run_ctx));
 	tjit->tccnt_off = alloc_stack(tjit, sizeof(u64));
+	tjit->r14_off = alloc_stack(tjit, sizeof(u64) * 2);
 	/*
 	 * In accordance with the s390x ABI, the caller has allocated
 	 * STACK_FRAME_OVERHEAD bytes for us. 8 of them contain the caller's

@@ -2268,8 +2274,13 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 	tjit->stack_size -= STACK_FRAME_OVERHEAD - sizeof(u64);
 	tjit->orig_stack_args_off = tjit->stack_size + STACK_FRAME_OVERHEAD;
 
+	/* lgr %r1,%r15 */
+	EMIT4(0xb9040000, REG_1, REG_15);
 	/* aghi %r15,-stack_size */
 	EMIT4_IMM(0xa70b0000, REG_15, -tjit->stack_size);
+	/* stg %r1,backchain_off(%r15) */
+	EMIT6_DISP_LH(0xe3000000, 0x0024, REG_1, REG_0, REG_15,
+		      tjit->backchain_off);
 	/* mvc tccnt_off(4,%r15),stack_size+STK_OFF_TCCNT(%r15) */
 	_EMIT6(0xd203f000 | tjit->tccnt_off,
 	       0xf000 | (tjit->stack_size + STK_OFF_TCCNT));

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #84 lore raw

PATCH 81/191 net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <[email protected]>

[ Upstream commit 31c07dffafce914c1d1543c135382a11ff058d93 ]

Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.

Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock.

nfc_llcp_sock_get_sn() has a similar problem.

Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear.

Fixes 8f50020ed9b8 ("NFC: LLCP late binding")

Reported-by Sili Luo <[email protected]>

Signed-off-by Eric Dumazet <[email protected]>

Cc Willy Tarreau <[email protected]>

Reviewed-by Krzysztof Kozlowski <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/nfc/llcp_core.c | 30 ++++++++++++------------------
 1 file changed, 12 insertions(+), 18 deletions(-)

net/nfc/llcp_core.c +12 ~~-18~~

index 6705bb895e239..1dac28136e6a3 100644
@@ -203,17 +203,13 @@ static struct nfc_llcp_sock *nfc_llcp_sock_get(struct nfc_llcp_local *local,
 
 		if (tmp_sock->ssap == ssap && tmp_sock->dsap == dsap) {
 			llcp_sock = tmp_sock;
+			sock_hold(&llcp_sock->sk);
 			break;
 		}
 	}
 
 	read_unlock(&local->sockets.lock);
 
-	if (llcp_sock == NULL)
-		return NULL;
-
-	sock_hold(&llcp_sock->sk);
-
 	return llcp_sock;
 }

@@ -346,7 +342,8 @@ static int nfc_llcp_wks_sap(const char *service_name, size_t service_name_len)
 
 static
 struct nfc_llcp_sock *nfc_llcp_sock_from_sn(struct nfc_llcp_local *local,
-					    const u8 *sn, size_t sn_len)
+					    const u8 *sn, size_t sn_len,
+					    bool needref)
 {
 	struct sock *sk;
 	struct nfc_llcp_sock *llcp_sock, *tmp_sock;

@@ -382,6 +379,8 @@ struct nfc_llcp_sock *nfc_llcp_sock_from_sn(struct nfc_llcp_local *local,
 
 		if (memcmp(sn, tmp_sock->service_name, sn_len) == 0) {
 			llcp_sock = tmp_sock;
+			if (needref)
+				sock_hold(&llcp_sock->sk);
 			break;
 		}
 	}

@@ -423,7 +422,8 @@ u8 nfc_llcp_get_sdp_ssap(struct nfc_llcp_local *local,
 		 * to this service name.
 		 */
 		if (nfc_llcp_sock_from_sn(local, sock->service_name,
-					  sock->service_name_len) != NULL) {
+					  sock->service_name_len,
+					  false) != NULL) {
 			mutex_unlock(&local->sdp_lock);
 
 			return LLCP_SAP_MAX;

@@ -824,16 +824,7 @@ static struct nfc_llcp_sock *nfc_llcp_connecting_sock_get(struct nfc_llcp_local
 static struct nfc_llcp_sock *nfc_llcp_sock_get_sn(struct nfc_llcp_local *local,
 						  const u8 *sn, size_t sn_len)
 {
-	struct nfc_llcp_sock *llcp_sock;
-
-	llcp_sock = nfc_llcp_sock_from_sn(local, sn, sn_len);
-
-	if (llcp_sock == NULL)
-		return NULL;
-
-	sock_hold(&llcp_sock->sk);
-
-	return llcp_sock;
+	return nfc_llcp_sock_from_sn(local, sn, sn_len, true);
 }
 
 static const u8 *nfc_llcp_connect_sn(const struct sk_buff *skb, size_t *sn_len)

@@ -1298,7 +1289,8 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
 			}
 
 			llcp_sock = nfc_llcp_sock_from_sn(local, service_name,
-							  service_name_len);
+							  service_name_len,
+							  true);
 			if (!llcp_sock) {
 				sap = 0;
 				goto add_snl;

@@ -1318,6 +1310,7 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
 
 				if (sap == LLCP_SAP_MAX) {
 					sap = 0;
+					nfc_llcp_sock_put(llcp_sock);
 					goto add_snl;
 				}

@@ -1335,6 +1328,7 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
 
 			pr_debug("%p %d\n", llcp_sock, sap);
 
+			nfc_llcp_sock_put(llcp_sock);
 add_snl:
 			sdp = nfc_llcp_build_sdres_tlv(tid, sap);
 			if (sdp == NULL)

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #85 lore raw

PATCH 82/191 ethtool: Fix mod state of verbose no_mask bitset

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kory Maincent <[email protected]>

[ Upstream commit 108a36d07c01edbc5942d27c92494d1c6e4d45a0 ]

A bitset without mask in a _SET request means we want exactly the bits in the bitset to be set. This works correctly for compact format but when verbose format is parsed, ethnl_update_bitset32_verbose() only sets the bits present in the request bitset but does not clear the rest. The commit 6699170376ab fixes this issue by clearing the whole target bitmap before we start iterating. The solution proposed brought an issue with the behavior of the mod variable. As the bitset is always cleared the old val will always differ to the new val.

Fix it by adding a new temporary variable which save the state of the old bitmap.

Fixes 6699170376ab ("ethtool: fix application of verbose no_mask bitset")

Signed-off-by Kory Maincent <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/ethtool/bitset.c | 32 ++++++++++++++++++++++++++------
 1 file changed, 26 insertions(+), 6 deletions(-)

net/ethtool/bitset.c +26 -6

index 0515d6604b3b9..883ed9be81f9f 100644
@@ -431,8 +431,10 @@ ethnl_update_bitset32_verbose(u32 *bitmap, unsigned int nbits,
 			      ethnl_string_array_t names,
 			      struct netlink_ext_ack *extack, bool *mod)
 {
+	u32 *orig_bitmap, *saved_bitmap = NULL;
 	struct nlattr *bit_attr;
 	bool no_mask;
+	bool dummy;
 	int rem;
 	int ret;

@@ -448,8 +450,22 @@ ethnl_update_bitset32_verbose(u32 *bitmap, unsigned int nbits,
 	}
 
 	no_mask = tb[ETHTOOL_A_BITSET_NOMASK];
-	if (no_mask)
-		ethnl_bitmap32_clear(bitmap, 0, nbits, mod);
+	if (no_mask) {
+		unsigned int nwords = DIV_ROUND_UP(nbits, 32);
+		unsigned int nbytes = nwords * sizeof(u32);
+
+		/* The bitmap size is only the size of the map part without
+		 * its mask part.
+		 */
+		saved_bitmap = kcalloc(nwords, sizeof(u32), GFP_KERNEL);
+		if (!saved_bitmap)
+			return -ENOMEM;
+		memcpy(saved_bitmap, bitmap, nbytes);
+		ethnl_bitmap32_clear(bitmap, 0, nbits, &dummy);
+		orig_bitmap = saved_bitmap;
+	} else {
+		orig_bitmap = bitmap;
+	}
 
 	nla_for_each_nested(bit_attr, tb[ETHTOOL_A_BITSET_BITS], rem) {
 		bool old_val, new_val;

@@ -458,13 +474,14 @@ ethnl_update_bitset32_verbose(u32 *bitmap, unsigned int nbits,
 		if (nla_type(bit_attr) != ETHTOOL_A_BITSET_BITS_BIT) {
 			NL_SET_ERR_MSG_ATTR(extack, bit_attr,
 					    "only ETHTOOL_A_BITSET_BITS_BIT allowed in ETHTOOL_A_BITSET_BITS");
-			return -EINVAL;
+			ret = -EINVAL;
+			goto out;
 		}
 		ret = ethnl_parse_bit(&idx, &new_val, nbits, bit_attr, no_mask,
 				      names, extack);
 		if (ret < 0)
-			return ret;
-		old_val = bitmap[idx / 32] & ((u32)1 << (idx % 32));
+			goto out;
+		old_val = orig_bitmap[idx / 32] & ((u32)1 << (idx % 32));
 		if (new_val != old_val) {
 			if (new_val)
 				bitmap[idx / 32] |= ((u32)1 << (idx % 32));

@@ -474,7 +491,10 @@ ethnl_update_bitset32_verbose(u32 *bitmap, unsigned int nbits,
 		}
 	}
 
-	return 0;
+	ret = 0;
+out:
+	kfree(saved_bitmap);
+	return ret;
 }
 
 static int ethnl_compact_sanity_checks(unsigned int nbits,

Signature · 1 line

2.40.1

Jakub Kicinski

2023-10-19 16:29 UTC #86 lore raw

Re: [PATCH 6.5 082/191] ethtool: Fix mod state of verbose no_mask bitset

Quoted 11 lines · On Mon, 16 Oct 2023 10:41:07 +0200 Greg Kroah-Hartman wrote:

A bitset without mask in a _SET request means we want exactly the bits in the bitset to be set. This works correctly for compact format but when verbose format is parsed, ethnl_update_bitset32_verbose() only sets the bits present in the request bitset but does not clear the rest. The commit 6699170376ab fixes this issue by clearing the whole target bitmap before we start iterating. The solution proposed brought an issue with the behavior of the mod variable. As the bitset is always cleared the old val will always differ to the new val.
Fix it by adding a new temporary variable which save the state of the old bitmap.

This one got reverted / needs more work.
Please drop across the branches.

Greg Kroah-Hartman

author maintainer

2023-10-19 17:23 UTC #87 lore raw

Re: [PATCH 6.5 082/191] ethtool: Fix mod state of verbose no_mask bitset

Quoted 10 lines · Jakub Kicinski

Quoted 9 lines · On Mon, 16 Oct 2023 10:41:07 +0200 Greg Kroah-Hartman wrote:
A bitset without mask in a _SET request means we want exactly the bits in the bitset to be set. This works correctly for compact format but when verbose format is parsed, ethnl_update_bitset32_verbose() only sets the bits present in the request bitset but does not clear the rest. The commit 6699170376ab fixes this issue by clearing the whole target bitmap before we start iterating. The solution proposed brought an issue with the behavior of the mod variable. As the bitset is always cleared the old val will always differ to the new val.

Quoted 5 lines

Quoted 2 lines
Fix it by adding a new temporary variable which save the state of the old bitmap.
This one got reverted / needs more work.
Please drop across the branches.

Now dropped, thanks.

greg k-h

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #88 lore raw

PATCH 83/191 net/smc: Fix pos miscalculation in statistics

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nils Hoppmann <[email protected]>

[ Upstream commit a950a5921db450c74212327f69950ff03419483a ]

SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) will calculate wrong bucket positions for payloads of exactly 4096 bytes and (1 << (m + 12)) bytes, with m == SMC_BUF_MAX - 1.

Intended bucket distribution:
Assume l == size of payload, m == SMC_BUF_MAX - 1.

Bucket 0 : 0 < l <= 2^13
Bucket n, 1 <= n <= m-1 : 2^(n+12) < l <= 2^(n+13)
Bucket m : l > 2^(m+12)

Current solution:
_pos = fls64((l) >> 13)
[...]
_pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m

For l == 4096, _pos == -1, but should be _pos == 0.
For l == (1 << (m + 12)), _pos == m, but should be _pos == m - 1.

In order to avoid special treatment of these corner cases, the calculation is adjusted. The new solution first subtracts the length by one, and then calculates the correct bucket by shifting accordingly, i.e. _pos = fls64((l - 1) >> 13), l > 0.
This not only fixes the issues named above, but also makes the whole bucket assignment easier to follow.

Same is done for SMC_STAT_RMB_SIZE_SUB(_smc_stats, _tech, k, _len), where the calculation of the bucket position is similar to the one named above.

Fixes e0e4b8fa5338 ("net/smc: Add SMC statistics support")

Signed-off-by Nils Hoppmann <[email protected]>

Reviewed-by Halil Pasic <[email protected]>

Reviewed-by Wenjia Zhang <[email protected]>

Reviewed-by Dust Li <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/smc/smc_stats.h | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

net/smc/smc_stats.h +9 -5

index aa8928975cc63..9d32058db2b5d 100644
@@ -92,13 +92,14 @@ do { \
 	typeof(_smc_stats) stats = (_smc_stats); \
 	typeof(_tech) t = (_tech); \
 	typeof(_len) l = (_len); \
-	int _pos = fls64((l) >> 13); \
+	int _pos; \
 	typeof(_rc) r = (_rc); \
 	int m = SMC_BUF_MAX - 1; \
 	this_cpu_inc((*stats).smc[t].key ## _cnt); \
-	if (r <= 0) \
+	if (r <= 0 || l <= 0) \
 		break; \
-	_pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m; \
+	_pos = fls64((l - 1) >> 13); \
+	_pos = (_pos <= m) ? _pos : m; \
 	this_cpu_inc((*stats).smc[t].key ## _pd.buf[_pos]); \
 	this_cpu_add((*stats).smc[t].key ## _bytes, r); \
 } \

@@ -138,9 +139,12 @@ while (0)
 do { \
 	typeof(_len) _l = (_len); \
 	typeof(_tech) t = (_tech); \
-	int _pos = fls((_l) >> 13); \
+	int _pos; \
 	int m = SMC_BUF_MAX - 1; \
-	_pos = (_pos < m) ? ((_l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m; \
+	if (_l <= 0) \
+		break; \
+	_pos = fls((_l - 1) >> 13); \
+	_pos = (_pos <= m) ? _pos : m; \
 	this_cpu_inc((*(_smc_stats)).smc[t].k ## _rmbsize.buf[_pos]); \
 } \
 while (0)

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #89 lore raw

PATCH 84/191 net: tcp: fix crashes trying to free half-baked MTU probes

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jakub Kicinski <[email protected]>

[ Upstream commit 71c299c711d1f44f0bf04f1fea66baad565240f1 ]

tcp_stream_alloc_skb() initializes the skb to use tcp_tsorted_anchor which is a union with the destructor. We need to clean that TCP-iness up before freeing.

Fixes 736013292e3c ("tcp: let tcp_mtu_probe() build headless packets")

Reviewed-by Eric Dumazet <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/ipv4/tcp_output.c | 1 +
 1 file changed, 1 insertion(+)

net/ipv4/tcp_output.c +1 -0

index 37fd9537423f1..a8f58f5e99a77 100644
@@ -2441,6 +2441,7 @@ static int tcp_mtu_probe(struct sock *sk)
 
 	/* build the payload, and be prepared to abort if this fails. */
 	if (tcp_clone_payload(sk, nskb, probe_size)) {
+		tcp_skb_tsorted_anchor_cleanup(nskb);
 		consume_skb(nskb);
 		return -1;
 	}

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #90 lore raw

PATCH 85/191 pinctrl: renesas: rzn1: Enable missing PINMUX

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ralph Siemsen <[email protected]>

[ Upstream commit f055ff23c331f28aa4ace4b72dc56f63b9a726c8 ]

Enable pin muxing (eg. programmable function), so that the RZ/N1 GPIO pins will be configured as specified by the pinmux in the DTS.

This used to be enabled implicitly via CONFIG_GENERIC_PINMUX_FUNCTIONS, however that was removed, since the RZ/N1 driver does not call any of the generic pinmux functions.

Fixes 1308fb4e4eae14e6 ("pinctrl: rzn1: Do not select GENERIC_PIN{CTRL_GROUPS,MUX_FUNCTIONS}")

Signed-off-by Ralph Siemsen <[email protected]>

Reviewed-by Miquel Raynal <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Geert Uytterhoeven <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pinctrl/renesas/Kconfig | 1 +
 1 file changed, 1 insertion(+)

drivers/pinctrl/renesas/Kconfig +1 -0

index 77730dc548ed3..c8d519ca53eb7 100644
@@ -235,6 +235,7 @@ config PINCTRL_RZN1
 	depends on OF
 	depends on ARCH_RZN1 || COMPILE_TEST
 	select GENERIC_PINCONF
+	select PINMUX
 	help
 	  This selects pinctrl driver for Renesas RZ/N1 devices.

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #91 lore raw

PATCH 86/191 af_packet: Fix fortified memcpy() without flex array.

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kuniyuki Iwashima <[email protected]>

[ Upstream commit e2bca4870fdaf855651ee80b083d892599c5d982 ]

Sergei Trofimovich reported a regression [0] caused by commit a0ade8404c3b ("af_packet: Fix warning of fortified memcpy() in packet_getname().").

It introduced a flex array sll_addr_flex in struct sockaddr_ll as a union-ed member with sll_addr to work around the fortified memcpy() check.

However, a userspace program uses a struct that has struct sockaddr_ll in the middle, where a flex array is illegal to exist.

include/linux/if_packet.h:24:17: error: flexible array member 'sockaddr_ll::<unnamed union>::<unnamed struct>::sll_addr_flex' not at end of 'struct packet_info_t'

     24 |                 __DECLARE_FLEX_ARRAY(unsigned char, sll_addr_flex);
        |                 ^~~~~~~~~~~~~~~~~~~~

To fix the regression, let's go back to the first attempt [1] telling memcpy() the actual size of the array.

Reported-by Sergei Trofimovich <[email protected]>

Closes https://github.com/NixOS/nixpkgs/pull/252587#issuecomment-1741733002 [0]

Link https://lore.kernel.org/netdev/[email protected]/ [1] open here

Fixes a0ade8404c3b ("af_packet: Fix warning of fortified memcpy() in packet_getname().")

Signed-off-by Kuniyuki Iwashima <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/uapi/linux/if_packet.h | 6 +-----
 net/packet/af_packet.c         | 7 ++++++-
 2 files changed, 7 insertions(+), 6 deletions(-)

include/uapi/linux/if_packet.h +1 -5

index 4d0ad22f83b56..9efc42382fdb9 100644
@@ -18,11 +18,7 @@ struct sockaddr_ll {
 	unsigned short	sll_hatype;
 	unsigned char	sll_pkttype;
 	unsigned char	sll_halen;
-	union {
-		unsigned char	sll_addr[8];
-		/* Actual length is in sll_halen. */
-		__DECLARE_FLEX_ARRAY(unsigned char, sll_addr_flex);
-	};
+	unsigned char	sll_addr[8];
 };
 
 /* Packet types */

net/packet/af_packet.c +6 -1

index a2935bd18ed98..a39b2a0dd5425 100644
@@ -3605,7 +3605,12 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
 	if (dev) {
 		sll->sll_hatype = dev->type;
 		sll->sll_halen = dev->addr_len;
-		memcpy(sll->sll_addr_flex, dev->dev_addr, dev->addr_len);
+
+		/* Let __fortify_memcpy_chk() know the actual buffer size. */
+		memcpy(((struct sockaddr_storage *)sll)->__data +
+		       offsetof(struct sockaddr_ll, sll_addr) -
+		       offsetofend(struct sockaddr_ll, sll_family),
+		       dev->dev_addr, dev->addr_len);
 	} else {
 		sll->sll_hatype = 0;	/* Bad: we have no ARPHRD_UNSPEC */
 		sll->sll_halen = 0;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #92 lore raw

PATCH 87/191 nfc: nci: assert requested protocol is valid

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeremy Cline <[email protected]>

[ Upstream commit 354a6e707e29cb0c007176ee5b8db8be7bd2dee0 ]

The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones.

Fixes 6a2968aaf50c ("NFC: basic NCI protocol implementation")

Reported-and-tested-by [email protected]

Closes https://syzkaller.appspot.com/bug?extid=0839b78e119aae1fec78

Signed-off-by Jeremy Cline <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/nfc/nci/core.c | 5 +++++
 1 file changed, 5 insertions(+)

net/nfc/nci/core.c +5 -0

index fff755dde30d6..6c9592d051206 100644
@@ -909,6 +909,11 @@ static int nci_activate_target(struct nfc_dev *nfc_dev,
 		return -EINVAL;
 	}
 
+	if (protocol >= NFC_PROTO_MAX) {
+		pr_err("the requested nfc protocol is invalid\n");
+		return -EINVAL;
+	}
+
 	if (!(nci_target->supported_protocols & (1 << protocol))) {
 		pr_err("target does not support the requested protocol 0x%x\n",
 		       protocol);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #93 lore raw

PATCH 88/191 octeontx2-pf: Fix page pool frag allocation warning

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ratheesh Kannoth <[email protected]>

[ Upstream commit 50e492143374c17ad89c865a1a44837b3f5c8226 ]

Since page pool param's "order" is set to 0, will result in below warn message if interface is configured with higher rx buffer size.

Steps to reproduce the issue.
1. devlink dev param set pci/0002:04:00.0 name receive_buffer_size \
value 8196 cmode runtime
2. ifconfig eth0 up

[   19.901356] ------------[ cut here ]------------
[   19.901361] WARNING: CPU: 11 PID: 12331 at net/core/page_pool.c:567 page_pool_alloc_frag+0x3c/0x230
[   19.901449] pstate: 82401009 (Nzcv daif +PAN -UAO +TCO -DIT +SSBS BTYPE=--)
[   19.901451] pc : page_pool_alloc_frag+0x3c/0x230
[   19.901453] lr : __otx2_alloc_rbuf+0x60/0xbc [rvu_nicpf]
[   19.901460] sp : ffff80000f66b970
[   19.901461] x29: ffff80000f66b970 x28: 0000000000000000 x27: 0000000000000000
[   19.901464] x26: ffff800000d15b68 x25: ffff000195b5c080 x24: ffff0002a5a32dc0
[   19.901467] x23: ffff0001063c0878 x22: 0000000000000100 x21: 0000000000000000
[   19.901469] x20: 0000000000000000 x19: ffff00016f781000 x18: 0000000000000000
[   19.901472] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[   19.901474] x14: 0000000000000000 x13: ffff0005ffdc9c80 x12: 0000000000000000
[   19.901477] x11: ffff800009119a38 x10: 4c6ef2e3ba300519 x9 : ffff800000d13844
[   19.901479] x8 : ffff0002a5a33cc8 x7 : 0000000000000030 x6 : 0000000000000030
[   19.901482] x5 : 0000000000000005 x4 : 0000000000000000 x3 : 0000000000000a20
[   19.901484] x2 : 0000000000001080 x1 : ffff80000f66b9d4 x0 : 0000000000001000
[   19.901487] Call trace:
[   19.901488]  page_pool_alloc_frag+0x3c/0x230
[   19.901490]  __otx2_alloc_rbuf+0x60/0xbc [rvu_nicpf]
[   19.901494]  otx2_rq_aura_pool_init+0x1c4/0x240 [rvu_nicpf]
[   19.901498]  otx2_open+0x228/0xa70 [rvu_nicpf]
[   19.901501]  otx2vf_open+0x20/0xd0 [rvu_nicvf]
[   19.901504]  __dev_open+0x114/0x1d0
[   19.901507]  __dev_change_flags+0x194/0x210
[   19.901510]  dev_change_flags+0x2c/0x70
[   19.901512]  devinet_ioctl+0x3a4/0x6c4
[   19.901515]  inet_ioctl+0x228/0x240
[   19.901518]  sock_ioctl+0x2ac/0x480
[   19.901522]  __arm64_sys_ioctl+0x564/0xe50
[   19.901525]  invoke_syscall.constprop.0+0x58/0xf0
[   19.901529]  do_el0_svc+0x58/0x150
[   19.901531]  el0_svc+0x30/0x140
[   19.901533]  el0t_64_sync_handler+0xe8/0x114
[   19.901535]  el0t_64_sync+0x1a0/0x1a4
[   19.901537] ---[ end trace 678c0bf660ad8116 ]---

Fixes b2e3406a38f0 ("octeontx2-pf: Add support for page pool")

Signed-off-by Ratheesh Kannoth <[email protected]>

Reviewed-by Yunsheng Lin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c | 1 +
 1 file changed, 1 insertion(+)

drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c +1 -0

index 20ecc90d203e0..379e1510b70c0 100644
@@ -1401,6 +1401,7 @@ int otx2_pool_init(struct otx2_nic *pfvf, u16 pool_id,
 		return 0;
 	}
 
+	pp_params.order = get_order(buf_size);
 	pp_params.flags = PP_FLAG_PAGE_FRAG | PP_FLAG_DMA_MAP;
 	pp_params.pool_size = min(OTX2_PAGE_POOL_SZ, numptrs);
 	pp_params.nid = NUMA_NO_NODE;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #94 lore raw

PATCH 89/191 rswitch: Fix renesas_eth_sw_remove() implementation

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit 510b18cf23b9bd8a982ef7f1fb19f3968a2bf787 ]

Fix functions calling order and a condition in renesas_eth_sw_remove(). Otherwise, kernel NULL pointer dereference happens from phy_stop() if a net device opens.

Fixes 3590918b5d07 ("net: ethernet: renesas: Add support for "Ethernet Switch"")

Signed-off-by Yoshihiro Shimoda <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/renesas/rswitch.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

drivers/net/ethernet/renesas/rswitch.c +6 -4

index 660cbfe344d2c..5024ce9587312 100644
@@ -1942,15 +1942,17 @@ static void rswitch_deinit(struct rswitch_private *priv)
 	rswitch_gwca_hw_deinit(priv);
 	rcar_gen4_ptp_unregister(priv->ptp_priv);
 
-	for (i = 0; i < RSWITCH_NUM_PORTS; i++) {
+	rswitch_for_each_enabled_port(priv, i) {
 		struct rswitch_device *rdev = priv->rdev[i];
 
-		phy_exit(priv->rdev[i]->serdes);
-		rswitch_ether_port_deinit_one(rdev);
 		unregister_netdev(rdev->ndev);
-		rswitch_device_free(priv, i);
+		rswitch_ether_port_deinit_one(rdev);
+		phy_exit(priv->rdev[i]->serdes);
 	}
 
+	for (i = 0; i < RSWITCH_NUM_PORTS; i++)
+		rswitch_device_free(priv, i);
+
 	rswitch_gwca_ts_queue_free(priv);
 	rswitch_gwca_linkfix_free(priv);

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #95 lore raw

PATCH 90/191 rswitch: Fix imbalance phy_power_off() calling

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit 053f13f67be6d02781730c9ac71abde6e9140610 ]

The phy_power_off() should not be called if phy_power_on() failed. So, add a condition .power_count before calls phy_power_off().

Fixes 5cb630925b49 ("net: renesas: rswitch: Add phy_power_{on,off}() calling")

Signed-off-by Yoshihiro Shimoda <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/renesas/rswitch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/renesas/rswitch.c +1 -1

index 5024ce9587312..fb9a520f42078 100644
@@ -1255,7 +1255,7 @@ static void rswitch_adjust_link(struct net_device *ndev)
 		phy_print_status(phydev);
 		if (phydev->link)
 			phy_power_on(rdev->serdes);
-		else
+		else if (rdev->serdes->power_count)
 			phy_power_off(rdev->serdes);
 
 		rdev->etha->link = phydev->link;

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #96 lore raw

PATCH 91/191 workqueue: Override implicit ordered attribute in workqueue_apply_unbound_cpumask()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Waiman Long <[email protected]>

[ Upstream commit ca10d851b9ad0338c19e8e3089e24d565ebfffd7 ]

Commit 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered") enabled implicit ordered attribute to be added to WQ_UNBOUND workqueues with max_active of 1. This prevented the changing of attributes to these workqueues leading to fix commit 0a94efb5acbb ("workqueue: implicit ordered attribute should be overridable").

However, workqueue_apply_unbound_cpumask() was not updated at that time. So sysfs changes to wq_unbound_cpumask has no effect on WQ_UNBOUND workqueues with implicit ordered attribute. Since not all WQ_UNBOUND workqueues are visible on sysfs, we are not able to make all the necessary cpumask changes even if we iterates all the workqueue cpumasks in sysfs and changing them one by one.

Fix this problem by applying the corresponding change made to apply_workqueue_attrs_locked() in the fix commit to workqueue_apply_unbound_cpumask().

Fixes 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")

Signed-off-by Waiman Long <[email protected]>

Signed-off-by Tejun Heo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 kernel/workqueue.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

kernel/workqueue.c +6 -2

index e51ab3d4765eb..e4a37d7a6752d 100644
@@ -5741,9 +5741,13 @@ static int workqueue_apply_unbound_cpumask(const cpumask_var_t unbound_cpumask)
 	list_for_each_entry(wq, &workqueues, list) {
 		if (!(wq->flags & WQ_UNBOUND))
 			continue;
+
 		/* creating multiple pwqs breaks ordering guarantee */
-		if (wq->flags & __WQ_ORDERED)
-			continue;
+		if (!list_empty(&wq->pwqs)) {
+			if (wq->flags & __WQ_ORDERED_EXPLICIT)
+				continue;
+			wq->flags &= ~__WQ_ORDERED;
+		}
 
 		ctx = apply_wqattrs_prepare(wq, wq->unbound_attrs, unbound_cpumask);
 		if (!ctx) {

Signature · 1 line

2.40.1

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #97 lore raw

PATCH 92/191 riscv: signal: fix sigaltstack frame size checking

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Chiu <[email protected]>

commit 14a270bfab7ab1c4b605c01eeca5557447ad5a2b upstream.

The alternative stack checking in get_sigframe introduced by the Vector support is not needed and has a problem. It is not needed as we have already validate it at the beginning of the function if we are already on an altstack. If not, the size of an altstack is always validated at its allocation stage with sigaltstack_size_valid().

Besides, we must only regard the size of an altstack if the handler of a signal is registered with SA_ONSTACK. So, blindly checking overflow of an altstack if sas_ss_size not equals to zero will check against wrong signal handlers if only a subset of signals are registered with SA_ONSTACK.

Fixes 8ee0b41898fa ("riscv: signal: Add sigcontext save/restore for vector")

Reported-by Prashanth Swaminathan <[email protected]>

Signed-off-by Andy Chiu <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Palmer Dabbelt <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/riscv/kernel/signal.c |    7 -------
 1 file changed, 7 deletions(-)

arch/riscv/kernel/signal.c +0 -7

@@ -311,13 +311,6 @@ static inline void __user *get_sigframe(
 	/* Align the stack frame. */
 	sp &= ~0xfUL;
 
-	/*
-	 * Fail if the size of the altstack is not large enough for the
-	 * sigframe construction.
-	 */
-	if (current->sas_ss_size && sp < current->sas_ss_sp)
-		return (void __user __force *)-1UL;
-
 	return (void __user *)sp;
 }

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #98 lore raw

PATCH 93/191 ovl: temporarily disable appending lowedirs

Link https://lore.kernel.org/r/CAJfpegsr3A4YgF2YBevWa6n3=AcP7hNndG6EPMu3ncvV-AM71A@mail.gmail.com/ open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amir Goldstein <[email protected]>

commit beae836e9c61ee039e367a94b14f7fea08f0ad4c upstream.

Kernel v6.5 converted overlayfs to new mount api.
As an added bonus, it also added a feature to allow appending lowerdirs using lowerdir=:/lower2,lowerdir=::/data3 syntax.

This new syntax has raised some concerns regarding escaping of colons. We decided to try and disable this syntax, which hasn't been in the wild for so long and introduce it again in 6.7 using explicit mount options lowerdir+=/lower2,datadir+=/data3.

Fixes b36a5780cb44 ("ovl: modify layer parameter parsing")

Signed-off-by Amir Goldstein <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/overlayfs/params.c |   52 ++------------------------------------------------
 1 file changed, 3 insertions(+), 49 deletions(-)

fs/overlayfs/params.c +3 ~~-49~~

@@ -284,12 +284,6 @@ static void ovl_parse_param_drop_lowerdi
  *     Set "/lower1", "/lower2", and "/lower3" as lower layers and
  *     "/data1" and "/data2" as data lower layers. Any existing lower
  *     layers are replaced.
- * (2) lowerdir=:/lower4
- *     Append "/lower4" to current stack of lower layers. This requires
- *     that there already is at least one lower layer configured.
- * (3) lowerdir=::/lower5
- *     Append data "/lower5" as data lower layer. This requires that
- *     there's at least one regular lower layer present.
  */
 static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc)
 {

@@ -311,49 +305,9 @@ static int ovl_parse_param_lowerdir(cons
 		return 0;
 	}
 
-	if (strncmp(name, "::", 2) == 0) {
-		/*
-		 * This is a data layer.
-		 * There must be at least one regular lower layer
-		 * specified.
-		 */
-		if (ctx->nr == 0) {
-			pr_err("data lower layers without regular lower layers not allowed");
-			return -EINVAL;
-		}
-
-		/* Skip the leading "::". */
-		name += 2;
-		data_layer = true;
-		/*
-		 * A data layer is automatically an append as there
-		 * must've been at least one regular lower layer.
-		 */
-		append = true;
-	} else if (*name == ':') {
-		/*
-		 * This is a regular lower layer.
-		 * If users want to append a layer enforce that they
-		 * have already specified a first layer before. It's
-		 * better to be strict.
-		 */
-		if (ctx->nr == 0) {
-			pr_err("cannot append layer if no previous layer has been specified");
-			return -EINVAL;
-		}
-
-		/*
-		 * Once a sequence of data layers has started regular
-		 * lower layers are forbidden.
-		 */
-		if (ctx->nr_data > 0) {
-			pr_err("regular lower layers cannot follow data lower layers");
-			return -EINVAL;
-		}
-
-		/* Skip the leading ":". */
-		name++;
-		append = true;
+	if (*name == ':') {
+		pr_err("cannot append lower layer");
+		return -EINVAL;
 	}
 
 	dup = kstrdup(name, GFP_KERNEL);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #99 lore raw

PATCH 94/191 dmaengine: stm32-mdma: abort resume if no ongoing transfer

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amelie Delaunay <[email protected]>

commit 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a upstream.

chan->desc can be null, if transfer is terminated when resume is called, leading to a NULL pointer when retrieving the hwdesc.
To avoid this case, check that chan->desc is not null and channel is disabled (transfer previously paused or terminated).

Fixes a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/stm32-mdma.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/dma/stm32-mdma.c +4 -0

@@ -1237,6 +1237,10 @@ static int stm32_mdma_resume(struct dma_
 	unsigned long flags;
 	u32 status, reg;
 
+	/* Transfer can be terminated */
+	if (!chan->desc || (stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)) & STM32_MDMA_CCR_EN))
+		return -EPERM;
+
 	hwdesc = chan->desc->node[chan->curr_hwdesc].hwdesc;
 
 	spin_lock_irqsave(&chan->vchan.lock, flags);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #100 lore raw

PATCH 95/191 dmaengine: stm32-dma: fix stm32_dma_prep_slave_sg in case of MDMA chaining

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amelie Delaunay <[email protected]>

commit 2df467e908ce463cff1431ca1b00f650f7a514b4 upstream.

Current Target (CT) have to be reset when starting an MDMA chaining use case, as Double Buffer mode is activated. It ensures the DMA will start processing the first memory target (pointed with SxM0AR).

Fixes 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/stm32-dma.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/dma/stm32-dma.c +3 -1

@@ -1113,8 +1113,10 @@ static struct dma_async_tx_descriptor *s
 		chan->chan_reg.dma_scr &= ~STM32_DMA_SCR_PFCTRL;
 
 	/* Activate Double Buffer Mode if DMA triggers STM32 MDMA and more than 1 sg */
-	if (chan->trig_mdma && sg_len > 1)
+	if (chan->trig_mdma && sg_len > 1) {
 		chan->chan_reg.dma_scr |= STM32_DMA_SCR_DBM;
+		chan->chan_reg.dma_scr &= ~STM32_DMA_SCR_CT;
+	}
 
 	for_each_sg(sgl, sg, sg_len, i) {
 		ret = stm32_dma_set_xfer_param(chan, direction, &buswidth,

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #101 lore raw

PATCH 96/191 dmaengine: stm32-dma: fix residue in case of MDMA chaining

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amelie Delaunay <[email protected]>

commit 67e13e89742c3b21ce177f612bf9ef32caae6047 upstream.

In case of MDMA chaining, DMA is configured in Double-Buffer Mode (DBM) with two periods, but if transfer has been prepared with _prep_slave_sg(), the transfer is not marked cyclic (=!chan->desc->cyclic). However, as DBM is activated for MDMA chaining, residue computation must take into account cyclic constraints.

With only two periods in MDMA chaining, and no update due to Transfer Complete interrupt masked, n_sg is always 0. If DMA current memory address (depending on SxCR.CT and SxM0AR/SxM1AR) does not correspond, it means n_sg should be increased.
Then, the residue of the current period is the one read from SxNDTR and should not be overwritten with the full period length.

Fixes 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/stm32-dma.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

drivers/dma/stm32-dma.c +4 -3

@@ -1389,11 +1389,12 @@ static size_t stm32_dma_desc_residue(str
 
 	residue = stm32_dma_get_remaining_bytes(chan);
 
-	if (chan->desc->cyclic && !stm32_dma_is_current_sg(chan)) {
+	if ((chan->desc->cyclic || chan->trig_mdma) && !stm32_dma_is_current_sg(chan)) {
 		n_sg++;
 		if (n_sg == chan->desc->num_sgs)
 			n_sg = 0;
-		residue = sg_req->len;
+		if (!chan->trig_mdma)
+			residue = sg_req->len;
 	}
 
 	/*

@@ -1403,7 +1404,7 @@ static size_t stm32_dma_desc_residue(str
 	 * residue = remaining bytes from NDTR + remaining
 	 * periods/sg to be transferred
 	 */
-	if (!chan->desc->cyclic || n_sg != 0)
+	if ((!chan->desc->cyclic && !chan->trig_mdma) || n_sg != 0)
 		for (i = n_sg; i < desc->num_sgs; i++)
 			residue += desc->sg_req[i].len;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:49 UTC #102 lore raw

PATCH 97/191 dmaengine: stm32-mdma: use Link Address Register to compute residue

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amelie Delaunay <[email protected]>

commit a4b306eb83579c07b63dc65cd5bae53b7b4019d0 upstream.

Current implementation relies on curr_hwdesc index. But to keep this index up to date, Block Transfer interrupt (BTIE) has to be enabled. If it is not, curr_hwdesc is not updated, and then residue is not reliable. Rely on Link Address Register instead. And disable BTIE interrupt in stm32_mdma_setup_xfer() because it is no more needed in case of _prep_slave_sg() to maintain curr_hwdesc up to date.
It avoids extra interrupts and also ensures a reliable residue. These improvements are required for STM32 DCMI camera capture use case, which need STM32 DMA and MDMA chaining for good performance.

Fixes 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/stm32-mdma.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

drivers/dma/stm32-mdma.c +11 -4

@@ -778,8 +778,6 @@ static int stm32_mdma_setup_xfer(struct
 	/* Enable interrupts */
 	ccr &= ~STM32_MDMA_CCR_IRQ_MASK;
 	ccr |= STM32_MDMA_CCR_TEIE | STM32_MDMA_CCR_CTCIE;
-	if (sg_len > 1)
-		ccr |= STM32_MDMA_CCR_BTIE;
 	desc->ccr = ccr;
 
 	return 0;

@@ -1325,12 +1323,21 @@ static size_t stm32_mdma_desc_residue(st
 {
 	struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
 	struct stm32_mdma_hwdesc *hwdesc;
-	u32 cbndtr, residue, modulo, burst_size;
+	u32 cisr, clar, cbndtr, residue, modulo, burst_size;
 	int i;
 
+	cisr = stm32_mdma_read(dmadev, STM32_MDMA_CISR(chan->id));
+
 	residue = 0;
-	for (i = curr_hwdesc + 1; i < desc->count; i++) {
+	/* Get the next hw descriptor to process from current transfer */
+	clar = stm32_mdma_read(dmadev, STM32_MDMA_CLAR(chan->id));
+	for (i = desc->count - 1; i >= 0; i--) {
 		hwdesc = desc->node[i].hwdesc;
+
+		if (hwdesc->clar == clar)
+			break;/* Current transfer found, stop cumulating */
+
+		/* Cumulate residue of unprocessed hw descriptors */
 		residue += STM32_MDMA_CBNDTR_BNDT(hwdesc->cbndtr);
 	}
 	cbndtr = stm32_mdma_read(dmadev, STM32_MDMA_CBNDTR(chan->id));

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #103 lore raw

PATCH 98/191 dmaengine: stm32-mdma: set in_flight_bytes in case CRQA flag is set

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amelie Delaunay <[email protected]>

commit 584970421725b7805db84714b857851fdf7203a9 upstream.

CRQA flag is set by hardware when the channel request become active and the channel is enabled. It is cleared by hardware, when the channel request is completed.
So when it is set, it means MDMA is transferring bytes.
This information is useful in case of STM32 DMA and MDMA chaining, especially when the user pauses DMA before stopping it, to trig one last MDMA transfer to get the latest bytes of the SRAM buffer to the destination buffer.
STM32 DCMI driver can then use this to know if the last MDMA transfer in case of chaining is done.

Fixes 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/stm32-mdma.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

drivers/dma/stm32-mdma.c +9 -5

@@ -1319,7 +1319,8 @@ static int stm32_mdma_slave_config(struc
 
 static size_t stm32_mdma_desc_residue(struct stm32_mdma_chan *chan,
 				      struct stm32_mdma_desc *desc,
-				      u32 curr_hwdesc)
+				      u32 curr_hwdesc,
+				      struct dma_tx_state *state)
 {
 	struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
 	struct stm32_mdma_hwdesc *hwdesc;

@@ -1343,6 +1344,10 @@ static size_t stm32_mdma_desc_residue(st
 	cbndtr = stm32_mdma_read(dmadev, STM32_MDMA_CBNDTR(chan->id));
 	residue += cbndtr & STM32_MDMA_CBNDTR_BNDT_MASK;
 
+	state->in_flight_bytes = 0;
+	if (chan->chan_config.m2m_hw && (cisr & STM32_MDMA_CISR_CRQA))
+		state->in_flight_bytes = cbndtr & STM32_MDMA_CBNDTR_BNDT_MASK;
+
 	if (!chan->mem_burst)
 		return residue;

@@ -1372,11 +1377,10 @@ static enum dma_status stm32_mdma_tx_sta
 
 	vdesc = vchan_find_desc(&chan->vchan, cookie);
 	if (chan->desc && cookie == chan->desc->vdesc.tx.cookie)
-		residue = stm32_mdma_desc_residue(chan, chan->desc,
-						  chan->curr_hwdesc);
+		residue = stm32_mdma_desc_residue(chan, chan->desc, chan->curr_hwdesc, state);
 	else if (vdesc)
-		residue = stm32_mdma_desc_residue(chan,
-						  to_stm32_mdma_desc(vdesc), 0);
+		residue = stm32_mdma_desc_residue(chan, to_stm32_mdma_desc(vdesc), 0, state);
+
 	dma_set_residue(state, residue);
 
 	spin_unlock_irqrestore(&chan->vchan.lock, flags);

Greg Kroah-Hartman

author maintainer

2023-10-16 15:00 UTC #104 lore raw

PATCH 99/191 usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wesley Cheng <[email protected]>

commit 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 upstream.

As mentioned in:
commit 474ed23a6257 ("xhci: align the last trb before link if it is
easily splittable.")

A bounce buffer is utilized for ensuring that transfers that span across ring segments are aligned to the EP's max packet size. However, the device that is used to map the DMA buffer to is currently using the XHCI HCD, which does not carry any DMA operations in certain configrations. Migration to using the sysdev entry was introduced for DWC3 based implementations where the IOMMU operations are present.

Replace the reference to the controller device to sysdev instead. This allows the bounce buffer to be properly mapped to any implementations that have an IOMMU involved.

cc [email protected]

Fixes 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")

Signed-off-by Wesley Cheng <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-ring.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/usb/host/xhci-ring.c +2 -2

@@ -798,7 +798,7 @@ static void xhci_giveback_urb_in_irq(str
 static void xhci_unmap_td_bounce_buffer(struct xhci_hcd *xhci,
 		struct xhci_ring *ring, struct xhci_td *td)
 {
-	struct device *dev = xhci_to_hcd(xhci)->self.controller;
+	struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 	struct xhci_segment *seg = td->bounce_seg;
 	struct urb *urb = td->urb;
 	size_t len;

@@ -3469,7 +3469,7 @@ static u32 xhci_td_remainder(struct xhci
 static int xhci_align_td(struct xhci_hcd *xhci, struct urb *urb, u32 enqd_len,
 			 u32 *trb_buff_len, struct xhci_segment *seg)
 {
-	struct device *dev = xhci_to_hcd(xhci)->self.controller;
+	struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 	unsigned int unalign;
 	unsigned int max_pkt;
 	u32 new_buff_len;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #105 lore raw

PATCH 100/191 xhci: track port suspend state correctly in unsuccessful resume cases

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit d7cdfc319b2bcf6899ab0a05eec0958bc802a9a1 upstream.

xhci-hub.c tracks suspended ports in a suspended_port bitfield. This is checked when responding to a Get_Status(PORT) request to see if a port in running U0 state was recently resumed, and adds the required USB_PORT_STAT_C_SUSPEND change bit in those cases.

The suspended_port bit was left uncleared if a device is disconnected during suspend. The bit remained set even when a new device was connected and enumerated. The set bit resulted in a incorrect Get_Status(PORT) response with a bogus USB_PORT_STAT_C_SUSPEND change
bit set once the new device reached U0 link state.

USB_PORT_STAT_C_SUSPEND change bit is only used for USB2 ports, but xhci-hub keeps track of both USB2 and USB3 suspended ports.

Reported-by Wesley Cheng <[email protected]>

Closes https://lore.kernel.org/linux-usb/[email protected]/ open here

Fixes 1d5810b6923c ("xhci: Rework port suspend structures for limited ports.")

Tested-by Wesley Cheng <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-hub.c |   19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

drivers/usb/host/xhci-hub.c +10 -9

@@ -1062,19 +1062,19 @@ static void xhci_get_usb3_port_status(st
 		*status |= USB_PORT_STAT_C_CONFIG_ERROR << 16;
 
 	/* USB3 specific wPortStatus bits */
-	if (portsc & PORT_POWER) {
+	if (portsc & PORT_POWER)
 		*status |= USB_SS_PORT_STAT_POWER;
-		/* link state handling */
-		if (link_state == XDEV_U0)
-			bus_state->suspended_ports &= ~(1 << portnum);
-	}
 
-	/* remote wake resume signaling complete */
-	if (bus_state->port_remote_wakeup & (1 << portnum) &&
+	/* no longer suspended or resuming */
+	if (link_state != XDEV_U3 &&
 	    link_state != XDEV_RESUME &&
 	    link_state != XDEV_RECOVERY) {
-		bus_state->port_remote_wakeup &= ~(1 << portnum);
-		usb_hcd_end_port_resume(&hcd->self, portnum);
+		/* remote wake resume signaling complete */
+		if (bus_state->port_remote_wakeup & (1 << portnum)) {
+			bus_state->port_remote_wakeup &= ~(1 << portnum);
+			usb_hcd_end_port_resume(&hcd->self, portnum);
+		}
+		bus_state->suspended_ports &= ~(1 << portnum);
 	}
 
 	xhci_hub_report_usb3_link_state(xhci, status, portsc);

@@ -1131,6 +1131,7 @@ static void xhci_get_usb2_port_status(st
 			usb_hcd_end_port_resume(&port->rhub->hcd->self, portnum);
 		}
 		port->rexit_active = 0;
+		bus_state->suspended_ports &= ~(1 << portnum);
 	}
 }

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #106 lore raw

PATCH 101/191 xhci: Clear EHB bit only at end of interrupt handler

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lukas Wunner <[email protected]>

commit 15f3ef070933817fac2bcbdb9c85bff9e54e9f80 upstream.

The Event Handler Busy bit shall be cleared by software when the Event Ring is empty. The xHC is thereby informed that it may raise another interrupt once it has enqueued new events (sec 4.17.2).

However since commit dc0ffbea5729 ("usb: host: xhci: update event ring dequeue pointer on purpose"), the EHB bit is already cleared after half a segment has been processed.

As a result, spurious interrupts may occur:

- xhci_irq() processes half a segment, clears EHB, continues processing remaining events.
- xHC enqueues new events. Because EHB has been cleared, xHC sets Interrupt Pending bit. Interrupt moderation countdown begins.
- Meanwhile xhci_irq() continues processing events. Interrupt moderation countdown reaches zero, so an MSI interrupt is signaled.
- xhci_irq() empties the Event Ring, clears EHB again and is done.
- Because an MSI interrupt has been signaled, xhci_irq() is run again. It discovers there's nothing to do and returns IRQ_NONE.

Avoid by clearing the EHB bit only at the end of xhci_irq().

Fixes dc0ffbea5729 ("usb: host: xhci: update event ring dequeue pointer on purpose")

Signed-off-by Lukas Wunner <[email protected]>

Cc [email protected] # v5.5+

Cc Peter Chen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-ring.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

drivers/usb/host/xhci-ring.c +7 -5

index 98389b568633..3e5dc0723a8f 100644
@@ -2996,7 +2996,8 @@ static int xhci_handle_event(struct xhci_hcd *xhci, struct xhci_interrupter *ir)
  */
 static void xhci_update_erst_dequeue(struct xhci_hcd *xhci,
 				     struct xhci_interrupter *ir,
-				     union xhci_trb *event_ring_deq)
+				     union xhci_trb *event_ring_deq,
+				     bool clear_ehb)
 {
 	u64 temp_64;
 	dma_addr_t deq;

@@ -3017,12 +3018,13 @@ static void xhci_update_erst_dequeue(struct xhci_hcd *xhci,
 			return;
 
 		/* Update HC event ring dequeue pointer */
-		temp_64 &= ERST_PTR_MASK;
+		temp_64 &= ERST_DESI_MASK;
 		temp_64 |= ((u64) deq & (u64) ~ERST_PTR_MASK);
 	}
 
 	/* Clear the event handler busy flag (RW1C) */
-	temp_64 |= ERST_EHB;
+	if (clear_ehb)
+		temp_64 |= ERST_EHB;
 	xhci_write_64(xhci, temp_64, &ir->ir_set->erst_dequeue);
 }

@@ -3103,7 +3105,7 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
 	while (xhci_handle_event(xhci, ir) > 0) {
 		if (event_loop++ < TRBS_PER_SEGMENT / 2)
 			continue;
-		xhci_update_erst_dequeue(xhci, ir, event_ring_deq);
+		xhci_update_erst_dequeue(xhci, ir, event_ring_deq, false);
 		event_ring_deq = ir->event_ring->dequeue;
 
 		/* ring is half-full, force isoc trbs to interrupt more often */

@@ -3113,7 +3115,7 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
 		event_loop = 0;
 	}
 
-	xhci_update_erst_dequeue(xhci, ir, event_ring_deq);
+	xhci_update_erst_dequeue(xhci, ir, event_ring_deq, true);
 	ret = IRQ_HANDLED;
 
 out:

Signature · 1 line

2.42.0

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #107 lore raw

PATCH 102/191 xhci: Preserve RsvdP bits in ERSTBA register correctly

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lukas Wunner <[email protected]>

commit cf97c5e0f7dda2edc15ecd96775fe6c355823784 upstream.

xhci_add_interrupter() erroneously preserves only the lowest 4 bits when writing the ERSTBA register, not the lowest 6 bits. Fix it.

Migrate the ERST_BASE_RSVDP macro to the modern GENMASK_ULL() syntax to avoid a u64 cast.

This was previously fixed by commit 8c1cbec9db1a ("xhci: fix event ring segment table related masks and variables in header"), but immediately undone by commit b17a57f89f69 ("xhci: Refactor interrupter code for initial multi interrupter support.").

Fixes b17a57f89f69 ("xhci: Refactor interrupter code for initial multi interrupter support.")

Signed-off-by Lukas Wunner <[email protected]>

Cc [email protected] # v6.3+

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-mem.c |    4 ++--
 drivers/usb/host/xhci.h     |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

drivers/usb/host/xhci-mem.c +2 -2

@@ -2288,8 +2288,8 @@ xhci_add_interrupter(struct xhci_hcd *xh
 	writel(erst_size, &ir->ir_set->erst_size);
 
 	erst_base = xhci_read_64(xhci, &ir->ir_set->erst_base);
-	erst_base &= ERST_PTR_MASK;
-	erst_base |= (ir->erst.erst_dma_addr & (u64) ~ERST_PTR_MASK);
+	erst_base &= ERST_BASE_RSVDP;
+	erst_base |= ir->erst.erst_dma_addr & ~ERST_BASE_RSVDP;
 	xhci_write_64(xhci, erst_base, &ir->ir_set->erst_base);
 
 	/* Set the event ring dequeue address of this interrupter */

drivers/usb/host/xhci.h +1 -1

@@ -514,7 +514,7 @@ struct xhci_intr_reg {
 #define	ERST_SIZE_MASK		(0xffff << 16)
 
 /* erst_base bitmasks */
-#define ERST_BASE_RSVDP		(0x3f)
+#define ERST_BASE_RSVDP		(GENMASK_ULL(5, 0))
 
 /* erst_dequeue bitmasks */
 /* Dequeue ERST Segment Index (DESI) - Segment number (or alias)

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #108 lore raw

PATCH 103/191 net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read

[1] https://syzkaller.appspot.com/bug?extid=1f53a30781af65d2c955

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Javier Carrasco <[email protected]>

commit 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 upstream.

syzbot has found an uninit-value bug triggered by the dm9601 driver [1].

This error happens because the variable res is not updated if the call to dm_read_shared_word returns an error. In this particular case -EPROTO was returned and res stayed uninitialized.

This can be avoided by checking the return value of dm_read_shared_word and propagating the error if the read operation failed.

Link https://lore.kernel.org/r/20231009-topic-dm9601_uninit_mdio_read-v2-1-f2fe39739b6c@gmail.com open here

Signed-off-by Javier Carrasco <[email protected]>

Reported-and-tested-by [email protected]

Acked-by Peter Korsgaard <[email protected]>

Fixes d0374f4f9c35cdfbee0 ("USB: Davicom DM9601 usbnet driver")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/usb/dm9601.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/net/usb/dm9601.c +6 -1

@@ -222,13 +222,18 @@ static int dm9601_mdio_read(struct net_d
 	struct usbnet *dev = netdev_priv(netdev);
 
 	__le16 res;
+	int err;
 
 	if (phy_id) {
 		netdev_dbg(dev->net, "Only internal phy supported\n");
 		return 0;
 	}
 
-	dm_read_shared_word(dev, 1, loc, &res);
+	err = dm_read_shared_word(dev, 1, loc, &res);
+	if (err < 0) {
+		netdev_err(dev->net, "MDIO read error: %d\n", err);
+		return err;
+	}
 
 	netdev_dbg(dev->net,
 		   "dm9601_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\n",

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #109 lore raw

PATCH 104/191 usb: dwc3: Soft reset phy on probe for host

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thinh Nguyen <[email protected]>

commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b upstream.

When there's phy initialization, we need to initiate a soft-reset sequence. That's done through USBCMD.HCRST in the xHCI driver and its initialization, However, the dwc3 driver may modify core configs before the soft-reset. This may result in some connection instability. So, ensure the phy is ready before the controller updates the GCTL.PRTCAPDIR or other settings by issuing phy soft-reset.

Note that some host-mode configurations may not expose device registers to initiate the controller soft-reset (via DCTL.CoreSftRst). So we reset through GUSB3PIPECTL and GUSB2PHYCFG instead.

Link https://lore.kernel.org/r/70aea513215d273669152696cc02b20ddcdb6f1a.1694564261.git.Thinh.Nguyen@synopsys.com open here

Fixes e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")

Reported-by Kenta Sato <[email protected]>

Closes https://lore.kernel.org/linux-usb/[email protected]/ open here

Signed-off-by Thinh Nguyen <[email protected]>

Tested-by Kenta Sato <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/dwc3/core.c |   39 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

drivers/usb/dwc3/core.c +38 -1

@@ -279,9 +279,46 @@ int dwc3_core_soft_reset(struct dwc3 *dw
 	 * XHCI driver will reset the host block. If dwc3 was configured for
 	 * host-only mode or current role is host, then we can return early.
 	 */
-	if (dwc->dr_mode == USB_DR_MODE_HOST || dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
+	if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
 		return 0;
 
+	/*
+	 * If the dr_mode is host and the dwc->current_dr_role is not the
+	 * corresponding DWC3_GCTL_PRTCAP_HOST, then the dwc3_core_init_mode
+	 * isn't executed yet. Ensure the phy is ready before the controller
+	 * updates the GCTL.PRTCAPDIR or other settings by soft-resetting
+	 * the phy.
+	 *
+	 * Note: GUSB3PIPECTL[n] and GUSB2PHYCFG[n] are port settings where n
+	 * is port index. If this is a multiport host, then we need to reset
+	 * all active ports.
+	 */
+	if (dwc->dr_mode == USB_DR_MODE_HOST) {
+		u32 usb3_port;
+		u32 usb2_port;
+
+		usb3_port = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
+		usb3_port |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
+		dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port);
+
+		usb2_port = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+		usb2_port |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
+		dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port);
+
+		/* Small delay for phy reset assertion */
+		usleep_range(1000, 2000);
+
+		usb3_port &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
+		dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port);
+
+		usb2_port &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
+		dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port);
+
+		/* Wait for clock synchronization */
+		msleep(50);
+		return 0;
+	}
+
 	reg = dwc3_readl(dwc->regs, DWC3_DCTL);
 	reg |= DWC3_DCTL_CSFTRST;
 	reg &= ~DWC3_DCTL_RUN_STOP;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #110 lore raw

PATCH 105/191 usb: cdns3: Modify the return value of cdns_set_active () to void when CONFIG_PM_SLEEP is disabled

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xiaolei Wang <[email protected]>

commit 9f35d612da5592f1bf1cae44ec1e023df37bea12 upstream.

The return type of cdns_set_active () is inconsistent depending on whether CONFIG_PM_SLEEP is enabled, so the return value is modified to void type.

Reported-by Pavel Machek <[email protected]>

Closes https://lore.kernel.org/all/[email protected]/ open here

Fixes 2319b9c87fe2 ("usb: cdns3: Put the cdns set active part outside the spin lock")

Signed-off-by Xiaolei Wang <[email protected]>

Reviewed-by Pavel Machek <[email protected]>

Reviewed-by Roger Quadros <[email protected]>

Acked-by Peter Chen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/cdns3/core.h |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/usb/cdns3/core.h +1 -2

@@ -131,8 +131,7 @@ void cdns_set_active(struct cdns *cdns,
 #else /* CONFIG_PM_SLEEP */
 static inline int cdns_resume(struct cdns *cdns)
 { return 0; }
-static inline int cdns_set_active(struct cdns *cdns, u8 set_active)
-{ return 0; }
+static inline void cdns_set_active(struct cdns *cdns, u8 set_active) { }
 static inline int cdns_suspend(struct cdns *cdns)
 { return 0; }
 #endif /* CONFIG_PM_SLEEP */

Greg Kroah-Hartman

author maintainer

2023-10-16 14:50 UTC #111 lore raw

PATCH 106/191 usb: hub: Guard against accesses to uninitialized BOS descriptors

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ricardo Cañuelo <[email protected]>

commit f74a7afc224acd5e922c7a2e52244d891bbe44ee upstream.

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.

Signed-off-by Ricardo Cañuelo <[email protected]>

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/hub.c |   25 ++++++++++++++++++++++---
 drivers/usb/core/hub.h |    2 +-
 2 files changed, 23 insertions(+), 4 deletions(-)

drivers/usb/core/hub.c +22 -3

@@ -151,6 +151,10 @@ int usb_device_supports_lpm(struct usb_d
 	if (udev->quirks & USB_QUIRK_NO_LPM)
 		return 0;
 
+	/* Skip if the device BOS descriptor couldn't be read */
+	if (!udev->bos)
+		return 0;
+
 	/* USB 2.1 (and greater) devices indicate LPM support through
 	 * their USB 2.0 Extended Capabilities BOS descriptor.
 	 */

@@ -327,6 +331,10 @@ static void usb_set_lpm_parameters(struc
 	if (!udev->lpm_capable || udev->speed < USB_SPEED_SUPER)
 		return;
 
+	/* Skip if the device BOS descriptor couldn't be read */
+	if (!udev->bos)
+		return;
+
 	hub = usb_hub_to_struct_hub(udev->parent);
 	/* It doesn't take time to transition the roothub into U0, since it
 	 * doesn't have an upstream link.

@@ -2720,13 +2728,17 @@ out_authorized:
 static enum usb_ssp_rate get_port_ssp_rate(struct usb_device *hdev,
 					   u32 ext_portstatus)
 {
-	struct usb_ssp_cap_descriptor *ssp_cap = hdev->bos->ssp_cap;
+	struct usb_ssp_cap_descriptor *ssp_cap;
 	u32 attr;
 	u8 speed_id;
 	u8 ssac;
 	u8 lanes;
 	int i;
 
+	if (!hdev->bos)
+		goto out;
+
+	ssp_cap = hdev->bos->ssp_cap;
 	if (!ssp_cap)
 		goto out;

@@ -4244,8 +4256,15 @@ static void usb_enable_link_state(struct
 		enum usb3_link_state state)
 {
 	int timeout;
-	__u8 u1_mel = udev->bos->ss_cap->bU1devExitLat;
-	__le16 u2_mel = udev->bos->ss_cap->bU2DevExitLat;
+	__u8 u1_mel;
+	__le16 u2_mel;
+
+	/* Skip if the device BOS descriptor couldn't be read */
+	if (!udev->bos)
+		return;
+
+	u1_mel = udev->bos->ss_cap->bU1devExitLat;
+	u2_mel = udev->bos->ss_cap->bU2DevExitLat;
 
 	/* If the device says it doesn't have *any* exit latency to come out of
 	 * U1 or U2, it's probably lying.  Assume it doesn't implement that link

drivers/usb/core/hub.h +1 -1

@@ -153,7 +153,7 @@ static inline int hub_is_superspeedplus(
 {
 	return (hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS &&
 		le16_to_cpu(hdev->descriptor.bcdUSB) >= 0x0310 &&
-		hdev->bos->ssp_cap);
+		hdev->bos && hdev->bos->ssp_cap);
 }
 
 static inline unsigned hub_power_on_good_delay(struct usb_hub *hub)

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #112 lore raw

PATCH 107/191 usb: musb: Get the musb_qh poniter after musb_giveback

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xingxing Luo <[email protected]>

commit 33d7e37232155aadebe4145dcc592f00dabd7a2b upstream.

When multiple threads are performing USB transmission, musb->lock will be unlocked when musb_giveback is executed. At this time, qh may be released in the dequeue process in other threads, resulting in a wild pointer, so it needs to be here get qh again, and judge whether qh is NULL, and when dequeue, you need to set qh to NULL.

Fixes dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")

Signed-off-by Xingxing Luo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/musb/musb_host.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/usb/musb/musb_host.c +8 -1

index a02c29216955..bc4507781167 100644
@@ -321,10 +321,16 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb,
 	musb_giveback(musb, urb, status);
 	qh->is_ready = ready;
 
+	/*
+	 * musb->lock had been unlocked in musb_giveback, so qh may
+	 * be freed, need to get it again
+	 */
+	qh = musb_ep_get_qh(hw_ep, is_in);
+
 	/* reclaim resources (and bandwidth) ASAP; deschedule it, and
 	 * invalidate qh as soon as list_empty(&hep->urb_list)
 	 */
-	if (list_empty(&qh->hep->urb_list)) {
+	if (qh && list_empty(&qh->hep->urb_list)) {
 		struct list_head	*head;
 		struct dma_controller	*dma = musb->dma_controller;

@@ -2398,6 +2404,7 @@ static int musb_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
 		 * and its URB list has emptied, recycle this qh.
 		 */
 		if (ready && list_empty(&qh->hep->urb_list)) {
+			musb_ep_set_qh(qh->hw_ep, is_in, NULL);
 			qh->hep->hcpriv = NULL;
 			list_del(&qh->ring);
 			kfree(qh);

Signature · 1 line

2.42.0

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #113 lore raw

PATCH 108/191 usb: musb: Modify the "HWVers" register address

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xingxing Luo <[email protected]>

commit 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 upstream.

musb HWVers rgister address is not 0x69, if we operate the wrong address 0x69, it will cause a kernel crash, because there is no register corresponding to this address in the additional control register of musb. In fact, HWVers has been defined in musb_register.h, and the name is "MUSB_HWVERS", so We need to use this macro instead of 0x69.

Fixes c2365ce5d5a0 ("usb: musb: replace hard coded registers with defines")

Signed-off-by Xingxing Luo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/musb/musb_debugfs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/musb/musb_debugfs.c +1 -1

@@ -39,7 +39,7 @@ static const struct musb_register_map mu
 	{ "IntrUsbE",	MUSB_INTRUSBE,	8 },
 	{ "DevCtl",	MUSB_DEVCTL,	8 },
 	{ "VControl",	0x68,		32 },
-	{ "HWVers",	0x69,		16 },
+	{ "HWVers",	MUSB_HWVERS,	16 },
 	{ "LinkInfo",	MUSB_LINKINFO,	8 },
 	{ "VPLen",	MUSB_VPLEN,	8 },
 	{ "HS_EOF1",	MUSB_HS_EOF1,	8 },

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #114 lore raw

PATCH 109/191 iio: pressure: bmp280: Fix NULL pointer exception

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Phil Elwell <[email protected]>

commit 85dfb43bf69281adb1f345dfd9a39faf2e5a718d upstream.

The bmp085 EOC IRQ support is optional, but the driver's common probe function queries the IRQ properties whether or not it exists, which can trigger a NULL pointer exception. Avoid any exception by making the query conditional on the possession of a valid IRQ.

Fixes aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")

Signed-off-by Phil Elwell <[email protected]>

Reviewed-by Linus Walleij <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/pressure/bmp280-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/iio/pressure/bmp280-core.c +1 -1

@@ -2179,7 +2179,7 @@ int bmp280_common_probe(struct device *d
 	 * however as it happens, the BMP085 shares the chip ID of BMP180
 	 * so we look for an IRQ if we have that.
 	 */
-	if (irq > 0 || (chip_id  == BMP180_CHIP_ID)) {
+	if (irq > 0 && (chip_id  == BMP180_CHIP_ID)) {
 		ret = bmp085_fetch_eoc_irq(dev, name, irq, data);
 		if (ret)
 			return ret;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:51 UTC #115 lore raw

PATCH 110/191 iio: imu: bno055: Fix missing Kconfig dependencies

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jonathan Cameron <[email protected]>

commit c9b9cfe7d342683f624a89c3b617be18aff879e8 upstream.

This driver uses IIO triggered buffers so it needs to select them in Kconfig.

on riscv-32bit:

/opt/crosstool/gcc-13.2.0-nolibc/riscv32-linux/bin/riscv32-linux-ld: drivers/iio/imu/bno055/bno055.o: in function `.L367':
bno055.c:(.text+0x2c96): undefined reference to `devm_iio_triggered_buffer_setup_ext'

Reported-by Randy Dunlap <[email protected]>

Closes https://lore.kernel.org/linux-next/[email protected]/ open here

Fixes 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver")

Cc Andrea Merello <[email protected]>

Acked-by Randy Dunlap <[email protected]>

Tested-by Randy Dunlap <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/imu/bno055/Kconfig |    2 ++
 1 file changed, 2 insertions(+)

drivers/iio/imu/bno055/Kconfig +2 -0

@@ -2,6 +2,8 @@
 
 config BOSCH_BNO055
 	tristate
+	select IIO_BUFFER
+	select IIO_TRIGGERED_BUFFER
 
 config BOSCH_BNO055_SERIAL
 	tristate "Bosch BNO055 attached via UART"

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #116 lore raw

PATCH 111/191 iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data()

[1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffer.c#L1189
[2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c#L198

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tzung-Bi Shih <[email protected]>

commit 7771c8c80d62ad065637ef74ed2962983f6c5f6d upstream.

cros_ec_sensors_push_data() reads indio_dev->active_scan_mask and calls iio_push_to_buffers_with_timestamp() without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode right before cros_ec_sensors_push_data() accesses them.

An use-after-free on indio_dev->active_scan_mask was observed. The call trace:
[...]
_find_next_bit
cros_ec_sensors_push_data
cros_ec_sensorhub_event
blocking_notifier_call_chain
cros_ec_irq_thread

It was caused by a race condition: one thread just freed active_scan_mask at [1]; while another thread tried to access the memory at [2].

Fix it by calling iio_device_claim_buffer_mode() to ensure the indio_dev can't exit buffer mode during cros_ec_sensors_push_data().

Fixes aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO")

Signed-off-by Tzung-Bi Shih <[email protected]>

Reviewed-by Guenter Roeck <[email protected]>

Reviewed-by Stephen Boyd <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +5 -1

@@ -190,8 +190,11 @@ int cros_ec_sensors_push_data(struct iio
 	/*
 	 * Ignore samples if the buffer is not set: it is needed if the ODR is
 	 * set but the buffer is not enabled yet.
+	 *
+	 * Note: iio_device_claim_buffer_mode() returns -EBUSY if the buffer
+	 * is not enabled.
 	 */
-	if (!iio_buffer_enabled(indio_dev))
+	if (iio_device_claim_buffer_mode(indio_dev) < 0)
 		return 0;
 
 	out = (s16 *)st->samples;

@@ -210,6 +213,7 @@ int cros_ec_sensors_push_data(struct iio
 	iio_push_to_buffers_with_timestamp(indio_dev, st->samples,
 					   timestamp + delta);
 
+	iio_device_release_buffer_mode(indio_dev);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(cros_ec_sensors_push_data);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #117 lore raw

PATCH 112/191 iio: adc: imx8qxp: Fix address for command buffer registers

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Philipp Rossak <[email protected]>

commit 850101b3598277794f92a9e363a60a66e0d42890 upstream.

The ADC Command Buffer Register high and low are currently pointing to the wrong address and makes it impossible to perform correct ADC measurements over all channels.

According to the datasheet of the imx8qxp the ADC_CMDL register starts at address 0x100 and the ADC_CMDH register starts at address 0x104.

This bug seems to be in the kernel since the introduction of this driver.

This can be observed by checking all raw voltages of the adc and they are all nearly identical:

cat /sys/bus/iio/devices/iio\:device0/in_voltage*_raw 3498
3494
3491
3491
3489
3490
3490
3490

Fixes 1e23dcaa1a9fa ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC")

Signed-off-by Philipp Rossak <[email protected]>

Acked-by Haibo Chen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/imx8qxp-adc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/iio/adc/imx8qxp-adc.c +2 -2

@@ -38,8 +38,8 @@
 #define IMX8QXP_ADR_ADC_FCTRL		0x30
 #define IMX8QXP_ADR_ADC_SWTRIG		0x34
 #define IMX8QXP_ADR_ADC_TCTRL(tid)	(0xc0 + (tid) * 4)
-#define IMX8QXP_ADR_ADC_CMDH(cid)	(0x100 + (cid) * 8)
-#define IMX8QXP_ADR_ADC_CMDL(cid)	(0x104 + (cid) * 8)
+#define IMX8QXP_ADR_ADC_CMDL(cid)	(0x100 + (cid) * 8)
+#define IMX8QXP_ADR_ADC_CMDH(cid)	(0x104 + (cid) * 8)
 #define IMX8QXP_ADR_ADC_RESFIFO		0x300
 #define IMX8QXP_ADR_ADC_TST		0xffc

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #118 lore raw

PATCH 113/191 iio: dac: ad3552r: Correct device IDs

Link https://lore.kernel.org/r/011f480220799fbfabdd53896f8a2f251ad995ad.1691091324.git.marcelo.schmitt1@gmail.com open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marcelo Schmitt <[email protected]>

commit 9a85653ed3b9a9b7b31d95a34b64b990c3d33ca1 upstream.

Device IDs for AD3542R and AD3552R were swapped leading to unintended collection of DAC output ranges being used for each design. Change device ID values so they are correct for each DAC chip.

Fixes 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support")

Signed-off-by Marcelo Schmitt <[email protected]>

Reported-by Chandrakant Minajigi <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/dac/ad3552r.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/iio/dac/ad3552r.c +2 -2

@@ -140,8 +140,8 @@ enum ad3552r_ch_vref_select {
 };
 
 enum ad3542r_id {
-	AD3542R_ID = 0x4008,
-	AD3552R_ID = 0x4009,
+	AD3542R_ID = 0x4009,
+	AD3552R_ID = 0x4008,
 };
 
 enum ad3552r_ch_output_range {

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #119 lore raw

PATCH 114/191 iio: admv1013: add mixer_vgate corner cases

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Antoniu Miclaus <[email protected]>

commit 287d998af24326b009ae0956820a3188501b34a0 upstream.

Include the corner cases in the computation of the MIXER_VGATE register value.

According to the datasheet: The MIXER_VGATE values follows the VCM such as, that for a 0V to 1.8V VCM, MIXER_VGATE = 23.89 VCM + 81, and for a > 1.8V to 2.6V VCM, MIXER_VGATE = 23.75 VCM + 1.25.

Fixes da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013")

Signed-off-by Antoniu Miclaus <[email protected]>

Reviewed-by Nuno Sa <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/frequency/admv1013.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/iio/frequency/admv1013.c +2 -2

@@ -351,9 +351,9 @@ static int admv1013_update_mixer_vgate(s
 	if (vcm < 0)
 		return vcm;
 
-	if (vcm < 1800000)
+	if (vcm <= 1800000)
 		mixer_vgate = (2389 * vcm / 1000000 + 8100) / 100;
-	else if (vcm > 1800000 && vcm < 2600000)
+	else if (vcm > 1800000 && vcm <= 2600000)
 		mixer_vgate = (2375 * vcm / 1000000 + 125) / 100;
 	else
 		return -EINVAL;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #120 lore raw

PATCH 115/191 iio: pressure: dps310: Adjust Timeout Settings

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lakshmi Yadlapati <[email protected]>

commit 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 upstream.

The DPS310 sensor chip has been encountering intermittent errors while reading the sensor device across various system designs. This issue causes the chip to become "stuck," preventing the indication of "ready" status for pressure and temperature measurements in the MEAS_CFG register.

To address this issue, this commit fixes the timeout settings to improve sensor stability:
- After sending a reset command to the chip, the timeout has been extended from 2.5 ms to 15 ms, aligning with the DPS310 specification.
- The read timeout value of the MEAS_CFG register has been adjusted from 20ms to 30ms to match the specification.

Signed-off-by Lakshmi Yadlapati <[email protected]>

Fixes 7b4ab4abcea4 ("iio: pressure: dps310: Reset chip after timeout")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/pressure/dps310.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/iio/pressure/dps310.c +4 -4

@@ -57,8 +57,8 @@
 #define  DPS310_RESET_MAGIC	0x09
 #define DPS310_COEF_BASE	0x10
 
-/* Make sure sleep time is <= 20ms for usleep_range */
-#define DPS310_POLL_SLEEP_US(t)		min(20000, (t) / 8)
+/* Make sure sleep time is <= 30ms for usleep_range */
+#define DPS310_POLL_SLEEP_US(t)		min(30000, (t) / 8)
 /* Silently handle error in rate value here */
 #define DPS310_POLL_TIMEOUT_US(rc)	((rc) <= 0 ? 1000000 : 1000000 / (rc))

@@ -402,8 +402,8 @@ static int dps310_reset_wait(struct dps3
 	if (rc)
 		return rc;
 
-	/* Wait for device chip access: 2.5ms in specification */
-	usleep_range(2500, 12000);
+	/* Wait for device chip access: 15ms in specification */
+	usleep_range(15000, 55000);
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #121 lore raw

PATCH 116/191 iio: pressure: ms5611: ms5611_prom_is_valid false negative bug

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexander Zangerl <[email protected]>

commit fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b upstream.

The ms5611 driver falsely rejects lots of MS5607-02BA03-50 chips with "PROM integrity check failed" because it doesn't accept a prom crc value of zero as legitimate.

According to the datasheet for this chip (and the manufacturer's application note about the PROM CRC), none of the possible values for the CRC are excluded - but the current code in ms5611_prom_is_valid() ends with

return crc_orig != 0x0000 && crc == crc_orig

Discussed with the driver author (Tomasz Duszynski) and he indicated that at that time (2015) he was dealing with some faulty chip samples which returned blank data under some circumstances and/or followed example code which indicated CRC zero being bad.

As far as I can tell this exception should not be applied anymore; We've got a few hundred custom boards here with this chip where large numbers of the prom have a legitimate CRC value 0, and do work fine, but which the current driver code wrongly rejects.

Signed-off-by Alexander Zangerl <[email protected]>

Fixes c0644160a8b5 ("iio: pressure: add support for MS5611 pressure and temperature sensor")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/pressure/ms5611_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/iio/pressure/ms5611_core.c +1 -1

@@ -76,7 +76,7 @@ static bool ms5611_prom_is_valid(u16 *pr
 
 	crc = (crc >> 12) & 0x000F;
 
-	return crc_orig != 0x0000 && crc == crc_orig;
+	return crc == crc_orig;
 }
 
 static int ms5611_read_prom(struct iio_dev *indio_dev)

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #122 lore raw

PATCH 117/191 iio: adc: ad7192: Correct reference voltage

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alisa-Dariana Roman <[email protected]>

commit 7e7dcab620cd6d34939f615cac63fc0ef7e81c72 upstream.

The avdd and the reference voltage are two different sources but the reference voltage was assigned according to the avdd supply.

Add vref regulator structure and set the reference voltage according to the vref supply from the devicetree.

In case vref supply is missing, reference voltage is set according to the avdd supply for compatibility with old devicetrees.

Fixes b581f748cce0 ("staging: iio: adc: ad7192: move out of staging")

Signed-off-by Alisa-Dariana Roman <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/ad7192.c |   29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

drivers/iio/adc/ad7192.c +25 -4

@@ -177,6 +177,7 @@ struct ad7192_chip_info {
 struct ad7192_state {
 	const struct ad7192_chip_info	*chip_info;
 	struct regulator		*avdd;
+	struct regulator		*vref;
 	struct clk			*mclk;
 	u16				int_vref_mv;
 	u32				fclk;

@@ -1014,10 +1015,30 @@ static int ad7192_probe(struct spi_devic
 	if (ret)
 		return dev_err_probe(&spi->dev, ret, "Failed to enable specified DVdd supply\n");
 
-	ret = regulator_get_voltage(st->avdd);
-	if (ret < 0) {
-		dev_err(&spi->dev, "Device tree error, reference voltage undefined\n");
-		return ret;
+	st->vref = devm_regulator_get_optional(&spi->dev, "vref");
+	if (IS_ERR(st->vref)) {
+		if (PTR_ERR(st->vref) != -ENODEV)
+			return PTR_ERR(st->vref);
+
+		ret = regulator_get_voltage(st->avdd);
+		if (ret < 0)
+			return dev_err_probe(&spi->dev, ret,
+					     "Device tree error, AVdd voltage undefined\n");
+	} else {
+		ret = regulator_enable(st->vref);
+		if (ret) {
+			dev_err(&spi->dev, "Failed to enable specified Vref supply\n");
+			return ret;
+		}
+
+		ret = devm_add_action_or_reset(&spi->dev, ad7192_reg_disable, st->vref);
+		if (ret)
+			return ret;
+
+		ret = regulator_get_voltage(st->vref);
+		if (ret < 0)
+			return dev_err_probe(&spi->dev, ret,
+					     "Device tree error, Vref voltage undefined\n");
 	}
 	st->int_vref_mv = ret / 1000;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #123 lore raw

PATCH 118/191 iio: addac: Kconfig: update ad74413r selections

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Antoniu Miclaus <[email protected]>

commit b120dd3a15582fb7a959cecb05e4d9814fcba386 upstream.

Building ad74413r without selecting IIO_BUFFER and IIO_TRIGGERED_BUFFER generates error with respect to the iio trigger functions that are used within the driver.
Update the Kconfig accordingly.

Fixes fea251b6a5db ("iio: addac: add AD74413R driver")

Signed-off-by Antoniu Miclaus <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/addac/Kconfig |    2 ++
 1 file changed, 2 insertions(+)

drivers/iio/addac/Kconfig +2 -0

@@ -24,6 +24,8 @@ config AD74413R
 	depends on GPIOLIB && SPI
 	select REGMAP_SPI
 	select CRC8
+	select IIO_BUFFER
+	select IIO_TRIGGERED_BUFFER
 	help
 	  Say yes here to build support for Analog Devices AD74412R/AD74413R
 	  quad-channel software configurable input/output solution.

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #124 lore raw

PATCH 119/191 media: subdev: Dont report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit 4800021c630210ea0b19434a1fb56ab16385f2b3 upstream.

Since the stream API is still experimental it is currently locked away behind the internal, default disabled, v4l2_subdev_enable_streams_api flag.

Advertising V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled confuses userspace. E.g. it causes the following libcamera error:

ERROR SimplePipeline simple.cpp:1497 Failed to reset routes for
/dev/v4l-subdev1: Inappropriate ioctl for device

Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled to avoid problems like this.

Reported-by Dennis Bonke <[email protected]>

Fixes 9a6b5bf4c1bb ("media: add V4L2_SUBDEV_CAP_STREAMS")

Cc [email protected] # for >= 6.3

Acked-by Sakari Ailus <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/v4l2-core/v4l2-subdev.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/media/v4l2-core/v4l2-subdev.c +7 -0

@@ -517,6 +517,13 @@ static long subdev_do_ioctl(struct file
 				       V4L2_SUBDEV_CLIENT_CAP_STREAMS;
 	int rval;
 
+	/*
+	 * If the streams API is not enabled, remove V4L2_SUBDEV_CAP_STREAMS.
+	 * Remove this when the API is no longer experimental.
+	 */
+	if (!v4l2_subdev_enable_streams_api)
+		streams_subdev = false;
+
 	switch (cmd) {
 	case VIDIOC_SUBDEV_QUERYCAP: {
 		struct v4l2_subdev_capability *cap = arg;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #125 lore raw

PATCH 120/191 arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Macpaul Lin <[email protected]>

commit 25389c03c21c9587dd21c768d1cbfa514a3ca211 upstream.

The onboard dram of mt8195-demo board is 8GB.

Cc [email protected] # 6.1, 6.4, 6.5

Fixes 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board")

Signed-off-by Macpaul Lin <[email protected]>

Reviewed-by AngeloGioacchino Del Regno <[email protected]>

Signed-off-by AngeloGioacchino Del Regno <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/boot/dts/mediatek/mt8195-demo.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/boot/dts/mediatek/mt8195-demo.dts +1 -1

@@ -48,7 +48,7 @@
 
 	memory@40000000 {
 		device_type = "memory";
-		reg = <0 0x40000000 0 0x80000000>;
+		reg = <0 0x40000000 0x2 0x00000000>;
 	};
 
 	reserved-memory {

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #126 lore raw

PATCH 121/191 arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Macpaul Lin <[email protected]>

commit 6cd2a30b96a4b2d270bc1ef1611429dc3fa63327 upstream.

The dts file of the MediaTek MT8195 demo board has been updated to include new reserved memory regions.
These reserved memory regions are:
- SCP
- VPU,
- Sound DMA
- APU.

These regions are defined with the "shared-dma-pool" compatible property. In addition, the existing reserved memory regions have been reordered by their addresses to improve readability and maintainability of the DTS file.

Cc [email protected] # 6.1, 6.4, 6.5

Fixes e4a417520101 ("arm64: dts: mediatek: mt8195-demo: fix the memory size of node secmon")

Signed-off-by Macpaul Lin <[email protected]>

Reviewed-by AngeloGioacchino Del Regno <[email protected]>

Signed-off-by AngeloGioacchino Del Regno <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/boot/dts/mediatek/mt8195-demo.dts |   37 +++++++++++++++++++++------
 1 file changed, 30 insertions(+), 7 deletions(-)

arch/arm64/boot/dts/mediatek/mt8195-demo.dts +30 -7

@@ -56,13 +56,8 @@
 		#size-cells = <2>;
 		ranges;
 
-		/* 2 MiB reserved for ARM Trusted Firmware (BL31) */
-		bl31_secmon_reserved: secmon@54600000 {
-			no-map;
-			reg = <0 0x54600000 0x0 0x200000>;
-		};
-
-		/* 12 MiB reserved for OP-TEE (BL32)
+		/*
+		 * 12 MiB reserved for OP-TEE (BL32)
 		 * +-----------------------+ 0x43e0_0000
 		 * |      SHMEM 2MiB       |
 		 * +-----------------------+ 0x43c0_0000

@@ -75,6 +70,34 @@
 			no-map;
 			reg = <0 0x43200000 0 0x00c00000>;
 		};
+
+		scp_mem: memory@50000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x50000000 0 0x2900000>;
+			no-map;
+		};
+
+		vpu_mem: memory@53000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x53000000 0 0x1400000>; /* 20 MB */
+		};
+
+		/* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+		bl31_secmon_mem: memory@54600000 {
+			no-map;
+			reg = <0 0x54600000 0x0 0x200000>;
+		};
+
+		snd_dma_mem: memory@60000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x60000000 0 0x1100000>;
+			no-map;
+		};
+
+		apu_mem: memory@62000000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x62000000 0 0x1400000>; /* 20 MB */
+		};
 	};
 };

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #127 lore raw

PATCH 122/191 drm: Do not overrun array in drm_gem_get_pages()

Link https://lore.kernel.org/lkml/[email protected]/ open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matthew Wilcox (Oracle) <[email protected]>

commit b7fd68ab1538e3adb665670414bea440f399fda9 upstream.

If the shared memory object is larger than the DRM object that it backs, we can overrun the page array. Limit the number of pages we install from each folio to prevent this.

Signed-off-by "Matthew Wilcox (Oracle)" <[email protected]>

Reported-by Oleksandr Natalenko <[email protected]>

Tested-by Oleksandr Natalenko <[email protected]>

Fixes 3291e09a4638 ("drm: convert drm_gem_put_pages() to use a folio_batch")

Cc [email protected] # 6.5.x

Signed-off-by Maxime Ripard <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/drm_gem.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/gpu/drm/drm_gem.c +4 -2

@@ -537,7 +537,7 @@ struct page **drm_gem_get_pages(struct d
 	struct page **pages;
 	struct folio *folio;
 	struct folio_batch fbatch;
-	int i, j, npages;
+	long i, j, npages;
 
 	if (WARN_ON(!obj->filp))
 		return ERR_PTR(-EINVAL);

@@ -561,11 +561,13 @@ struct page **drm_gem_get_pages(struct d
 
 	i = 0;
 	while (i < npages) {
+		long nr;
 		folio = shmem_read_folio_gfp(mapping, i,
 				mapping_gfp_mask(mapping));
 		if (IS_ERR(folio))
 			goto fail;
-		for (j = 0; j < folio_nr_pages(folio); j++, i++)
+		nr = min(npages - i, folio_nr_pages(folio));
+		for (j = 0; j < nr; j++, i++)
 			pages[i] = folio_file_page(folio, i);
 
 		/* Make sure shmem keeps __GFP_DMA32 allocated pages in the

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #128 lore raw

PATCH 123/191 drm/tiny: correctly print `struct resource *` on error

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joey Gouly <[email protected]>

commit c1165df2be2fffe3adeeaa68f4ee4325108c5e4e upstream.

The res variable is already a struct resource *, don't take the address of it.

Fixes incorrect output:

	simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [??? 0xffff4be88a387d00-0xfffffefffde0a240 flags 0x0]: -16

To be correct:

	simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [mem 0x9e20dc000-0x9e307bfff flags 0x200]: -16

Signed-off-by Joey Gouly <[email protected]>

Fixes 9a10c7e6519b ("drm/simpledrm: Add support for system memory framebuffers")

Cc Thomas Zimmermann <[email protected]>

Cc Thierry Reding <[email protected]>

Cc Javier Martinez Canillas <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Cc <[email protected]> # v6.3+

Reviewed-by Thomas Zimmermann <[email protected]>

Signed-off-by Thomas Zimmermann <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/tiny/simpledrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/tiny/simpledrm.c +1 -1

index ff86ba1ae1b8..8ea120eb8674 100644
@@ -745,7 +745,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 
 		ret = devm_aperture_acquire_from_firmware(dev, res->start, resource_size(res));
 		if (ret) {
-			drm_err(dev, "could not acquire memory range %pr: %d\n", &res, ret);
+			drm_err(dev, "could not acquire memory range %pr: %d\n", res, ret);
 			return ERR_PTR(ret);
 		}

Signature · 1 line

2.42.0

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #129 lore raw

PATCH 124/191 drm/atomic-helper: relax unregistered connector check

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Simon Ser <[email protected]>

commit 2b7947bd32e243c52870d54141d3b4ea6775e63d upstream.

The driver might pull connectors which weren't submitted by user-space into the atomic state. For instance, intel_dp_mst_atomic_master_trans_check() pulls in connectors sharing the same DP-MST stream. However, if the connector is unregistered, this later fails with:

    [  559.425658] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CONNECTOR:378:DP-7] is not registered

Skip the unregistered connector check to allow user-space to turn off connectors one-by-one.

See this wlroots issue:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407

Previous discussion:
https://lore.kernel.org/intel-gfx/[email protected]/

Signed-off-by Simon Ser <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Reviewed-by Ville Syrjälä <[email protected]>

Reviewed-by Lyude Paul <[email protected]>

Cc Jani Nikula <[email protected]>

Cc Imre Deak <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/drm_atomic_helper.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

drivers/gpu/drm/drm_atomic_helper.c +13 -4

@@ -290,7 +290,8 @@ static int
 update_connector_routing(struct drm_atomic_state *state,
 			 struct drm_connector *connector,
 			 struct drm_connector_state *old_connector_state,
-			 struct drm_connector_state *new_connector_state)
+			 struct drm_connector_state *new_connector_state,
+			 bool added_by_user)
 {
 	const struct drm_connector_helper_funcs *funcs;
 	struct drm_encoder *new_encoder;

@@ -339,9 +340,13 @@ update_connector_routing(struct drm_atom
 	 * there's a chance the connector may have been destroyed during the
 	 * process, but it's better to ignore that then cause
 	 * drm_atomic_helper_resume() to fail.
+	 *
+	 * Last, we want to ignore connector registration when the connector
+	 * was not pulled in the atomic state by user-space (ie, was pulled
+	 * in by the driver, e.g. when updating a DP-MST stream).
 	 */
 	if (!state->duplicated && drm_connector_is_unregistered(connector) &&
-	    crtc_state->active) {
+	    added_by_user && crtc_state->active) {
 		drm_dbg_atomic(connector->dev,
 			       "[CONNECTOR:%d:%s] is not registered\n",
 			       connector->base.id, connector->name);

@@ -620,7 +625,10 @@ drm_atomic_helper_check_modeset(struct d
 	struct drm_connector *connector;
 	struct drm_connector_state *old_connector_state, *new_connector_state;
 	int i, ret;
-	unsigned int connectors_mask = 0;
+	unsigned int connectors_mask = 0, user_connectors_mask = 0;
+
+	for_each_oldnew_connector_in_state(state, connector, old_connector_state, new_connector_state, i)
+		user_connectors_mask |= BIT(i);
 
 	for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
 		bool has_connectors =

@@ -685,7 +693,8 @@ drm_atomic_helper_check_modeset(struct d
 		 */
 		ret = update_connector_routing(state, connector,
 					       old_connector_state,
-					       new_connector_state);
+					       new_connector_state,
+					       BIT(i) & user_connectors_mask);
 		if (ret)
 			return ret;
 		if (old_connector_state->crtc) {

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #130 lore raw

PATCH 125/191 drm/amdgpu: add missing NULL check

Link https://gitlab.freedesktop.org/drm/amd/-/issues/2902

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christian König <[email protected]>

commit ff89f064dca38e2203790bf876cc7756b8ab2961 upstream.

bo->tbo.resource can easily be NULL here.

Signed-off-by Christian König <[email protected]>

Reviewed-by Alex Deucher <[email protected]>

CC [email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/amd/amdgpu/amdgpu_object.h +1 -1

@@ -250,7 +250,7 @@ static inline bool amdgpu_bo_in_cpu_visi
 	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
 	struct amdgpu_res_cursor cursor;
 
-	if (bo->tbo.resource->mem_type != TTM_PL_VRAM)
+	if (!bo->tbo.resource || bo->tbo.resource->mem_type != TTM_PL_VRAM)
 		return false;
 
 	amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &cursor);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #131 lore raw

PATCH 126/191 drm/amd/display: Dont set dpms_off for seamless boot

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Miess <[email protected]>

commit 23645bca98304a2772f0de96f97370dd567d0ae6 upstream.

[Why]
eDPs fail to light up with seamless boot enabled

[How]
When seamless boot is enabled don't configure dpms_off in disable_vbios_mode_if_required.

Reviewed-by Charlene Liu <[email protected]>

Cc Mario Limonciello <[email protected]>

Cc Alex Deucher <[email protected]>

Acked-by Tom Chung <[email protected]>

Signed-off-by Daniel Miess <[email protected]>

Tested-by Daniel Wheeler <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/display/dc/core/dc.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/gpu/drm/amd/display/dc/core/dc.c +3 -0

@@ -1263,6 +1263,9 @@ static void disable_vbios_mode_if_requir
 		if (stream == NULL)
 			continue;
 
+		if (stream->apply_seamless_boot_optimization)
+			continue;
+
 		// only looking for first odm pipe
 		if (pipe->prev_odm_pipe)
 			continue;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #132 lore raw

PATCH 127/191 drm/vmwgfx: Keep a gem reference to user bos in surfaces

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zack Rusin <[email protected]>

commit 91398b413d03660fd5828f7b4abc64e884b98069 upstream.

Surfaces can be backed (i.e. stored in) memory objects (mob's) which are created and managed by the userspace as GEM buffers. Surfaces grab only a ttm reference which means that the gem object can be deleted underneath us, especially in cases where prime buffer export is used.

Make sure that all userspace surfaces which are backed by gem objects hold a gem reference to make sure they're not deleted before vmw surfaces are done with them, which fixes:

------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 2 PID: 2632 at lib/refcount.c:28 refcount_warn_saturate+0xfb/0x150
Modules linked in: overlay vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock snd_ens1371 snd_ac97_codec ac97_bus snd_pcm gameport>
CPU: 2 PID: 2632 Comm: vmw_ref_count Not tainted 6.5.0-rc2-vmwgfx #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
RIP: 0010:refcount_warn_saturate+0xfb/0x150
Code: eb 9e 0f b6 1d 8b 5b a6 01 80 fb 01 0f 87 ba e4 80 00 83 e3 01 75 89 48 c7 c7 c0 3c f9 a3 c6 05 6f 5b a6 01 01 e8 15 81 98 ff <0f> 0b e9 6f ff ff ff 0f b>
RSP: 0018:ffffbdc34344bba0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027
RDX: ffff960475ea1548 RSI: 0000000000000001 RDI: ffff960475ea1540
RBP: ffffbdc34344bba8 R08: 0000000000000003 R09: 65646e75203a745f
R10: ffffffffa5b32b20 R11: 72657466612d6573 R12: ffff96037d6a6400
R13: ffff9603484805b0 R14: 000000000000000b R15: ffff9603bed06060
FS:  00007f5fd8520c40(0000) GS:ffff960475e80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5fda755000 CR3: 000000010d012005 CR4: 00000000003706e0
Call Trace:
 <TASK>
 ? show_regs+0x6e/0x80
 ? refcount_warn_saturate+0xfb/0x150
 ? __warn+0x91/0x150
 ? refcount_warn_saturate+0xfb/0x150
 ? report_bug+0x19d/0x1b0
 ? handle_bug+0x46/0x80
 ? exc_invalid_op+0x1d/0x80
 ? asm_exc_invalid_op+0x1f/0x30
 ? refcount_warn_saturate+0xfb/0x150
 drm_gem_object_handle_put_unlocked+0xba/0x110 [drm]
 drm_gem_object_release_handle+0x6e/0x80 [drm]
 drm_gem_handle_delete+0x6a/0xc0 [drm]
 ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx]
 vmw_bo_unref_ioctl+0x33/0x40 [vmwgfx]
 drm_ioctl_kernel+0xbc/0x160 [drm]
 drm_ioctl+0x2d2/0x580 [drm]
 ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx]
 ? do_vmi_munmap+0xee/0x180
 vmw_generic_ioctl+0xbd/0x180 [vmwgfx]
 vmw_unlocked_ioctl+0x19/0x20 [vmwgfx]
 __x64_sys_ioctl+0x99/0xd0
 do_syscall_64+0x5d/0x90
 ? syscall_exit_to_user_mode+0x2a/0x50
 ? do_syscall_64+0x6d/0x90
 ? handle_mm_fault+0x16e/0x2f0
 ? exit_to_user_mode_prepare+0x34/0x170
 ? irqentry_exit_to_user_mode+0xd/0x20
 ? irqentry_exit+0x3f/0x50
 ? exc_page_fault+0x8e/0x190
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
RIP: 0033:0x7f5fda51aaff
Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 7>
RSP: 002b:00007ffd536a4d30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffd536a4de0 RCX: 00007f5fda51aaff
RDX: 00007ffd536a4de0 RSI: 0000000040086442 RDI: 0000000000000003
RBP: 0000000040086442 R08: 000055fa603ada50 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffd536a51b8
R13: 0000000000000003 R14: 000055fa5ebb4c80 R15: 00007f5fda90f040
 </TASK>
---[ end trace 0000000000000000 ]---

A lot of the analyis on the bug was done by Murray McAllister and Ian Forbes.

Reported-by Murray McAllister <[email protected]>

Cc Ian Forbes <[email protected]>

Signed-off-by Zack Rusin <[email protected]>

Fixes a950b989ea29 ("drm/vmwgfx: Do not drop the reference to the handle too soon")

Cc <[email protected]> # v6.2+

Reviewed-by Martin Krastev <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c       |    7 ++++---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h       |   17 ++++++++++++-----
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c  |    6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h      |    4 ++++
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |   10 ++++++----
 drivers/gpu/drm/vmwgfx/vmwgfx_gem.c      |   18 +++++++++++++++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c      |    6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c  |    2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   12 ++++++------
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |    4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |   31 ++++++++++++-------------------
 11 files changed, 68 insertions(+), 49 deletions(-)

drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +4 -3

@@ -34,6 +34,8 @@
 
 static void vmw_bo_release(struct vmw_bo *vbo)
 {
+	WARN_ON(vbo->tbo.base.funcs &&
+		kref_read(&vbo->tbo.base.refcount) != 0);
 	vmw_bo_unmap(vbo);
 	drm_gem_object_release(&vbo->tbo.base);
 }

@@ -497,7 +499,7 @@ static int vmw_user_bo_synccpu_release(s
 		if (!(flags & drm_vmw_synccpu_allow_cs)) {
 			atomic_dec(&vmw_bo->cpu_writers);
 		}
-		vmw_user_bo_unref(vmw_bo);
+		vmw_user_bo_unref(&vmw_bo);
 	}
 
 	return ret;

@@ -539,7 +541,7 @@ int vmw_user_bo_synccpu_ioctl(struct drm
 			return ret;
 
 		ret = vmw_user_bo_synccpu_grab(vbo, arg->flags);
-		vmw_user_bo_unref(vbo);
+		vmw_user_bo_unref(&vbo);
 		if (unlikely(ret != 0)) {
 			if (ret == -ERESTARTSYS || ret == -EBUSY)
 				return -EBUSY;

@@ -612,7 +614,6 @@ int vmw_user_bo_lookup(struct drm_file *
 	}
 
 	*out = to_vmw_bo(gobj);
-	ttm_bo_get(&(*out)->tbo);
 
 	return 0;
 }

drivers/gpu/drm/vmwgfx/vmwgfx_bo.h +12 -5

@@ -195,12 +195,19 @@ static inline struct vmw_bo *vmw_bo_refe
 	return buf;
 }
 
-static inline void vmw_user_bo_unref(struct vmw_bo *vbo)
+static inline struct vmw_bo *vmw_user_bo_ref(struct vmw_bo *vbo)
 {
-	if (vbo) {
-		ttm_bo_put(&vbo->tbo);
-		drm_gem_object_put(&vbo->tbo.base);
-	}
+	drm_gem_object_get(&vbo->tbo.base);
+	return vbo;
+}
+
+static inline void vmw_user_bo_unref(struct vmw_bo **buf)
+{
+	struct vmw_bo *tmp_buf = *buf;
+
+	*buf = NULL;
+	if (tmp_buf)
+		drm_gem_object_put(&tmp_buf->tbo.base);
 }
 
 static inline struct vmw_bo *to_vmw_bo(struct drm_gem_object *gobj)

drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c +3 -3

@@ -432,7 +432,7 @@ static int vmw_cotable_resize(struct vmw
 	 * for the new COTable. Initially pin the buffer object to make sure
 	 * we can use tryreserve without failure.
 	 */
-	ret = vmw_bo_create(dev_priv, &bo_params, &buf);
+	ret = vmw_gem_object_create(dev_priv, &bo_params, &buf);
 	if (ret) {
 		DRM_ERROR("Failed initializing new cotable MOB.\n");
 		goto out_done;

@@ -502,7 +502,7 @@ static int vmw_cotable_resize(struct vmw
 
 	vmw_resource_mob_attach(res);
 	/* Let go of the old mob. */
-	vmw_bo_unreference(&old_buf);
+	vmw_user_bo_unref(&old_buf);
 	res->id = vcotbl->type;
 
 	ret = dma_resv_reserve_fences(bo->base.resv, 1);

@@ -521,7 +521,7 @@ out_map_new:
 out_wait:
 	ttm_bo_unpin(bo);
 	ttm_bo_unreserve(bo);
-	vmw_bo_unreference(&buf);
+	vmw_user_bo_unref(&buf);
 
 out_done:
 	MKS_STAT_TIME_POP(MKSSTAT_KERN_COTABLE_RESIZE);

drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +4 -0

@@ -853,6 +853,10 @@ static inline bool vmw_resource_mob_atta
 /**
  * GEM related functionality - vmwgfx_gem.c
  */
+struct vmw_bo_params;
+int vmw_gem_object_create(struct vmw_private *vmw,
+			  struct vmw_bo_params *params,
+			  struct vmw_bo **p_vbo);
 extern int vmw_gem_object_create_with_handle(struct vmw_private *dev_priv,
 					     struct drm_file *filp,
 					     uint32_t size,

drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +6 -4

@@ -1151,7 +1151,7 @@ static int vmw_translate_mob_ptr(struct
 				 SVGAMobId *id,
 				 struct vmw_bo **vmw_bo_p)
 {
-	struct vmw_bo *vmw_bo;
+	struct vmw_bo *vmw_bo, *tmp_bo;
 	uint32_t handle = *id;
 	struct vmw_relocation *reloc;
 	int ret;

@@ -1164,7 +1164,8 @@ static int vmw_translate_mob_ptr(struct
 	}
 	vmw_bo_placement_set(vmw_bo, VMW_BO_DOMAIN_MOB, VMW_BO_DOMAIN_MOB);
 	ret = vmw_validation_add_bo(sw_context->ctx, vmw_bo);
-	vmw_user_bo_unref(vmw_bo);
+	tmp_bo = vmw_bo;
+	vmw_user_bo_unref(&tmp_bo);
 	if (unlikely(ret != 0))
 		return ret;

@@ -1206,7 +1207,7 @@ static int vmw_translate_guest_ptr(struc
 				   SVGAGuestPtr *ptr,
 				   struct vmw_bo **vmw_bo_p)
 {
-	struct vmw_bo *vmw_bo;
+	struct vmw_bo *vmw_bo, *tmp_bo;
 	uint32_t handle = ptr->gmrId;
 	struct vmw_relocation *reloc;
 	int ret;

@@ -1220,7 +1221,8 @@ static int vmw_translate_guest_ptr(struc
 	vmw_bo_placement_set(vmw_bo, VMW_BO_DOMAIN_GMR | VMW_BO_DOMAIN_VRAM,
 			     VMW_BO_DOMAIN_GMR | VMW_BO_DOMAIN_VRAM);
 	ret = vmw_validation_add_bo(sw_context->ctx, vmw_bo);
-	vmw_user_bo_unref(vmw_bo);
+	tmp_bo = vmw_bo;
+	vmw_user_bo_unref(&tmp_bo);
 	if (unlikely(ret != 0))
 		return ret;

drivers/gpu/drm/vmwgfx/vmwgfx_gem.c +15 -3

@@ -111,6 +111,20 @@ static const struct drm_gem_object_funcs
 	.vm_ops = &vmw_vm_ops,
 };
 
+int vmw_gem_object_create(struct vmw_private *vmw,
+			  struct vmw_bo_params *params,
+			  struct vmw_bo **p_vbo)
+{
+	int ret = vmw_bo_create(vmw, params, p_vbo);
+
+	if (ret != 0)
+		goto out_no_bo;
+
+	(*p_vbo)->tbo.base.funcs = &vmw_gem_object_funcs;
+out_no_bo:
+	return ret;
+}
+
 int vmw_gem_object_create_with_handle(struct vmw_private *dev_priv,
 				      struct drm_file *filp,
 				      uint32_t size,

@@ -126,12 +140,10 @@ int vmw_gem_object_create_with_handle(st
 		.pin = false
 	};
 
-	ret = vmw_bo_create(dev_priv, &params, p_vbo);
+	ret = vmw_gem_object_create(dev_priv, &params, p_vbo);
 	if (ret != 0)
 		goto out_no_bo;
 
-	(*p_vbo)->tbo.base.funcs = &vmw_gem_object_funcs;
-
 	ret = drm_gem_handle_create(filp, &(*p_vbo)->tbo.base, handle);
 out_no_bo:
 	return ret;

drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +3 -3

@@ -1471,8 +1471,8 @@ static int vmw_create_bo_proxy(struct dr
 	/* Reserve and switch the backing mob. */
 	mutex_lock(&res->dev_priv->cmdbuf_mutex);
 	(void) vmw_resource_reserve(res, false, true);
-	vmw_bo_unreference(&res->guest_memory_bo);
-	res->guest_memory_bo = vmw_bo_reference(bo_mob);
+	vmw_user_bo_unref(&res->guest_memory_bo);
+	res->guest_memory_bo = vmw_user_bo_ref(bo_mob);
 	res->guest_memory_offset = 0;
 	vmw_resource_unreserve(res, false, false, false, NULL, 0);
 	mutex_unlock(&res->dev_priv->cmdbuf_mutex);

@@ -1666,7 +1666,7 @@ static struct drm_framebuffer *vmw_kms_f
 err_out:
 	/* vmw_user_lookup_handle takes one ref so does new_fb */
 	if (bo)
-		vmw_user_bo_unref(bo);
+		vmw_user_bo_unref(&bo);
 	if (surface)
 		vmw_surface_unreference(&surface);

drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c +1 -1

@@ -451,7 +451,7 @@ int vmw_overlay_ioctl(struct drm_device
 
 	ret = vmw_overlay_update_stream(dev_priv, buf, arg, true);
 
-	vmw_user_bo_unref(buf);
+	vmw_user_bo_unref(&buf);
 
 out_unlock:
 	mutex_unlock(&overlay->mutex);

drivers/gpu/drm/vmwgfx/vmwgfx_resource.c +6 -6

@@ -141,7 +141,7 @@ static void vmw_resource_release(struct
 		if (res->coherent)
 			vmw_bo_dirty_release(res->guest_memory_bo);
 		ttm_bo_unreserve(bo);
-		vmw_bo_unreference(&res->guest_memory_bo);
+		vmw_user_bo_unref(&res->guest_memory_bo);
 	}
 
 	if (likely(res->hw_destroy != NULL)) {

@@ -338,7 +338,7 @@ static int vmw_resource_buf_alloc(struct
 		return 0;
 	}
 
-	ret = vmw_bo_create(res->dev_priv, &bo_params, &gbo);
+	ret = vmw_gem_object_create(res->dev_priv, &bo_params, &gbo);
 	if (unlikely(ret != 0))
 		goto out_no_bo;

@@ -457,11 +457,11 @@ void vmw_resource_unreserve(struct vmw_r
 			vmw_resource_mob_detach(res);
 			if (res->coherent)
 				vmw_bo_dirty_release(res->guest_memory_bo);
-			vmw_bo_unreference(&res->guest_memory_bo);
+			vmw_user_bo_unref(&res->guest_memory_bo);
 		}
 
 		if (new_guest_memory_bo) {
-			res->guest_memory_bo = vmw_bo_reference(new_guest_memory_bo);
+			res->guest_memory_bo = vmw_user_bo_ref(new_guest_memory_bo);
 
 			/*
 			 * The validation code should already have added a

@@ -551,7 +551,7 @@ out_no_reserve:
 	ttm_bo_put(val_buf->bo);
 	val_buf->bo = NULL;
 	if (guest_memory_dirty)
-		vmw_bo_unreference(&res->guest_memory_bo);
+		vmw_user_bo_unref(&res->guest_memory_bo);
 
 	return ret;
 }

@@ -727,7 +727,7 @@ int vmw_resource_validate(struct vmw_res
 		goto out_no_validate;
 	else if (!res->func->needs_guest_memory && res->guest_memory_bo) {
 		WARN_ON_ONCE(vmw_resource_mob_attached(res));
-		vmw_bo_unreference(&res->guest_memory_bo);
+		vmw_user_bo_unref(&res->guest_memory_bo);
 	}
 
 	return 0;

drivers/gpu/drm/vmwgfx/vmwgfx_shader.c +2 -2

@@ -180,7 +180,7 @@ static int vmw_gb_shader_init(struct vmw
 
 	res->guest_memory_size = size;
 	if (byte_code) {
-		res->guest_memory_bo = vmw_bo_reference(byte_code);
+		res->guest_memory_bo = vmw_user_bo_ref(byte_code);
 		res->guest_memory_offset = offset;
 	}
 	shader->size = size;

@@ -809,7 +809,7 @@ static int vmw_shader_define(struct drm_
 				    shader_type, num_input_sig,
 				    num_output_sig, tfile, shader_handle);
 out_bad_arg:
-	vmw_user_bo_unref(buffer);
+	vmw_user_bo_unref(&buffer);
 	return ret;
 }

drivers/gpu/drm/vmwgfx/vmwgfx_surface.c +12 ~~-19~~

@@ -686,9 +686,6 @@ static void vmw_user_surface_base_releas
 	    container_of(base, struct vmw_user_surface, prime.base);
 	struct vmw_resource *res = &user_srf->srf.res;
 
-	if (res->guest_memory_bo)
-		drm_gem_object_put(&res->guest_memory_bo->tbo.base);
-
 	*p_base = NULL;
 	vmw_resource_unreference(&res);
 }

@@ -855,23 +852,21 @@ int vmw_surface_define_ioctl(struct drm_
 	 * expect a backup buffer to be present.
 	 */
 	if (dev_priv->has_mob && req->shareable) {
-		uint32_t backup_handle;
-
-		ret = vmw_gem_object_create_with_handle(dev_priv,
-							file_priv,
-							res->guest_memory_size,
-							&backup_handle,
-							&res->guest_memory_bo);
+		struct vmw_bo_params params = {
+			.domain = VMW_BO_DOMAIN_SYS,
+			.busy_domain = VMW_BO_DOMAIN_SYS,
+			.bo_type = ttm_bo_type_device,
+			.size = res->guest_memory_size,
+			.pin = false
+		};
+
+		ret = vmw_gem_object_create(dev_priv,
+					    &params,
+					    &res->guest_memory_bo);
 		if (unlikely(ret != 0)) {
 			vmw_resource_unreference(&res);
 			goto out_unlock;
 		}
-		vmw_bo_reference(res->guest_memory_bo);
-		/*
-		 * We don't expose the handle to the userspace and surface
-		 * already holds a gem reference
-		 */
-		drm_gem_handle_delete(file_priv, backup_handle);
 	}
 
 	tmp = vmw_resource_reference(&srf->res);

@@ -1512,7 +1507,7 @@ vmw_gb_surface_define_internal(struct dr
 		if (ret == 0) {
 			if (res->guest_memory_bo->tbo.base.size < res->guest_memory_size) {
 				VMW_DEBUG_USER("Surface backup buffer too small.\n");
-				vmw_bo_unreference(&res->guest_memory_bo);
+				vmw_user_bo_unref(&res->guest_memory_bo);
 				ret = -EINVAL;
 				goto out_unlock;
 			} else {

@@ -1526,8 +1521,6 @@ vmw_gb_surface_define_internal(struct dr
 							res->guest_memory_size,
 							&backup_handle,
 							&res->guest_memory_bo);
-		if (ret == 0)
-			vmw_bo_reference(res->guest_memory_bo);
 	}
 
 	if (unlikely(ret != 0)) {

Greg Kroah-Hartman

author maintainer

2023-10-16 14:52 UTC #133 lore raw

PATCH 128/191 ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit c1ed72171ed580fbf159e703b77685aa4b0d0df5 upstream.

Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CBA has an ACPI DSDT table that describes IRQ 1 as ActiveLow while the kernel overrides it to EdgeHigh.

This prevents the keyboard from working. To fix this issue, add this laptop to the skip_override_table so that the kernel does not override IRQ 1.

Closes https://bugzilla.kernel.org/show_bug.cgi?id=217901

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/resource.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/acpi/resource.c +7 -0

@@ -440,6 +440,13 @@ static const struct dmi_system_id asus_l
 		},
 	},
 	{
+		.ident = "Asus ExpertBook B1402CBA",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_BOARD_NAME, "B1402CBA"),
+		},
+	},
+	{
 		.ident = "Asus ExpertBook B1502CBA",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #134 lore raw

PATCH 129/191 ACPI: resource: Add TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q to irq1_edge_low_force_override[]

Link https://laptopparts4less.frl/index.php?route=product/search&filter_name=GM6BG

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit f9b3ea02555e67e2e7bf95219953b88d122bd275 upstream.

The TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q are 3 GPU variants of a TongFang barebone design which is sold under various brand names.

The ACPI IRQ override for the keyboard IRQ must be used on these AMD Zen laptops in order for the IRQ to work.

Adjust the pcspecialist_laptop[] DMI match table for this:

1. Drop the sys-vendor match from the existing PCSpecialist Elimina Pro 16 entry for the GM6BGEQ (RTX3050 GPU) model so that it will also match the laptop when sold by other vendors such as hyperbook.pl.

2. Add board-name matches for the GM6BG5Q (RTX4050) and GM6B0Q (RTX4060) models.

Note the .ident values of the dmi_system_id structs are left unset since these are not used.

Reported-by Francesco <[email protected]>

Closes https://bugzilla.kernel.org/show_bug.cgi?id=217394

Link https://hyperbook.pl/en/content/14-hyperbook-drivers

Link https://linux-hardware.org/?probe=bfa70344e3

Link https://bbs.archlinuxcn.org/viewtopic.php?id=13313

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/resource.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

drivers/acpi/resource.c +13 -6

@@ -507,16 +507,23 @@ static const struct dmi_system_id mainge
 
 static const struct dmi_system_id pcspecialist_laptop[] = {
 	{
-		.ident = "PCSpecialist Elimina Pro 16 M",
-		/*
-		 * Some models have product-name "Elimina Pro 16 M",
-		 * others "GM6BGEQ". Match on board-name to match both.
-		 */
+		/* TongFang GM6BGEQ / PCSpecialist Elimina Pro 16 M, RTX 3050 */
 		.matches = {
-			DMI_MATCH(DMI_SYS_VENDOR, "PCSpecialist"),
 			DMI_MATCH(DMI_BOARD_NAME, "GM6BGEQ"),
 		},
 	},
+	{
+		/* TongFang GM6BG5Q, RTX 4050 */
+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "GM6BG5Q"),
+		},
+	},
+	{
+		/* TongFang GM6BG0Q / PCSpecialist Elimina Pro 16 M, RTX 4060 */
+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "GM6BG0Q"),
+		},
+	},
 	{ }
 };

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #135 lore raw

PATCH 130/191 ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit cd4aece493f99f95d41edcce32927d70a5dde923 upstream.

Added GPE quirk entry for the HP Pavilion Gaming 15-dk1xxx. There is a quirk entry for 2 15-c..... laptops, this is for a new version which has 15-dk1xxx as identifier.

This fixes the LID switch and rfkill and brightness hotkeys not working.

Closes https://github.com/systemd/systemd/issues/28942

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/ec.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/acpi/ec.c +11 -0

@@ -1915,6 +1915,17 @@ static const struct dmi_system_id ec_dmi
 	},
 	{
 		/*
+		 * HP Pavilion Gaming Laptop 15-dk1xxx
+		 * https://github.com/systemd/systemd/issues/28942
+		 */
+		.callback = ec_honor_dsdt_gpe,
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion Gaming Laptop 15-dk1xxx"),
+		},
+	},
+	{
+		/*
 		 * Samsung hardware
 		 * https://bugzilla.kernel.org/show_bug.cgi?id=44161
 		 */

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #136 lore raw

PATCH 131/191 serial: Reduce spinlocked portion of uart_rs485_config()

Link https://lore.kernel.org/r/f3a35967c28b32f3c6432d0aa5936e6a9908282d.1695307688.git.lukas@wunner.de open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lukas Wunner <[email protected]>

commit 8679328eb859d06a1984ab48d90ac35d11bbcaf1 upstream.

Commit 44b27aec9d96 ("serial: core, 8250: set RS485 termination GPIO in serial core") enabled support for RS485 termination GPIOs behind i2c expanders by setting the GPIO outside of the critical section protected by the port spinlock. Access to the i2c expander may sleep, which caused a splat with the port spinlock held.

Commit 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way") erroneously regressed that by spinlocking the GPIO manipulation again.

Fix by moving uart_rs485_config() (the function manipulating the GPIO) outside of the spinlocked section and acquiring the spinlock inside of uart_rs485_config() for the invocation of ->rs485_config() only.

This gets us one step closer to pushing the spinlock down into the ->rs485_config() callbacks which actually need it. (Some callbacks do not want to be spinlocked because they perform sleepable register accesses, see e.g. sc16is7xx_config_rs485().)

Stack trace for posterity:

Voluntary context switch within RCU read-side critical section!

 WARNING: CPU: 0 PID: 56 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch
 Call trace:
 rcu_note_context_switch
 __schedule
 schedule
 schedule_timeout
 wait_for_completion_timeout
 bcm2835_i2c_xfer
 __i2c_transfer
 i2c_transfer
 i2c_transfer_buffer_flags
 regmap_i2c_write
 _regmap_raw_write_impl
 _regmap_bus_raw_write
 _regmap_write
 _regmap_update_bits
 regmap_update_bits_base
 pca953x_gpio_set_value
 gpiod_set_raw_value_commit
 gpiod_set_value_nocheck
 gpiod_set_value_cansleep
 uart_rs485_config
 uart_add_one_port
 pl011_register_port
 pl011_probe

Fixes 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way")

Signed-off-by Lukas Wunner <[email protected]>

Cc [email protected] # v6.1+

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/serial_core.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

drivers/tty/serial/serial_core.c +9 -4

@@ -1410,12 +1410,18 @@ static void uart_set_rs485_termination(s
 static int uart_rs485_config(struct uart_port *port)
 {
 	struct serial_rs485 *rs485 = &port->rs485;
+	unsigned long flags;
 	int ret;
 
+	if (!(rs485->flags & SER_RS485_ENABLED))
+		return 0;
+
 	uart_sanitize_serial_rs485(port, rs485);
 	uart_set_rs485_termination(port, rs485);
 
+	spin_lock_irqsave(&port->lock, flags);
 	ret = port->rs485_config(port, NULL, rs485);
+	spin_unlock_irqrestore(&port->lock, flags);
 	if (ret)
 		memset(rs485, 0, sizeof(*rs485));

@@ -2480,11 +2486,10 @@ int uart_resume_port(struct uart_driver
 			if (ret == 0) {
 				if (tty)
 					uart_change_line_settings(tty, state, NULL);
+				uart_rs485_config(uport);
 				spin_lock_irq(&uport->lock);
 				if (!(uport->rs485.flags & SER_RS485_ENABLED))
 					ops->set_mctrl(uport, uport->mctrl);
-				else
-					uart_rs485_config(uport);
 				ops->start_tx(uport);
 				spin_unlock_irq(&uport->lock);
 				tty_port_set_initialized(port, true);

@@ -2593,10 +2598,10 @@ uart_configure_port(struct uart_driver *
 		port->mctrl &= TIOCM_DTR;
 		if (!(port->rs485.flags & SER_RS485_ENABLED))
 			port->ops->set_mctrl(port, port->mctrl);
-		else
-			uart_rs485_config(port);
 		spin_unlock_irqrestore(&port->lock, flags);
 
+		uart_rs485_config(port);
+
 		/*
 		 * If this driver supports console, and it hasn't been
 		 * successfully registered yet, try to re-register it.

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #137 lore raw

PATCH 132/191 serial: 8250_omap: Fix errors with no_console_suspend

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tony Lindgren <[email protected]>

commit 560706eff7c8e5621b0d63afe0866e0e1906e87e upstream.

We now get errors on system suspend if no_console_suspend is set as reported by Thomas. The errors started with commit 20a41a62618d ("serial:
8250_omap: Use force_suspend and resume for system suspend").

Let's fix the issue by checking for console_suspend_enabled in the system suspend and resume path.

Note that with this fix the checks for console_suspend_enabled in omap8250_runtime_suspend() become useless. We now keep runtime PM usage count for an attached kernel console starting with commit bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console").

Fixes 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend")

Cc stable <[email protected]>

Cc Udit Kumar <[email protected]>

Reported-by Thomas Richard <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Tested-by Thomas Richard <[email protected]>

Reviewed-by Dhruva Gole <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/8250/8250_omap.c |   25 ++++++++++---------------
 1 file changed, 10 insertions(+), 15 deletions(-)

drivers/tty/serial/8250/8250_omap.c +10 ~~-15~~

@@ -1618,7 +1618,7 @@ static int omap8250_suspend(struct devic
 {
 	struct omap8250_priv *priv = dev_get_drvdata(dev);
 	struct uart_8250_port *up = serial8250_get_port(priv->line);
-	int err;
+	int err = 0;
 
 	serial8250_suspend_port(priv->line);

@@ -1628,7 +1628,8 @@ static int omap8250_suspend(struct devic
 	if (!device_may_wakeup(dev))
 		priv->wer = 0;
 	serial_out(up, UART_OMAP_WER, priv->wer);
-	err = pm_runtime_force_suspend(dev);
+	if (uart_console(&up->port) && console_suspend_enabled)
+		err = pm_runtime_force_suspend(dev);
 	flush_work(&priv->qos_work);
 
 	return err;

@@ -1637,11 +1638,15 @@ static int omap8250_suspend(struct devic
 static int omap8250_resume(struct device *dev)
 {
 	struct omap8250_priv *priv = dev_get_drvdata(dev);
+	struct uart_8250_port *up = serial8250_get_port(priv->line);
 	int err;
 
-	err = pm_runtime_force_resume(dev);
-	if (err)
-		return err;
+	if (uart_console(&up->port) && console_suspend_enabled) {
+		err = pm_runtime_force_resume(dev);
+		if (err)
+			return err;
+	}
+
 	serial8250_resume_port(priv->line);
 	/* Paired with pm_runtime_resume_and_get() in omap8250_suspend() */
 	pm_runtime_mark_last_busy(dev);

@@ -1718,16 +1723,6 @@ static int omap8250_runtime_suspend(stru
 
 	if (priv->line >= 0)
 		up = serial8250_get_port(priv->line);
-	/*
-	 * When using 'no_console_suspend', the console UART must not be
-	 * suspended. Since driver suspend is managed by runtime suspend,
-	 * preventing runtime suspend (by returning error) will keep device
-	 * active during suspend.
-	 */
-	if (priv->is_suspending && !console_suspend_enabled) {
-		if (up && uart_console(&up->port))
-			return -EBUSY;
-	}
 
 	if (priv->habit & UART_ERRATA_CLOCK_DISABLE) {
 		int ret;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #138 lore raw

PATCH 133/191 serial: core: Fix checks for tx runtime PM state

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tony Lindgren <[email protected]>

commit 81a61051e0ce5fd7e09225c0d5985da08c7954a7 upstream.

Maximilian reported that surface_serial_hub serdev tx does not work during system suspend. During system suspend, runtime PM gets disabled in __device_suspend_late(), and tx is unable to wake-up the serial core port device that we use to check if tx is safe to start. Johan summarized the regression noting that serdev tx no longer always works as earlier when the serdev device is runtime PM active.

The serdev device and the serial core controller devices are siblings of the serial port hardware device. The runtime PM usage count from serdev device does not propagate to the serial core device siblings, it only propagates to the parent.

In addition to the tx issue for suspend, testing for the serial core port device can cause an unnecessary delay in enabling tx while waiting for the serial core port device to wake-up. The serial core port device wake-up is only needed to flush pending tx when the serial port hardware device was in runtime PM suspended state.

To fix the regression, we need to check the runtime PM state of the parent serial port hardware device for tx instead of the serial core port device.

As the serial port device drivers may or may not implement runtime PM, we need to also add a check for pm_runtime_enabled().

Reported-by Maximilian Luz <[email protected]>

Cc stable <[email protected]>

Fixes 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")

Signed-off-by Tony Lindgren <[email protected]>

Tested-by Maximilian Luz <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/serial_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/tty/serial/serial_core.c +1 -1

@@ -157,7 +157,7 @@ static void __uart_start(struct tty_stru
 	 * enabled, serial_port_runtime_resume() calls start_tx() again
 	 * after enabling the device.
 	 */
-	if (pm_runtime_active(&port_dev->dev))
+	if (!pm_runtime_enabled(port->dev) || pm_runtime_active(port->dev))
 		port->ops->start_tx(port);
 	pm_runtime_mark_last_busy(&port_dev->dev);
 	pm_runtime_put_autosuspend(&port_dev->dev);

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #139 lore raw

PATCH 134/191 binder: fix memory leaks of spam and pending work

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Carlos Llamas <[email protected]>

commit 1aa3aaf8953c84bad398adf6c3cabc9d6685bf7d upstream.

A transaction complete work is allocated and queued for each transaction. Under certain conditions the work->type might be marked as BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT to notify userspace about potential spamming threads or as BINDER_WORK_TRANSACTION_PENDING when the target is currently frozen.

However, these work types are not being handled in binder_release_work() so they will leak during a cleanup. This was reported by syzkaller with the following kmemleak dump:

BUG: memory leak
unreferenced object 0xffff88810e2d6de0 (size 32):
  comm "syz-executor338", pid 5046, jiffies 4294968230 (age 13.590s)
  hex dump (first 32 bytes):
    e0 6d 2d 0e 81 88 ff ff e0 6d 2d 0e 81 88 ff ff  .m-......m-.....
    04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff81573b75>] kmalloc_trace+0x25/0x90 mm/slab_common.c:1114
    [<ffffffff83d41873>] kmalloc include/linux/slab.h:599 [inline]
    [<ffffffff83d41873>] kzalloc include/linux/slab.h:720 [inline]
    [<ffffffff83d41873>] binder_transaction+0x573/0x4050 drivers/android/binder.c:3152
    [<ffffffff83d45a05>] binder_thread_write+0x6b5/0x1860 drivers/android/binder.c:4010
    [<ffffffff83d486dc>] binder_ioctl_write_read drivers/android/binder.c:5066 [inline]
    [<ffffffff83d486dc>] binder_ioctl+0x1b2c/0x3cf0 drivers/android/binder.c:5352
    [<ffffffff816b25f2>] vfs_ioctl fs/ioctl.c:51 [inline]
    [<ffffffff816b25f2>] __do_sys_ioctl fs/ioctl.c:871 [inline]
    [<ffffffff816b25f2>] __se_sys_ioctl fs/ioctl.c:857 [inline]
    [<ffffffff816b25f2>] __x64_sys_ioctl+0xf2/0x140 fs/ioctl.c:857
    [<ffffffff84b30008>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff84b30008>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fix the leaks by kfreeing these work types in binder_release_work() and handle them as a BINDER_WORK_TRANSACTION_COMPLETE cleanup.

Fixes 0567461a7a6e ("binder: return pending info for frozen async txns")

Fixes a7dc1e6f99df ("binder: tell userspace to dump current backtrace when detected oneway spamming")

Reported-by [email protected]

Closes https://syzkaller.appspot.com/bug?extid=7f10c1653e35933c0f1e

Signed-off-by Carlos Llamas <[email protected]>

Reviewed-by Alice Ryhl <[email protected]>

Acked-by Todd Kjos <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/android/binder.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/android/binder.c +2 -0

@@ -4812,6 +4812,8 @@ static void binder_release_work(struct b
 				"undelivered TRANSACTION_ERROR: %u\n",
 				e->cmd);
 		} break;
+		case BINDER_WORK_TRANSACTION_PENDING:
+		case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT:
 		case BINDER_WORK_TRANSACTION_COMPLETE: {
 			binder_debug(BINDER_DEBUG_DEAD_TRANSACTION,
 				"undelivered TRANSACTION_COMPLETE\n");

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #140 lore raw

PATCH 135/191 ksmbd: not allow to open file if delelete on close bit is set

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Namjae Jeon <[email protected]>

commit f43328357defc0dc9d28dbd06dc3361fd2b22e28 upstream.

Cthon test fail with the following error.

check for proper open/unlink operation
nfsjunk files before unlink:
-rwxr-xr-x 1 root root 0 9월 25 11:03 ./nfs2y8Jm9
./nfs2y8Jm9 open; unlink ret = 0
nfsjunk files after unlink:
-rwxr-xr-x 1 root root 0 9월 25 11:03 ./nfs2y8Jm9
data compare ok
nfsjunk files after close:
ls: cannot access './nfs2y8Jm9': No such file or directory
special tests failed

Cthon expect to second unlink failure when file is already unlinked. ksmbd can not allow to open file if flags of ksmbd inode is set with S_DEL_ON_CLS flags.

Signed-off-by Namjae Jeon <[email protected]>

Signed-off-by Steve French <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/smb/server/vfs_cache.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

fs/smb/server/vfs_cache.c +2 -2

@@ -106,7 +106,7 @@ int ksmbd_query_inode_status(struct inod
 	ci = __ksmbd_inode_lookup(inode);
 	if (ci) {
 		ret = KSMBD_INODE_STATUS_OK;
-		if (ci->m_flags & S_DEL_PENDING)
+		if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS))
 			ret = KSMBD_INODE_STATUS_PENDING_DELETE;
 		atomic_dec(&ci->m_count);
 	}

@@ -116,7 +116,7 @@ int ksmbd_query_inode_status(struct inod
 
 bool ksmbd_inode_pending_delete(struct ksmbd_file *fp)
 {
-	return (fp->f_ci->m_flags & S_DEL_PENDING);
+	return (fp->f_ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS));
 }
 
 void ksmbd_set_inode_pending_delete(struct ksmbd_file *fp)

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #141 lore raw

PATCH 136/191 perf/x86/lbr: Filter vsyscall addresses

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: JP Kobryn <[email protected]>

commit e53899771a02f798d436655efbd9d4b46c0f9265 upstream.

We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top):

    __insn_get_emulate_prefix()
    insn_get_emulate_prefix()
    insn_get_prefixes()
    insn_get_opcode()
    decode_branch_type()
    get_branch_type()
    intel_pmu_lbr_filter()
    intel_pmu_handle_irq()
    perf_event_nmi_handler()

Within __insn_get_emulate_prefix() at frame 0, a macro is called:

peek_nbyte_next(insn_byte_t, insn, i)

Within this macro, this dereference occurs:

    (insn)->next_byte

Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault.

To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region.

Signed-off-by JP Kobryn <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/events/utils.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

arch/x86/events/utils.c +3 -2

@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <asm/insn.h>
+#include <linux/mm.h>
 
 #include "perf_event.h"

@@ -132,9 +133,9 @@ static int get_branch_type(unsigned long
 		 * The LBR logs any address in the IP, even if the IP just
 		 * faulted. This means userspace can control the from address.
 		 * Ensure we don't blindly read any address by validating it is
-		 * a known text address.
+		 * a known text address and not a vsyscall address.
 		 */
-		if (kernel_text_address(from)) {
+		if (kernel_text_address(from) && !in_gate_area_no_mm(from)) {
 			addr = (void *)from;
 			/*
 			 * Assume we can get the maximum possible size

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #142 lore raw

PATCH 137/191 x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Borislav Petkov (AMD) <[email protected]>

commit f454b18e07f518bcd0c05af17a2239138bff52de upstream.

Fix erratum #1485 on Zen4 parts where running with STIBP disabled can cause an #UD exception. The performance impact of the fix is negligible.

Reported-by René Rebe <[email protected]>

Signed-off-by Borislav Petkov (AMD) <[email protected]>

Tested-by René Rebe <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/include/asm/msr-index.h |    9 +++++++--
 arch/x86/kernel/cpu/amd.c        |    8 ++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

arch/x86/include/asm/msr-index.h +7 -2

@@ -637,12 +637,17 @@
 /* AMD Last Branch Record MSRs */
 #define MSR_AMD64_LBR_SELECT			0xc000010e
 
-/* Fam 17h MSRs */
-#define MSR_F17H_IRPERF			0xc00000e9
+/* Zen4 */
+#define MSR_ZEN4_BP_CFG			0xc001102e
+#define MSR_ZEN4_BP_CFG_SHARED_BTB_FIX_BIT 5
 
+/* Zen 2 */
 #define MSR_ZEN2_SPECTRAL_CHICKEN	0xc00110e3
 #define MSR_ZEN2_SPECTRAL_CHICKEN_BIT	BIT_ULL(1)
 
+/* Fam 17h MSRs */
+#define MSR_F17H_IRPERF			0xc00000e9
+
 /* Fam 16h MSRs */
 #define MSR_F16H_L2I_PERF_CTL		0xc0010230
 #define MSR_F16H_L2I_PERF_CTR		0xc0010231

arch/x86/kernel/cpu/amd.c +8 -0

@@ -80,6 +80,10 @@ static const int amd_div0[] =
 	AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x17, 0x00, 0x0, 0x2f, 0xf),
 			   AMD_MODEL_RANGE(0x17, 0x50, 0x0, 0x5f, 0xf));
 
+static const int amd_erratum_1485[] =
+	AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x19, 0x10, 0x0, 0x1f, 0xf),
+			   AMD_MODEL_RANGE(0x19, 0x60, 0x0, 0xaf, 0xf));
+
 static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
 {
 	int osvw_id = *erratum++;

@@ -1149,6 +1153,10 @@ static void init_amd(struct cpuinfo_x86
 		pr_notice_once("AMD Zen1 DIV0 bug detected. Disable SMT for full protection.\n");
 		setup_force_cpu_bug(X86_BUG_DIV0);
 	}
+
+	if (!cpu_has(c, X86_FEATURE_HYPERVISOR) &&
+	     cpu_has_amd_erratum(c, amd_erratum_1485))
+		msr_set_bit(MSR_ZEN4_BP_CFG, MSR_ZEN4_BP_CFG_SHARED_BTB_FIX_BIT);
 }
 
 #ifdef CONFIG_X86_32

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #143 lore raw

PATCH 138/191 x86/alternatives: Disable KASAN in apply_alternatives()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kirill A. Shutemov <[email protected]>

commit d35652a5fc9944784f6f50a5c979518ff8dacf61 upstream.

Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine:

	BUG: KASAN: out-of-bounds in rcu_is_watching()
	Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
	...
	__asan_load4()
	rcu_is_watching()
	trace_hardirqs_on()
	text_poke_early()
	apply_alternatives()
	...

On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().

KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.

Fix it for real by disabling KASAN while the kernel is patching alternatives.

[ mingo: updated the changelog ]

Fixes 6657fca06e3f ("x86/mm: Allow to boot without LA57 if CONFIG_X86_5LEVEL=y")

Reported-by Fei Yang <[email protected]>

Signed-off-by Kirill A. Shutemov <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Acked-by Peter Zijlstra (Intel) <[email protected]>

Cc Linus Torvalds <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kernel/alternative.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

arch/x86/kernel/alternative.c +13 -0

@@ -403,6 +403,17 @@ void __init_or_module noinline apply_alt
 	u8 insn_buff[MAX_PATCH_LEN];
 
 	DPRINTK(ALT, "alt table %px, -> %px", start, end);
+
+	/*
+	 * In the case CONFIG_X86_5LEVEL=y, KASAN_SHADOW_START is defined using
+	 * cpu_feature_enabled(X86_FEATURE_LA57) and is therefore patched here.
+	 * During the process, KASAN becomes confused seeing partial LA57
+	 * conversion and triggers a false-positive out-of-bound report.
+	 *
+	 * Disable KASAN until the patching is complete.
+	 */
+	kasan_disable_current();
+
 	/*
 	 * The scan order should be from start to end. A later scanned
 	 * alternative code can overwrite previously scanned alternative code.

@@ -452,6 +463,8 @@ void __init_or_module noinline apply_alt
 
 		text_poke_early(instr, insn_buff, insn_buff_sz);
 	}
+
+	kasan_enable_current();
 }
 
 static inline bool is_jcc32(struct insn *insn)

Greg Kroah-Hartman

author maintainer

2023-10-16 14:53 UTC #144 lore raw

PATCH 139/191 mcb: remove is_added flag from mcb_device struct

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jorge Sanjuan Garcia <[email protected]>

commit 0f28ada1fbf0054557cddcdb93ad17f767105208 upstream.

When calling mcb_bus_add_devices(), both mcb devices and the mcb bus will attempt to attach a device to a driver because they share the same bus_type. This causes an issue when trying to cast the container of the device to mcb_device struct using to_mcb_device(), leading to a wrong cast when the mcb_bus is added. A crash occurs when freing the ida resources as the bus numbering of mcb_bus gets confused with the is_added flag on the mcb_device struct.

The only reason for this cast was to keep an is_added flag on the mcb_device struct that does not seem necessary. The function device_attach() handles already bound devices and the mcb subsystem does nothing special with this is_added flag so remove it completely.

Fixes 18d288198099 ("mcb: Correctly initialize the bus's device")

Cc stable <[email protected]>

Signed-off-by Jorge Sanjuan Garcia <[email protected]>

Co-developed-by Jose Javier Rodriguez Barbarin <[email protected]>

Signed-off-by Jose Javier Rodriguez Barbarin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mcb/mcb-core.c  |   10 +++-------
 drivers/mcb/mcb-parse.c |    2 --
 include/linux/mcb.h     |    1 -
 3 files changed, 3 insertions(+), 10 deletions(-)

drivers/mcb/mcb-core.c +3 -7

@@ -387,17 +387,13 @@ EXPORT_SYMBOL_NS_GPL(mcb_free_dev, MCB);
 
 static int __mcb_bus_add_devices(struct device *dev, void *data)
 {
-	struct mcb_device *mdev = to_mcb_device(dev);
 	int retval;
 
-	if (mdev->is_added)
-		return 0;
-
 	retval = device_attach(dev);
-	if (retval < 0)
+	if (retval < 0) {
 		dev_err(dev, "Error adding device (%d)\n", retval);
-
-	mdev->is_added = true;
+		return retval;
+	}
 
 	return 0;
 }

drivers/mcb/mcb-parse.c +0 -2

@@ -99,8 +99,6 @@ static int chameleon_parse_gdd(struct mc
 	mdev->mem.end = mdev->mem.start + size - 1;
 	mdev->mem.flags = IORESOURCE_MEM;
 
-	mdev->is_added = false;
-
 	ret = mcb_device_register(bus, mdev);
 	if (ret < 0)
 		goto err;

include/linux/mcb.h +0 -1

@@ -63,7 +63,6 @@ static inline struct mcb_bus *to_mcb_bus
 struct mcb_device {
 	struct device dev;
 	struct mcb_bus *bus;
-	bool is_added;
 	struct mcb_driver *driver;
 	u16 id;
 	int inst;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #145 lore raw

PATCH 140/191 thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d upstream.

On some systems the IOMMU blocks the first couple of driver ready messages to the connection manager firmware as can be seen in below excerpts:

thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020]

DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set

The reason is unknown and hard to debug because we were not able to reproduce this locally. This only happens on certain systems with Intel Maple Ridge Thunderbolt controller. If there is a device connected when the driver is loaded the issue does not happen either. Only when there is nothing connected (so typically when the system is booted up).

We can work this around by sending the driver ready several times. After a couple of retries the message goes through and the controller works just fine. For this reason make the number of retries a parameter for icm_request() and then for Maple Ridge (and Titan Ridge as they us the same function but this should not matter) increase number of retries while shortening the timeout accordingly.

Reported-by Werner Sembach <[email protected]>

Reported-by Konrad J Hambrick <[email protected]>

Reported-by Calvin Walton <[email protected]>

Closes https://bugzilla.kernel.org/show_bug.cgi?id=214259

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thunderbolt/icm.c |   40 ++++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

drivers/thunderbolt/icm.c +20 ~~-20~~

@@ -41,6 +41,7 @@
 #define PHY_PORT_CS1_LINK_STATE_SHIFT	26
 
 #define ICM_TIMEOUT			5000	/* ms */
+#define ICM_RETRIES			3
 #define ICM_APPROVE_TIMEOUT		10000	/* ms */
 #define ICM_MAX_LINK			4

@@ -296,10 +297,9 @@ static bool icm_copy(struct tb_cfg_reque
 
 static int icm_request(struct tb *tb, const void *request, size_t request_size,
 		       void *response, size_t response_size, size_t npackets,
-		       unsigned int timeout_msec)
+		       int retries, unsigned int timeout_msec)
 {
 	struct icm *icm = tb_priv(tb);
-	int retries = 3;
 
 	do {
 		struct tb_cfg_request *req;

@@ -410,7 +410,7 @@ static int icm_fr_get_route(struct tb *t
 		return -ENOMEM;
 
 	ret = icm_request(tb, &request, sizeof(request), switches,
-			  sizeof(*switches), npackets, ICM_TIMEOUT);
+			  sizeof(*switches), npackets, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		goto err_free;

@@ -463,7 +463,7 @@ icm_fr_driver_ready(struct tb *tb, enum
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -488,7 +488,7 @@ static int icm_fr_approve_switch(struct
 	memset(&reply, 0, sizeof(reply));
 	/* Use larger timeout as establishing tunnels can take some time */
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_APPROVE_TIMEOUT);
+			  1, ICM_RETRIES, ICM_APPROVE_TIMEOUT);
 	if (ret)
 		return ret;

@@ -515,7 +515,7 @@ static int icm_fr_add_switch_key(struct
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -543,7 +543,7 @@ static int icm_fr_challenge_switch_key(s
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -577,7 +577,7 @@ static int icm_fr_approve_xdomain_paths(
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1020,7 +1020,7 @@ icm_tr_driver_ready(struct tb *tb, enum
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, 20000);
+			  1, 10, 2000);
 	if (ret)
 		return ret;

@@ -1053,7 +1053,7 @@ static int icm_tr_approve_switch(struct
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_APPROVE_TIMEOUT);
+			  1, ICM_RETRIES, ICM_APPROVE_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1081,7 +1081,7 @@ static int icm_tr_add_switch_key(struct
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1110,7 +1110,7 @@ static int icm_tr_challenge_switch_key(s
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1144,7 +1144,7 @@ static int icm_tr_approve_xdomain_paths(
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1170,7 +1170,7 @@ static int icm_tr_xdomain_tear_down(stru
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1496,7 +1496,7 @@ icm_ar_driver_ready(struct tb *tb, enum
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1522,7 +1522,7 @@ static int icm_ar_get_route(struct tb *t
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1543,7 +1543,7 @@ static int icm_ar_get_boot_acl(struct tb
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1604,7 +1604,7 @@ static int icm_ar_set_boot_acl(struct tb
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

@@ -1626,7 +1626,7 @@ icm_icl_driver_ready(struct tb *tb, enum
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, 20000);
+			  1, ICM_RETRIES, 20000);
 	if (ret)
 		return ret;

@@ -2298,7 +2298,7 @@ static int icm_usb4_switch_op(struct tb_
 
 	memset(&reply, 0, sizeof(reply));
 	ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
-			  1, ICM_TIMEOUT);
+			  1, ICM_RETRIES, ICM_TIMEOUT);
 	if (ret)
 		return ret;

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #146 lore raw

PATCH 141/191 thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream.

Marek reported that when BlackMagic UltraStudio device is connected the kernel repeatedly tries to enable lane bonding without success making the device non-functional. It looks like the device does not have lane 1 connected at all so even though it is enabled we should not try to bond the lanes. For this reason check that lane 1 is in fact CL0 (connected, active) before attempting to bond the lanes.

Reported-by Marek Šanta <[email protected]>

Closes https://bugzilla.kernel.org/show_bug.cgi?id=217737

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thunderbolt/switch.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/thunderbolt/switch.c +7 -0

@@ -2724,6 +2724,13 @@ int tb_switch_lane_bonding_enable(struct
 	    !tb_port_is_width_supported(down, TB_LINK_WIDTH_DUAL))
 		return 0;
 
+	/*
+	 * Both lanes need to be in CL0. Here we assume lane 0 already be in
+	 * CL0 and check just for lane 1.
+	 */
+	if (tb_wait_for_port(down->dual_link_port, false) <= 0)
+		return -ENOTCONN;
+
 	ret = tb_port_lane_bonding_enable(up);
 	if (ret) {
 		tb_port_warn(up, "failed to enable lane bonding\n");

Greg Kroah-Hartman

author maintainer

2023-10-16 14:56 UTC #147 lore raw

PATCH 142/191 thunderbolt: Correct TMU mode initialization from hardware

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

commit e19f714ea63f861d95d3d92d45d5fd5ca2e05c8c upstream.

David reported that cppcheck found following possible copy & paste error from tmu_mode_init():

tmu.c:385:50: style: Expression is always false because 'else if' condition matches previous condition at line 383. [multiCondition]

And indeed this is a bug. Fix it to use correct index (TB_SWITCH_TMU_MODE_HIFI_UNI).

Reported-by David Binderman <[email protected]>

Fixes d49b4f043d63 ("thunderbolt: Add support for enhanced uni-directional TMU mode")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thunderbolt/tmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/thunderbolt/tmu.c +1 -1

index 747f88703d5c..11f2aec2a5d3 100644
@@ -382,7 +382,7 @@ static int tmu_mode_init(struct tb_switch *sw)
 		} else if (ucap && tb_port_tmu_is_unidirectional(up)) {
 			if (tmu_rates[TB_SWITCH_TMU_MODE_LOWRES] == rate)
 				sw->tmu.mode = TB_SWITCH_TMU_MODE_LOWRES;
-			else if (tmu_rates[TB_SWITCH_TMU_MODE_LOWRES] == rate)
+			else if (tmu_rates[TB_SWITCH_TMU_MODE_HIFI_UNI] == rate)
 				sw->tmu.mode = TB_SWITCH_TMU_MODE_HIFI_UNI;
 		} else if (rate) {
 			sw->tmu.mode = TB_SWITCH_TMU_MODE_HIFI_BI;

Signature · 1 line

2.42.0

Greg Kroah-Hartman

author maintainer

2023-10-16 14:54 UTC #148 lore raw

PATCH 143/191 thunderbolt: Restart XDomain discovery handshake after failure

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

commit 308092d080852f8997126e5b3507536162416f4a upstream.

Alex reported that after rebooting the other host the peer-to-peer link does not come up anymore. The reason for this is that the host that was not rebooted tries to send the UUID request only 10 times according to the USB4 Inter-Domain spec and gives up if it does not get reply. Then when the other side is actually ready it cannot get the link established anymore. The USB4 Inter-Domain spec requires that the discovery protocol is restarted in that case so implement this now.

Reported-by Alex Balcanquall <[email protected]>

Fixes 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thunderbolt/xdomain.c |   58 +++++++++++++++++++++++++++++-------------
 1 file changed, 41 insertions(+), 17 deletions(-)

drivers/thunderbolt/xdomain.c +41 ~~-17~~

@@ -703,6 +703,27 @@ out_unlock:
 	mutex_unlock(&xdomain_lock);
 }
 
+static void start_handshake(struct tb_xdomain *xd)
+{
+	xd->state = XDOMAIN_STATE_INIT;
+	queue_delayed_work(xd->tb->wq, &xd->state_work,
+			   msecs_to_jiffies(XDOMAIN_SHORT_TIMEOUT));
+}
+
+/* Can be called from state_work */
+static void __stop_handshake(struct tb_xdomain *xd)
+{
+	cancel_delayed_work_sync(&xd->properties_changed_work);
+	xd->properties_changed_retries = 0;
+	xd->state_retries = 0;
+}
+
+static void stop_handshake(struct tb_xdomain *xd)
+{
+	cancel_delayed_work_sync(&xd->state_work);
+	__stop_handshake(xd);
+}
+
 static void tb_xdp_handle_request(struct work_struct *work)
 {
 	struct xdomain_request_work *xw = container_of(work, typeof(*xw), work);

@@ -765,6 +786,15 @@ static void tb_xdp_handle_request(struct
 	case UUID_REQUEST:
 		tb_dbg(tb, "%llx: received XDomain UUID request\n", route);
 		ret = tb_xdp_uuid_response(ctl, route, sequence, uuid);
+		/*
+		 * If we've stopped the discovery with an error such as
+		 * timing out, we will restart the handshake now that we
+		 * received UUID request from the remote host.
+		 */
+		if (!ret && xd && xd->state == XDOMAIN_STATE_ERROR) {
+			dev_dbg(&xd->dev, "restarting handshake\n");
+			start_handshake(xd);
+		}
 		break;
 
 	case LINK_STATE_STATUS_REQUEST:

@@ -1521,6 +1551,13 @@ static void tb_xdomain_queue_properties_
 			   msecs_to_jiffies(XDOMAIN_SHORT_TIMEOUT));
 }
 
+static void tb_xdomain_failed(struct tb_xdomain *xd)
+{
+	xd->state = XDOMAIN_STATE_ERROR;
+	queue_delayed_work(xd->tb->wq, &xd->state_work,
+			   msecs_to_jiffies(XDOMAIN_DEFAULT_TIMEOUT));
+}
+
 static void tb_xdomain_state_work(struct work_struct *work)
 {
 	struct tb_xdomain *xd = container_of(work, typeof(*xd), state_work.work);

@@ -1547,7 +1584,7 @@ static void tb_xdomain_state_work(struct
 		if (ret) {
 			if (ret == -EAGAIN)
 				goto retry_state;
-			xd->state = XDOMAIN_STATE_ERROR;
+			tb_xdomain_failed(xd);
 		} else {
 			tb_xdomain_queue_properties_changed(xd);
 			if (xd->bonding_possible)

@@ -1612,7 +1649,7 @@ static void tb_xdomain_state_work(struct
 		if (ret) {
 			if (ret == -EAGAIN)
 				goto retry_state;
-			xd->state = XDOMAIN_STATE_ERROR;
+			tb_xdomain_failed(xd);
 		} else {
 			xd->state = XDOMAIN_STATE_ENUMERATED;
 		}

@@ -1623,6 +1660,8 @@ static void tb_xdomain_state_work(struct
 		break;
 
 	case XDOMAIN_STATE_ERROR:
+		dev_dbg(&xd->dev, "discovery failed, stopping handshake\n");
+		__stop_handshake(xd);
 		break;
 
 	default:

@@ -1833,21 +1872,6 @@ static void tb_xdomain_release(struct de
 	kfree(xd);
 }
 
-static void start_handshake(struct tb_xdomain *xd)
-{
-	xd->state = XDOMAIN_STATE_INIT;
-	queue_delayed_work(xd->tb->wq, &xd->state_work,
-			   msecs_to_jiffies(XDOMAIN_SHORT_TIMEOUT));
-}
-
-static void stop_handshake(struct tb_xdomain *xd)
-{
-	cancel_delayed_work_sync(&xd->properties_changed_work);
-	cancel_delayed_work_sync(&xd->state_work);
-	xd->properties_changed_retries = 0;
-	xd->state_retries = 0;
-}
-
 static int __maybe_unused tb_xdomain_suspend(struct device *dev)
 {
 	stop_handshake(tb_to_xdomain(dev));

Greg Kroah-Hartman

author maintainer

2023-10-16 14:55 UTC #149 lore raw

PATCH 144/191 powerpc/pseries: Fix STK_PARAM access in the hcall tracing code

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Athira Rajeev <[email protected]>

commit 3b678768c0458e6d8d45fadf61423e44effed4cb upstream.

In powerpc pseries system, below behaviour is observed while enabling tracing on hcall:

  # cd /sys/kernel/debug/tracing/
  # cat events/powerpc/hcall_exit/enable
  0
  # echo 1 > events/powerpc/hcall_exit/enable

  # ls
  -bash: fork: Bad address

Above is from power9 lpar with latest kernel. Past this, softlockup is observed. Initially while attempting via perf_event_open to use "PERF_TYPE_TRACEPOINT", kernel panic was observed.

perf config used:
================
memset(&pe[1],0,sizeof(struct perf_event_attr));
pe[1].type=PERF_TYPE_TRACEPOINT;
pe[1].size=96;
pe[1].config=0x26ULL; /* 38 raw_syscalls/sys_exit */
pe[1].sample_type=0; /* 0 */ pe[1].read_format=PERF_FORMAT_TOTAL_TIME_ENABLED|PERF_FORMAT_TOTAL_TIME_RUNNING|PERF_FORMAT_ID|PERF_FORMAT_GROUP|0x10ULL; /* 1f */ pe[1].inherit=1;
pe[1].precise_ip=0; /* arbitrary skid */
pe[1].wakeup_events=0;
pe[1].bp_type=HW_BREAKPOINT_EMPTY;
pe[1].config1=0x1ULL;

Kernel panic logs:
==================

Kernel attempted to read user page (8) - exploit attempt? (uid: 0)

  BUG: Kernel NULL pointer dereference on read at 0x00000008
  Faulting instruction address: 0xc0000000004c2814
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in: nfnetlink bonding tls rfkill sunrpc dm_service_time dm_multipath pseries_rng xts vmx_crypto xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ibmvfc scsi_transport_fc ibmveth dm_mirror dm_region_hash dm_log dm_mod fuse
  CPU: 0 PID: 1431 Comm: login Not tainted 6.4.0+ #1
  Hardware name: IBM,8375-42A POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.30 (VL950_892) hv:phyp pSeries
  NIP page_remove_rmap+0x44/0x320
  LR  wp_page_copy+0x384/0xec0
  Call Trace:
    0xc00000001416e400 (unreliable)
    wp_page_copy+0x384/0xec0
    __handle_mm_fault+0x9d4/0xfb0
    handle_mm_fault+0xf0/0x350
    ___do_page_fault+0x48c/0xc90
    hash__do_page_fault+0x30/0x70
    do_hash_fault+0x1a4/0x330
    data_access_common_virt+0x198/0x1f0
   --- interrupt: 300 at 0x7fffae971abc

git bisect tracked this down to below commit:
'commit baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead")'

This commit changed STACK_FRAME_OVERHEAD (112 ) to STACK_FRAME_MIN_SIZE (32 ) since 32 bytes is the minimum size for ELFv2 stack. With the latest kernel, when running on ELFv2, STACK_FRAME_MIN_SIZE is used to allocate stack size.

During plpar_hcall_trace, first call is made to HCALL_INST_PRECALL which saves the registers and allocates new stack frame. In the plpar_hcall_trace code, STK_PARAM is accessed at two places.
1. To save r4: std r4,STK_PARAM(R4)(r1)
2. To access r4 back: ld r12,STK_PARAM(R4)(r1)

HCALL_INST_PRECALL precall allocates a new stack frame. So all the stack parameter access after the precall, needs to be accessed with +STACK_FRAME_MIN_SIZE. So the store instruction should be:
std r4,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)

If the "std" is not updated with STACK_FRAME_MIN_SIZE, we will end up with overwriting stack contents and cause corruption. But instead of updating 'std', we can instead remove it since HCALL_INST_PRECALL already saves it to the correct location.

similarly load instruction should be:
ld r12,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)

Fix the load instruction to correctly access the stack parameter with +STACK_FRAME_MIN_SIZE and remove the store of r4 since the precall saves it correctly.

Cc [email protected] # v6.2+

Fixes baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead")

Co-developed-by Naveen N Rao <[email protected]>

Signed-off-by Naveen N Rao <[email protected]>

Signed-off-by Athira Rajeev <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Link https://msgid.link/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/platforms/pseries/hvCall.S |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

arch/powerpc/platforms/pseries/hvCall.S +1 -3

@@ -185,7 +185,6 @@ _GLOBAL_TOC(plpar_hcall)
 plpar_hcall_trace:
 	HCALL_INST_PRECALL(R5)
 
-	std	r4,STK_PARAM(R4)(r1)
 	mr	r0,r4
 
 	mr	r4,r5

@@ -197,7 +196,7 @@ plpar_hcall_trace:
 
 	HVSC
 
-	ld	r12,STK_PARAM(R4)(r1)
+	ld	r12,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)
 	std	r4,0(r12)
 	std	r5,8(r12)
 	std	r6,16(r12)

@@ -297,7 +296,6 @@ _GLOBAL_TOC(plpar_hcall9)
 plpar_hcall9_trace:
 	HCALL_INST_PRECALL(R5)
 
-	std	r4,STK_PARAM(R4)(r1)
 	mr	r0,r4
 
 	mr	r4,r5

Greg Kroah-Hartman

author maintainer

2023-10-16 14:56 UTC #150 lore raw

PATCH 145/191 powerpc/47x: Fix 47x syscall return crash

Link https://lore.kernel.org/linuxppc-dev/[email protected]/ open here

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michael Ellerman <[email protected]>

commit f0eee815babed70a749d2496a7678be5b45b4c14 upstream.

Eddie reported that newer kernels were crashing during boot on his 476 FSP2 system:

kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)

  BUG: Unable to handle kernel instruction fetch
  Faulting instruction address: 0xb7ee2000
  Oops: Kernel access of bad area, sig: 11 [#1]
  BE PAGE_SIZE=4K FSP-2
  Modules linked in:
  CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1
  Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2
  NIP:  b7ee2000 LR: 8c008000 CTR: 00000000
  REGS: bffebd83 TRAP: 0400   Not tainted (6.1.55-d23900f.ppcnf-fs p2)
  MSR:  00000030 <IR,DR>  CR: 00001000  XER: 20000000
  GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000
  GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000
  GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0
  GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0
  NIP [b7ee2000] 0xb7ee2000
  LR [8c008000] 0x8c008000
  Call Trace:
  Instruction dump:
  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
  ---[ end trace 0000000000000000 ]---

The problem is in ret_from_syscall where the check for icache_44x_need_flush is done. When the flush is needed the code jumps out-of-line to do the flush, and then intends to jump back to continue the syscall return.

However the branch back to label 1b doesn't return to the correct location, instead branching back just prior to the return to userspace, causing bogus register values to be used by the rfi.

The breakage was introduced by commit 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which inadvertently removed the "1" label and reused it elsewhere.

Fix it by adding named local labels in the correct locations. Note that the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n compiles.

Fixes 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32")

Cc [email protected] # v5.12+

Reported-by Eddie James <[email protected]>

Tested-by Eddie James <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Reviewed-by Christophe Leroy <[email protected]>

Link https://msgid.link/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/entry_32.S |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

arch/powerpc/kernel/entry_32.S +5 -3

@@ -138,8 +138,9 @@ ret_from_syscall:
 	lis	r4,icache_44x_need_flush@ha
 	lwz	r5,icache_44x_need_flush@l(r4)
 	cmplwi	cr0,r5,0
-	bne-	2f
+	bne-	.L44x_icache_flush
 #endif /* CONFIG_PPC_47x */
+.L44x_icache_flush_return:
 	kuep_unlock
 	lwz	r4,_LINK(r1)
 	lwz	r5,_CCR(r1)

@@ -173,10 +174,11 @@ syscall_exit_finish:
 	b	1b
 
 #ifdef CONFIG_44x
-2:	li	r7,0
+.L44x_icache_flush:
+	li	r7,0
 	iccci	r0,r0
 	stw	r7,icache_44x_need_flush@l(r4)
-	b	1b
+	b	.L44x_icache_flush_return
 #endif  /* CONFIG_44x */
 
 	.globl	ret_from_fork

Greg Kroah-Hartman

author maintainer

2023-10-16 14:56 UTC #151 lore raw

PATCH 146/191 libceph: use kernel_connect()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jordan Rife <[email protected]>

commit 7563cf17dce0a875ba3d872acdc63a78ea344019 upstream.

Direct calls to ops->connect() can overwrite the address parameter when used in conjunction with BPF SOCK_ADDR hooks. Recent changes to kernel_connect() ensure that callers are insulated from such side effects. This patch wraps the direct call to ops->connect() with kernel_connect() to prevent unexpected changes to the address passed to ceph_tcp_connect().

This change was originally part of a larger patch targeting the net tree addressing all instances of unprotected calls to ops->connect() throughout the kernel, but this change was split up into several patches targeting various trees.

Link https://lore.kernel.org/netdev/[email protected]/ open here

Fixes d74bad4e74ee ("bpf: Hooks for sys_connect")

Signed-off-by Jordan Rife <[email protected]>

Reviewed-by Ilya Dryomov <[email protected]>

Signed-off-by Ilya Dryomov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ceph/messenger.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

net/ceph/messenger.c +2 -2

@@ -459,8 +459,8 @@ int ceph_tcp_connect(struct ceph_connect
 	set_sock_callbacks(sock, con);
 
 	con_sock_state_connecting(con);
-	ret = sock->ops->connect(sock, (struct sockaddr *)&ss, sizeof(ss),
-				 O_NONBLOCK);
+	ret = kernel_connect(sock, (struct sockaddr *)&ss, sizeof(ss),
+			     O_NONBLOCK);
 	if (ret == -EINPROGRESS) {
 		dout("connect %s EINPROGRESS sk_state = %u\n",
 		     ceph_pr_addr(&con->peer_addr),

Greg Kroah-Hartman

author maintainer

2023-10-16 14:56 UTC #152 lore raw

PATCH 147/191 ceph: fix incorrect revoked caps assert in ceph_fill_file_size()

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xiubo Li <[email protected]>

commit 15c0a870dc44ed14e01efbdd319d232234ee639f upstream.

When truncating the inode the MDS will acquire the xlock for the ifile Locker, which will revoke the 'Frwsxl' caps from the clients. But when the client just releases and flushes the 'Fw' caps to MDS, for exmaple, and once the MDS receives the caps flushing msg it just thought the revocation has finished. Then the MDS will continue truncating the inode and then issued the truncate notification to all the clients. While just before the clients receives the cap flushing ack they receive the truncation notification, the clients will detecte that the 'issued | dirty' is still holding the 'Fw' caps.

Link https://tracker.ceph.com/issues/56693

Fixes b0d7c2231015 ("ceph: introduce i_truncate_mutex")

Signed-off-by Xiubo Li <[email protected]>

Reviewed-by Milind Changire <[email protected]>

Signed-off-by Ilya Dryomov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ceph/inode.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

fs/ceph/inode.c +1 -3

@@ -655,9 +655,7 @@ int ceph_fill_file_size(struct inode *in
 			ci->i_truncate_seq = truncate_seq;
 
 			/* the MDS should have revoked these caps */
-			WARN_ON_ONCE(issued & (CEPH_CAP_FILE_EXCL |
-					       CEPH_CAP_FILE_RD |
-					       CEPH_CAP_FILE_WR |
+			WARN_ON_ONCE(issued & (CEPH_CAP_FILE_RD |
 					       CEPH_CAP_FILE_LAZYIO));
 			/*
 			 * If we hold relevant caps, or in the case where we're

Greg Kroah-Hartman

author maintainer

2023-10-16 14:56 UTC #153 lore raw

PATCH 148/191 ceph: fix type promotion bug on 32bit systems

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

commit 07bb00ef00ace88dd6f695fadbba76565756e55c upstream.

In this code "ret" is type long and "src_objlen" is unsigned int. The problem is that on 32bit systems, when we do the comparison signed longs are type promoted to unsigned int. So negative error codes from do_splice_direct() are treated as success instead of failure.

Fixes 1b0c3b9f91f0 ("ceph: re-org copy_file_range and fix some error paths")

Reviewed-by Xiubo Li <[email protected]>

Signed-off-by Ilya Dryomov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ceph/file.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/ceph/file.c +1 -1

@@ -2559,7 +2559,7 @@ static ssize_t __ceph_copy_file_range(st
 		ret = do_splice_direct(src_file, &src_off, dst_file,
 				       &dst_off, src_objlen, flags);
 		/* Abort on short copies or on error */
-		if (ret < src_objlen) {
+		if (ret < (long)src_objlen) {
 			dout("Failed partial copy (%zd)\n", ret);
 			goto out;
 		}

Greg Kroah-Hartman

author maintainer

2023-10-16 14:56 UTC #154 lore raw

PATCH 149/191 Input: powermate - fix use-after-free in powermate_config_complete