--- /dev/null
+From fc363413ef8ea842ae7a99e3caf5465dafdd3a49 Mon Sep 17 00:00:00 2001
+From: Haibo Chen <haibo.chen@nxp.com>
+Date: Wed, 18 Oct 2023 11:00:17 +0200
+Subject: gpio: vf610: set value before the direction to avoid a glitch
+
+From: Haibo Chen <haibo.chen@nxp.com>
+
+commit fc363413ef8ea842ae7a99e3caf5465dafdd3a49 upstream.
+
+We found a glitch when configuring the pad as output high. To avoid this
+glitch, move the data value setting before direction config in the
+function vf610_gpio_direction_output().
+
+Fixes: 659d8a62311f ("gpio: vf610: add imx7ulp support")
+Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
+[Bartosz: tweak the commit message]
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-vf610.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpio-vf610.c
++++ b/drivers/gpio/gpio-vf610.c
+@@ -128,14 +128,14 @@ static int vf610_gpio_direction_output(s
+ unsigned long mask = BIT(gpio);
+ u32 val;
+
++ vf610_gpio_set(chip, gpio, value);
++
+ if (port->sdata && port->sdata->have_paddr) {
+ val = vf610_gpio_readl(port->gpio_base + GPIO_PDDR);
+ val |= mask;
+ vf610_gpio_writel(val, port->gpio_base + GPIO_PDDR);
+ }
+
+- vf610_gpio_set(chip, gpio, value);
+-
+ return pinctrl_gpio_direction_output(chip->base + gpio);
+ }
+
--- /dev/null
+From 32671e3799ca2e4590773fd0e63aaa4229e50c06 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Wed, 18 Oct 2023 13:56:54 +0200
+Subject: perf: Disallow mis-matched inherited group reads
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit 32671e3799ca2e4590773fd0e63aaa4229e50c06 upstream.
+
+Because group consistency is non-atomic between parent (filedesc) and children
+(inherited) events, it is possible for PERF_FORMAT_GROUP read() to try and sum
+non-matching counter groups -- with non-sensical results.
+
+Add group_generation to distinguish the case where a parent group removes and
+adds an event and thus has the same number, but a different configuration of
+events as inherited groups.
+
+This became a problem when commit fa8c269353d5 ("perf/core: Invert
+perf_read_group() loops") flipped the order of child_list and sibling_list.
+Previously it would iterate the group (sibling_list) first, and for each
+sibling traverse the child_list. In this order, only the group composition of
+the parent is relevant. By flipping the order the group composition of the
+child (inherited) events becomes an issue and the mis-match in group
+composition becomes evident.
+
+That said; even prior to this commit, while reading of a group that is not
+equally inherited was not broken, it still made no sense.
+
+(Ab)use ECHILD as error return to indicate issues with child process group
+composition.
+
+Fixes: fa8c269353d5 ("perf/core: Invert perf_read_group() loops")
+Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/20231018115654.GK33217@noisy.programming.kicks-ass.net
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/perf_event.h | 1 +
+ kernel/events/core.c | 39 +++++++++++++++++++++++++++++++++------
+ 2 files changed, 34 insertions(+), 6 deletions(-)
+
+--- a/include/linux/perf_event.h
++++ b/include/linux/perf_event.h
+@@ -694,6 +694,7 @@ struct perf_event {
+ /* The cumulative AND of all event_caps for events in this group. */
+ int group_caps;
+
++ unsigned int group_generation;
+ struct perf_event *group_leader;
+ struct pmu *pmu;
+ void *pmu_private;
+--- a/kernel/events/core.c
++++ b/kernel/events/core.c
+@@ -1962,6 +1962,7 @@ static void perf_group_attach(struct per
+
+ list_add_tail(&event->sibling_list, &group_leader->sibling_list);
+ group_leader->nr_siblings++;
++ group_leader->group_generation++;
+
+ perf_event__header_size(group_leader);
+
+@@ -2156,6 +2157,7 @@ static void perf_group_detach(struct per
+ if (leader != event) {
+ list_del_init(&event->sibling_list);
+ event->group_leader->nr_siblings--;
++ event->group_leader->group_generation++;
+ goto out;
+ }
+
+@@ -5279,7 +5281,7 @@ static int __perf_read_group_add(struct
+ u64 read_format, u64 *values)
+ {
+ struct perf_event_context *ctx = leader->ctx;
+- struct perf_event *sub;
++ struct perf_event *sub, *parent;
+ unsigned long flags;
+ int n = 1; /* skip @nr */
+ int ret;
+@@ -5289,6 +5291,33 @@ static int __perf_read_group_add(struct
+ return ret;
+
+ raw_spin_lock_irqsave(&ctx->lock, flags);
++ /*
++ * Verify the grouping between the parent and child (inherited)
++ * events is still in tact.
++ *
++ * Specifically:
++ * - leader->ctx->lock pins leader->sibling_list
++ * - parent->child_mutex pins parent->child_list
++ * - parent->ctx->mutex pins parent->sibling_list
++ *
++ * Because parent->ctx != leader->ctx (and child_list nests inside
++ * ctx->mutex), group destruction is not atomic between children, also
++ * see perf_event_release_kernel(). Additionally, parent can grow the
++ * group.
++ *
++ * Therefore it is possible to have parent and child groups in a
++ * different configuration and summing over such a beast makes no sense
++ * what so ever.
++ *
++ * Reject this.
++ */
++ parent = leader->parent;
++ if (parent &&
++ (parent->group_generation != leader->group_generation ||
++ parent->nr_siblings != leader->nr_siblings)) {
++ ret = -ECHILD;
++ goto unlock;
++ }
+
+ /*
+ * Since we co-schedule groups, {enabled,running} times of siblings
+@@ -5322,8 +5351,9 @@ static int __perf_read_group_add(struct
+ values[n++] = atomic64_read(&sub->lost_samples);
+ }
+
++unlock:
+ raw_spin_unlock_irqrestore(&ctx->lock, flags);
+- return 0;
++ return ret;
+ }
+
+ static int perf_read_group(struct perf_event *event,
+@@ -5342,10 +5372,6 @@ static int perf_read_group(struct perf_e
+
+ values[0] = 1 + leader->nr_siblings;
+
+- /*
+- * By locking the child_mutex of the leader we effectively
+- * lock the child list of all siblings.. XXX explain how.
+- */
+ mutex_lock(&leader->child_mutex);
+
+ ret = __perf_read_group_add(leader, read_format, values);
+@@ -13267,6 +13293,7 @@ static int inherit_group(struct perf_eve
+ !perf_get_aux_event(child_ctr, leader))
+ return -EINVAL;
+ }
++ leader->group_generation = parent_event->group_generation;
+ return 0;
+ }
+
--- /dev/null
+From fe0e04cf66a12ffe6d1b43725ddaabd5599d024f Mon Sep 17 00:00:00 2001
+From: Armin Wolf <W_Armin@gmx.de>
+Date: Sun, 15 Oct 2023 01:54:49 +0200
+Subject: platform/surface: platform_profile: Propagate error if profile registration fails
+
+From: Armin Wolf <W_Armin@gmx.de>
+
+commit fe0e04cf66a12ffe6d1b43725ddaabd5599d024f upstream.
+
+If platform_profile_register() fails, the driver does not propagate
+the error, but instead probes successfully. This means when the driver
+unbinds, the a warning might be issued by platform_profile_remove().
+
+Fix this by propagating the error back to the caller of
+surface_platform_profile_probe().
+
+Compile-tested only.
+
+Fixes: b78b4982d763 ("platform/surface: Add platform profile driver")
+Signed-off-by: Armin Wolf <W_Armin@gmx.de>
+Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
+Tested-by: Maximilian Luz <luzmaximilian@gmail.com>
+Link: https://lore.kernel.org/r/20231014235449.288702-1-W_Armin@gmx.de
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/surface/surface_platform_profile.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/platform/surface/surface_platform_profile.c
++++ b/drivers/platform/surface/surface_platform_profile.c
+@@ -159,8 +159,7 @@ static int surface_platform_profile_prob
+ set_bit(PLATFORM_PROFILE_BALANCED_PERFORMANCE, tpd->handler.choices);
+ set_bit(PLATFORM_PROFILE_PERFORMANCE, tpd->handler.choices);
+
+- platform_profile_register(&tpd->handler);
+- return 0;
++ return platform_profile_register(&tpd->handler);
+ }
+
+ static void surface_platform_profile_remove(struct ssam_device *sdev)
--- /dev/null
+From f37cc2fc277b371fc491890afb7d8a26e36bb3a1 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Tue, 17 Oct 2023 11:07:23 +0200
+Subject: platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2e
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit f37cc2fc277b371fc491890afb7d8a26e36bb3a1 upstream.
+
+Older Asus laptops change the backlight level themselves and then send
+WMI events with different codes for different backlight levels.
+
+The asus-wmi.c code maps the entire range of codes reported on
+brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
+
+define NOTIFY_BRNUP_MIN 0x11
+define NOTIFY_BRNUP_MAX 0x1f
+define NOTIFY_BRNDOWN_MIN 0x20
+define NOTIFY_BRNDOWN_MAX 0x2e
+
+ if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
+ code = ASUS_WMI_BRN_UP;
+ else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
+ code = ASUS_WMI_BRN_DOWN;
+
+Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX
+aka 0x20 - 0x2e events were mapped to 0x20.
+
+This mapping is causing issues on new laptop models which actually
+send 0x2b events for printscreen presses and 0x2c events for
+capslock presses, which get translated into spurious brightness-down
+presses.
+
+The plan is disable the 0x11-0x2e special mapping on laptops
+where asus-wmi does not register a backlight-device to avoid
+the spurious brightness-down keypresses. New laptops always send
+0x2e for brightness-down presses, change the special internal
+ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in
+preparation for fixing the spurious brightness-down presses.
+
+This change does not have any functional impact since all
+of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only
+then checked against the keymap code and the new 0x2e
+value is still in the 0x20 - 0x2e range.
+
+Reported-by: James John <me@donjajo.com>
+Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
+Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20231017090725.38163-2-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/asus-wmi.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/platform/x86/asus-wmi.h
++++ b/drivers/platform/x86/asus-wmi.h
+@@ -18,7 +18,7 @@
+ #include <linux/i8042.h>
+
+ #define ASUS_WMI_KEY_IGNORE (-1)
+-#define ASUS_WMI_BRN_DOWN 0x20
++#define ASUS_WMI_BRN_DOWN 0x2e
+ #define ASUS_WMI_BRN_UP 0x2f
+
+ struct module;
--- /dev/null
+From 235985d1763f7aba92c1c64e5f5aaec26c2c9b18 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Tue, 17 Oct 2023 11:07:25 +0200
+Subject: platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 235985d1763f7aba92c1c64e5f5aaec26c2c9b18 upstream.
+
+Newer Asus laptops send the following new WMI event codes when some
+of the F1 - F12 "media" hotkeys are pressed:
+
+0x2a Screen Capture
+0x2b PrintScreen
+0x2c CapsLock
+
+Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys
+are mapped on other laptops.
+
+PrintScreem and CapsLock are also reported as normal PS/2 keyboard events,
+map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log
+messages.
+
+Reported-by: James John <me@donjajo.com>
+Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
+Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20231017090725.38163-4-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/asus-nb-wmi.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/platform/x86/asus-nb-wmi.c
++++ b/drivers/platform/x86/asus-nb-wmi.c
+@@ -531,6 +531,9 @@ static void asus_nb_wmi_quirks(struct as
+ static const struct key_entry asus_nb_wmi_keymap[] = {
+ { KE_KEY, ASUS_WMI_BRN_DOWN, { KEY_BRIGHTNESSDOWN } },
+ { KE_KEY, ASUS_WMI_BRN_UP, { KEY_BRIGHTNESSUP } },
++ { KE_KEY, 0x2a, { KEY_SELECTIVE_SCREENSHOT } },
++ { KE_IGNORE, 0x2b, }, /* PrintScreen (also send via PS/2) on newer models */
++ { KE_IGNORE, 0x2c, }, /* CapsLock (also send via PS/2) on newer models */
+ { KE_KEY, 0x30, { KEY_VOLUMEUP } },
+ { KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
+ { KE_KEY, 0x32, { KEY_MUTE } },
--- /dev/null
+From a5b92be2482e5f9ef30be4e4cda12ed484381493 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Tue, 17 Oct 2023 11:07:24 +0200
+Subject: platform/x86: asus-wmi: Only map brightness codes when using asus-wmi backlight control
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit a5b92be2482e5f9ef30be4e4cda12ed484381493 upstream.
+
+Older Asus laptops change the backlight level themselves and then send
+WMI events with different codes for different backlight levels.
+
+The asus-wmi.c code maps the entire range of codes reported on
+brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
+
+define NOTIFY_BRNUP_MIN 0x11
+define NOTIFY_BRNUP_MAX 0x1f
+define NOTIFY_BRNDOWN_MIN 0x20
+define NOTIFY_BRNDOWN_MAX 0x2e
+
+ if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
+ code = ASUS_WMI_BRN_UP;
+ else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
+ code = ASUS_WMI_BRN_DOWN;
+
+This mapping is causing issues on new laptop models which actually
+send 0x2b events for printscreen presses and 0x2c events for
+capslock presses, which get translated into spurious brightness-down
+presses.
+
+This mapping is really only necessary when asus-wmi has registered
+a backlight-device for backlight control. In this case the mapping
+was used to decide to filter out the keypresss since in this case
+the firmware has already modified the brightness itself and instead
+of reporting a keypress asus-wmi will just report the new brightness
+value to userspace.
+
+OTOH when the firmware does not adjust the brightness itself then
+it seems to always report 0x2e for brightness-down presses and
+0x2f for brightness up presses independent of the actual brightness
+level. So in this case the mapping of the code is not necessary
+and this translation actually leads to spurious brightness-down
+presses being send to userspace when pressing printscreen or capslock.
+
+Modify asus_wmi_handle_event_code() to only do the mapping
+when using asus-wmi backlight control to fix the spurious
+brightness-down presses.
+
+Reported-by: James John <me@donjajo.com>
+Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
+Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20231017090725.38163-3-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/asus-wmi.c | 15 ++++-----------
+ 1 file changed, 4 insertions(+), 11 deletions(-)
+
+--- a/drivers/platform/x86/asus-wmi.c
++++ b/drivers/platform/x86/asus-wmi.c
+@@ -3268,7 +3268,6 @@ static void asus_wmi_handle_event_code(i
+ {
+ unsigned int key_value = 1;
+ bool autorelease = 1;
+- int orig_code = code;
+
+ if (asus->driver->key_filter) {
+ asus->driver->key_filter(asus->driver, &code, &key_value,
+@@ -3277,16 +3276,10 @@ static void asus_wmi_handle_event_code(i
+ return;
+ }
+
+- if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
+- code = ASUS_WMI_BRN_UP;
+- else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
+- code = ASUS_WMI_BRN_DOWN;
+-
+- if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) {
+- if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
+- asus_wmi_backlight_notify(asus, orig_code);
+- return;
+- }
++ if (acpi_video_get_backlight_type() == acpi_backlight_vendor &&
++ code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNDOWN_MAX) {
++ asus_wmi_backlight_notify(asus, code);
++ return;
+ }
+
+ if (code == NOTIFY_KBD_BRTUP) {
--- /dev/null
+From 4d73c6772ab771cbbe7e46a73e7c78ba490350fa Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Wed, 4 Oct 2023 11:19:15 -0700
+Subject: platform/x86: intel-uncore-freq: Conditionally create attribute for read frequency
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit 4d73c6772ab771cbbe7e46a73e7c78ba490350fa upstream.
+
+When the current uncore frequency can't be read, don't create attribute
+"current_freq_khz" as any read will fail later. Some user space
+applications like turbostat fail to continue with the failure. So, check
+error during attribute creation.
+
+Fixes: 414eef27283a ("platform/x86/intel/uncore-freq: Display uncore current frequency")
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Link: https://lore.kernel.org/r/20231004181915.1887913-1-srinivas.pandruvada@linux.intel.com
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
++++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
+@@ -153,7 +153,7 @@ show_uncore_data(initial_max_freq_khz);
+
+ static int create_attr_group(struct uncore_data *data, char *name)
+ {
+- int ret, index = 0;
++ int ret, freq, index = 0;
+
+ init_attribute_rw(max_freq_khz);
+ init_attribute_rw(min_freq_khz);
+@@ -165,7 +165,11 @@ static int create_attr_group(struct unco
+ data->uncore_attrs[index++] = &data->min_freq_khz_dev_attr.attr;
+ data->uncore_attrs[index++] = &data->initial_min_freq_khz_dev_attr.attr;
+ data->uncore_attrs[index++] = &data->initial_max_freq_khz_dev_attr.attr;
+- data->uncore_attrs[index++] = &data->current_freq_khz_dev_attr.attr;
++
++ ret = uncore_read_freq(data, &freq);
++ if (!ret)
++ data->uncore_attrs[index++] = &data->current_freq_khz_dev_attr.attr;
++
+ data->uncore_attrs[index] = NULL;
+
+ data->uncore_attr_group.name = name;
--- /dev/null
+From 63e8b94ad1840f02462633abdb363397f56bc642 Mon Sep 17 00:00:00 2001
+From: Dinghao Liu <dinghao.liu@zju.edu.cn>
+Date: Thu, 21 Sep 2023 15:14:12 +0800
+Subject: s390/cio: fix a memleak in css_alloc_subchannel
+
+From: Dinghao Liu <dinghao.liu@zju.edu.cn>
+
+commit 63e8b94ad1840f02462633abdb363397f56bc642 upstream.
+
+When dma_set_coherent_mask() fails, sch->lock has not been
+freed, which is allocated in css_sch_create_locks(), leading
+to a memleak.
+
+Fixes: 4520a91a976e ("s390/cio: use dma helpers for setting masks")
+Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
+Message-Id: <20230921071412.13806-1-dinghao.liu@zju.edu.cn>
+Link: https://lore.kernel.org/linux-s390/bd38baa8-7b9d-4d89-9422-7e943d626d6e@linux.ibm.com/
+Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
+Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/cio/css.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/cio/css.c
++++ b/drivers/s390/cio/css.c
+@@ -233,17 +233,19 @@ struct subchannel *css_alloc_subchannel(
+ */
+ ret = dma_set_coherent_mask(&sch->dev, DMA_BIT_MASK(31));
+ if (ret)
+- goto err;
++ goto err_lock;
+ /*
+ * But we don't have such restrictions imposed on the stuff that
+ * is handled by the streaming API.
+ */
+ ret = dma_set_mask(&sch->dev, DMA_BIT_MASK(64));
+ if (ret)
+- goto err;
++ goto err_lock;
+
+ return sch;
+
++err_lock:
++ kfree(sch->lock);
+ err:
+ kfree(sch);
+ return ERR_PTR(ret);
--- /dev/null
+From c1ae1c59c8c6e0b66a718308c623e0cb394dab6b Mon Sep 17 00:00:00 2001
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+Date: Tue, 17 Oct 2023 15:37:29 +0200
+Subject: s390/pci: fix iommu bitmap allocation
+
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+
+commit c1ae1c59c8c6e0b66a718308c623e0cb394dab6b upstream.
+
+Since the fixed commits both zdev->iommu_bitmap and zdev->lazy_bitmap
+are allocated as vzalloc(zdev->iommu_pages / 8). The problem is that
+zdev->iommu_bitmap is a pointer to unsigned long but the above only
+yields an allocation that is a multiple of sizeof(unsigned long) which
+is 8 on s390x if the number of IOMMU pages is a multiple of 64.
+This in turn is the case only if the effective IOMMU aperture is
+a multiple of 64 * 4K = 256K. This is usually the case and so didn't
+cause visible issues since both the virt_to_phys(high_memory) reduced
+limit and hardware limits use nice numbers.
+
+Under KVM, and in particular with QEMU limiting the IOMMU aperture to
+the vfio DMA limit (default 65535), it is possible for the reported
+aperture not to be a multiple of 256K however. In this case we end up
+with an iommu_bitmap whose allocation is not a multiple of
+8 causing bitmap operations to access it out of bounds.
+
+Sadly we can't just fix this in the obvious way and use bitmap_zalloc()
+because for large RAM systems (tested on 8 TiB) the zdev->iommu_bitmap
+grows too large for kmalloc(). So add our own bitmap_vzalloc() wrapper.
+This might be a candidate for common code, but this area of code will
+be replaced by the upcoming conversion to use the common code DMA API on
+s390 so just add a local routine.
+
+Fixes: 224593215525 ("s390/pci: use virtual memory for iommu bitmap")
+Fixes: 13954fd6913a ("s390/pci_dma: improve lazy flush for unmap")
+Cc: stable@vger.kernel.org
+Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
+Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/pci/pci_dma.c | 15 +++++++++++++--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/pci/pci_dma.c
++++ b/arch/s390/pci/pci_dma.c
+@@ -544,6 +544,17 @@ static void s390_dma_unmap_sg(struct dev
+ s->dma_length = 0;
+ }
+ }
++
++static unsigned long *bitmap_vzalloc(size_t bits, gfp_t flags)
++{
++ size_t n = BITS_TO_LONGS(bits);
++ size_t bytes;
++
++ if (unlikely(check_mul_overflow(n, sizeof(unsigned long), &bytes)))
++ return NULL;
++
++ return vzalloc(bytes);
++}
+
+ int zpci_dma_init_device(struct zpci_dev *zdev)
+ {
+@@ -584,13 +595,13 @@ int zpci_dma_init_device(struct zpci_dev
+ zdev->end_dma - zdev->start_dma + 1);
+ zdev->end_dma = zdev->start_dma + zdev->iommu_size - 1;
+ zdev->iommu_pages = zdev->iommu_size >> PAGE_SHIFT;
+- zdev->iommu_bitmap = vzalloc(zdev->iommu_pages / 8);
++ zdev->iommu_bitmap = bitmap_vzalloc(zdev->iommu_pages, GFP_KERNEL);
+ if (!zdev->iommu_bitmap) {
+ rc = -ENOMEM;
+ goto free_dma_table;
+ }
+ if (!s390_iommu_strict) {
+- zdev->lazy_bitmap = vzalloc(zdev->iommu_pages / 8);
++ zdev->lazy_bitmap = bitmap_vzalloc(zdev->iommu_pages, GFP_KERNEL);
+ if (!zdev->lazy_bitmap) {
+ rc = -ENOMEM;
+ goto free_bitmap;
--- /dev/null
+From 03b80ff8023adae6780e491f66e932df8165e3a0 Mon Sep 17 00:00:00 2001
+From: Francis Laniel <flaniel@linux.microsoft.com>
+Date: Fri, 20 Oct 2023 13:42:50 +0300
+Subject: selftests/ftrace: Add new test case which checks non unique symbol
+
+From: Francis Laniel <flaniel@linux.microsoft.com>
+
+commit 03b80ff8023adae6780e491f66e932df8165e3a0 upstream.
+
+If name_show() is non unique, this test will try to install a kprobe on this
+function which should fail returning EADDRNOTAVAIL.
+On kernel where name_show() is not unique, this test is skipped.
+
+Link: https://lore.kernel.org/all/20231020104250.9537-3-flaniel@linux.microsoft.com/
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Francis Laniel <flaniel@linux.microsoft.com>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/ftrace/test.d/kprobe/kprobe_non_uniq_symbol.tc | 13 ++++++++++
+ 1 file changed, 13 insertions(+)
+ create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_non_uniq_symbol.tc
+
+--- /dev/null
++++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_non_uniq_symbol.tc
+@@ -0,0 +1,13 @@
++#!/bin/sh
++# SPDX-License-Identifier: GPL-2.0
++# description: Test failure of registering kprobe on non unique symbol
++# requires: kprobe_events
++
++SYMBOL='name_show'
++
++# We skip this test on kernel where SYMBOL is unique or does not exist.
++if [ "$(grep -c -E "[[:alnum:]]+ t ${SYMBOL}" /proc/kallsyms)" -le '1' ]; then
++ exit_unsupported
++fi
++
++! echo "p:test_non_unique ${SYMBOL}" > kprobe_events
nvme-rdma-do-not-try-to-stop-unallocated-queues.patch
kvm-x86-mmu-stop-zapping-invalidated-tdp-mmu-roots-asynchronously.patch
hid-input-map-battery-system-charging.patch
+usb-serial-option-add-telit-le910c4-wwx-0x1035-composition.patch
+usb-serial-option-add-entry-for-sierra-em9191-with-new-firmware.patch
+usb-serial-option-add-fibocom-to-dell-custom-modem-fm101r-gl.patch
+perf-disallow-mis-matched-inherited-group-reads.patch
+s390-pci-fix-iommu-bitmap-allocation.patch
+selftests-ftrace-add-new-test-case-which-checks-non-unique-symbol.patch
+s390-cio-fix-a-memleak-in-css_alloc_subchannel.patch
+platform-surface-platform_profile-propagate-error-if-profile-registration-fails.patch
+platform-x86-intel-uncore-freq-conditionally-create-attribute-for-read-frequency.patch
+platform-x86-asus-wmi-change-asus_wmi_brn_down-code-from-0x20-to-0x2e.patch
+platform-x86-asus-wmi-only-map-brightness-codes-when-using-asus-wmi-backlight-control.patch
+platform-x86-asus-wmi-map-0x2a-code-ignore-0x2b-and-0x2c-events.patch
+gpio-vf610-set-value-before-the-direction-to-avoid-a-glitch.patch
--- /dev/null
+From 064f6e2ba9eb59b2c87b866e1e968e79ccedf9dd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Beno=C3=AEt=20Monin?= <benoit.monin@gmx.fr>
+Date: Mon, 2 Oct 2023 17:51:40 +0200
+Subject: USB: serial: option: add entry for Sierra EM9191 with new firmware
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Benoît Monin <benoit.monin@gmx.fr>
+
+commit 064f6e2ba9eb59b2c87b866e1e968e79ccedf9dd upstream.
+
+Following a firmware update of the modem, the interface for the AT
+command port changed, so add it back.
+
+T: Bus=08 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 2 Spd=5000 MxCh= 0
+D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
+P: Vendor=1199 ProdID=90d3 Rev=00.06
+S: Manufacturer=Sierra Wireless, Incorporated
+S: Product=Sierra Wireless EM9191
+S: SerialNumber=xxxxxxxxxxxxxxxx
+C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA
+I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
+I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
+I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none)
+I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
+
+Signed-off-by: Benoît Monin <benoit.monin@gmx.fr>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/option.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -2263,6 +2263,7 @@ static const struct usb_device_id option
+ { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1406, 0xff) }, /* GosunCn GM500 ECM/NCM */
+ { USB_DEVICE_AND_INTERFACE_INFO(OPPO_VENDOR_ID, OPPO_PRODUCT_R11, 0xff, 0xff, 0x30) },
+ { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9191, 0xff, 0xff, 0x30) },
++ { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9191, 0xff, 0xff, 0x40) },
+ { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9191, 0xff, 0, 0) },
+ { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, TOZED_PRODUCT_LT70C, 0xff, 0, 0) },
+ { } /* Terminating entry */
--- /dev/null
+From 52480e1f1a259c93d749ba3961af0bffedfe7a7a Mon Sep 17 00:00:00 2001
+From: Puliang Lu <puliang.lu@fibocom.com>
+Date: Mon, 16 Oct 2023 15:36:16 +0800
+Subject: USB: serial: option: add Fibocom to DELL custom modem FM101R-GL
+
+From: Puliang Lu <puliang.lu@fibocom.com>
+
+commit 52480e1f1a259c93d749ba3961af0bffedfe7a7a upstream.
+
+Update the USB serial option driver support for the Fibocom
+FM101R-GL LTE modules as there are actually several different variants.
+
+- VID:PID 413C:8213, FM101R-GL are laptop M.2 cards (with
+ MBIM interfaces for Linux)
+
+- VID:PID 413C:8215, FM101R-GL ESIM are laptop M.2 cards (with
+ MBIM interface for Linux)
+
+0x8213: mbim, tty
+0x8215: mbim, tty
+
+T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
+D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
+P: Vendor=413c ProdID=8213 Rev= 5.04
+S: Manufacturer=Fibocom Wireless Inc.
+S: Product=Fibocom FM101-GL Module
+S: SerialNumber=a3b7cbf0
+C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
+A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
+I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
+E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms
+I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
+I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
+E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none)
+E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
+E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+
+T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0
+D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
+P: Vendor=413c ProdID=8215 Rev= 5.04
+S: Manufacturer=Fibocom Wireless Inc.
+S: Product=Fibocom FM101-GL Module
+S: SerialNumber=a3b7cbf0
+C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
+A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
+I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
+E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms
+I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
+I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
+E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none)
+E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
+E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
+
+Signed-off-by: Puliang Lu <puliang.lu@fibocom.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/option.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -203,6 +203,9 @@ static void option_instat_callback(struc
+ #define DELL_PRODUCT_5829E_ESIM 0x81e4
+ #define DELL_PRODUCT_5829E 0x81e6
+
++#define DELL_PRODUCT_FM101R 0x8213
++#define DELL_PRODUCT_FM101R_ESIM 0x8215
++
+ #define KYOCERA_VENDOR_ID 0x0c88
+ #define KYOCERA_PRODUCT_KPC650 0x17da
+ #define KYOCERA_PRODUCT_KPC680 0x180a
+@@ -1108,6 +1111,8 @@ static const struct usb_device_id option
+ .driver_info = RSVD(0) | RSVD(6) },
+ { USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5829E_ESIM),
+ .driver_info = RSVD(0) | RSVD(6) },
++ { USB_DEVICE_INTERFACE_CLASS(DELL_VENDOR_ID, DELL_PRODUCT_FM101R, 0xff) },
++ { USB_DEVICE_INTERFACE_CLASS(DELL_VENDOR_ID, DELL_PRODUCT_FM101R_ESIM, 0xff) },
+ { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) }, /* ADU-E100, ADU-310 */
+ { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
+ { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },
--- /dev/null
+From 6a7be48e9bd18d309ba25c223a27790ad1bf0fa3 Mon Sep 17 00:00:00 2001
+From: Fabio Porcedda <fabio.porcedda@gmail.com>
+Date: Tue, 5 Sep 2023 09:37:24 +0200
+Subject: USB: serial: option: add Telit LE910C4-WWX 0x1035 composition
+
+From: Fabio Porcedda <fabio.porcedda@gmail.com>
+
+commit 6a7be48e9bd18d309ba25c223a27790ad1bf0fa3 upstream.
+
+Add support for the following Telit LE910C4-WWX composition:
+
+0x1035: TTY, TTY, ECM
+
+T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
+D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=1bc7 ProdID=1035 Rev=00.00
+S: Manufacturer=Telit
+S: Product=LE910C4-WWX
+S: SerialNumber=e1b117c7
+C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
+I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
+E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
+E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
+E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+I: If#= 2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
+E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
+I: If#= 3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
+E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
+
+Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Daniele Palmas <dnlplm@gmail.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/option.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -1290,6 +1290,7 @@ static const struct usb_device_id option
+ .driver_info = NCTRL(0) | RSVD(3) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1033, 0xff), /* Telit LE910C1-EUX (ECM) */
+ .driver_info = NCTRL(0) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1035, 0xff) }, /* Telit LE910C4-WWX (ECM) */
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG0),
+ .driver_info = RSVD(0) | RSVD(1) | NCTRL(2) | RSVD(3) },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG1),
projects / thirdparty / kernel / stable-queue.git / commitdiff
