--- /dev/null
+From 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 Mon Sep 17 00:00:00 2001
+From: Jakob Unterwurzacher <jakobunt@gmail.com>
+Date: Fri, 13 Dec 2024 10:54:58 +0100
+Subject: arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma
+
+From: Jakob Unterwurzacher <jakobunt@gmail.com>
+
+commit 9d241b06802c6c2176ae7aa4f9f17f8a577ed337 upstream.
+
+During mass manufacturing, we noticed the mmc_rx_crc_error counter,
+as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase
+above zero during nuttcp speedtests. Most of the time, this did not
+affect the achieved speed, but it prompted this investigation.
+
+Cycling through the rx_delay range on six boards (see table below) of
+various ages shows that there is a large good region from 0x12 to 0x35
+where we see zero crc errors on all tested boards.
+
+The old rx_delay value (0x10) seems to have always been on the edge for
+the KSZ9031RNX that is usually placed on Puma.
+
+Choose "rx_delay = 0x23" to put us smack in the middle of the good
+region. This works fine as well with the KSZ9131RNX PHY that was used
+for a small number of boards during the COVID chip shortages.
+
+ Board S/N PHY rx_delay good region
+ --------- --- --------------------
+ Puma TT0069903 KSZ9031RNX 0x11 0x35
+ Puma TT0157733 KSZ9031RNX 0x11 0x35
+ Puma TT0681551 KSZ9031RNX 0x12 0x37
+ Puma TT0681156 KSZ9031RNX 0x10 0x38
+ Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017)
+ Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards)
+
+ Intersection of good regions = 0x12 0x35
+ Middle of good region = 0x23
+
+Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
+Cc: stable@vger.kernel.org
+Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
+Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # Puma v2.1 and v2.3 with KSZ9031
+Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
+Link: https://lore.kernel.org/r/20241213-puma_rx_delay-v4-1-8e8e11cc6ed7@cherry.de
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+@@ -176,7 +176,7 @@
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x10>;
+- rx_delay = <0x10>;
++ rx_delay = <0x23>;
+ status = "okay";
+ };
+
--- /dev/null
+From 55cf2f4b945f6a6416cc2524ba740b83cc9af25a Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@linaro.org>
+Date: Wed, 4 Dec 2024 15:07:15 +0300
+Subject: binfmt_flat: Fix integer overflow bug on 32 bit systems
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+commit 55cf2f4b945f6a6416cc2524ba740b83cc9af25a upstream.
+
+Most of these sizes and counts are capped at 256MB so the math doesn't
+result in an integer overflow. The "relocs" count needs to be checked
+as well. Otherwise on 32bit systems the calculation of "full_data"
+could be wrong.
+
+ full_data = data_len + relocs * sizeof(unsigned long);
+
+Fixes: c995ee28d29d ("binfmt_flat: prevent kernel dammage from corrupted executable headers")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Acked-by: Nicolas Pitre <npitre@baylibre.com>
+Link: https://lore.kernel.org/r/5be17f6c-5338-43be-91ef-650153b975cb@stanley.mountain
+Signed-off-by: Kees Cook <kees@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/binfmt_flat.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/binfmt_flat.c
++++ b/fs/binfmt_flat.c
+@@ -529,7 +529,7 @@ static int load_flat_file(struct linux_b
+ * 28 bits (256 MB) is way more than reasonable in this case.
+ * If some top bits are set we have probable binary corruption.
+ */
+- if ((text_len | data_len | bss_len | stack_len | full_data) >> 28) {
++ if ((text_len | data_len | bss_len | stack_len | relocs | full_data) >> 28) {
+ pr_err("bad header\n");
+ ret = -ENOEXEC;
+ goto err;
--- /dev/null
+From 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Wed, 18 Dec 2024 00:19:59 +0300
+Subject: Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 5f397409f8ee5bc82901eeaf799e1cbc4f8edcf1 upstream.
+
+A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
+from l2cap_sock_new_connection_cb() and the error handling paths should
+also be aware of it.
+
+Seemingly a more elegant solution would be to swap bt_sock_alloc() and
+l2cap_chan_create() calls since they are not interdependent to that moment
+but then l2cap_chan_create() adds the soon to be deallocated and still
+dummy-initialized channel to the global list accessible by many L2CAP
+paths. The channel would be removed from the list in short period of time
+but be a bit more straight-forward here and just check for NULL instead of
+changing the order of function calls.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE static
+analysis tool.
+
+Fixes: 7c4f78cdb8e7 ("Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/l2cap_sock.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/l2cap_sock.c
++++ b/net/bluetooth/l2cap_sock.c
+@@ -1678,7 +1678,8 @@ static struct sock *l2cap_sock_alloc(str
+ chan = l2cap_chan_create();
+ if (!chan) {
+ sk_free(sk);
+- sock->sk = NULL;
++ if (sock)
++ sock->sk = NULL;
+ return NULL;
+ }
+
--- /dev/null
+From 43855ac61483cb914f060851535ea753c094b3e0 Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Wed, 22 Jan 2025 11:36:16 +0530
+Subject: cpufreq: s3c64xx: Fix compilation warning
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+commit 43855ac61483cb914f060851535ea753c094b3e0 upstream.
+
+The driver generates following warning when regulator support isn't
+enabled in the kernel. Fix it.
+
+ drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target':
+>> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable]
+ 55 | unsigned int old_freq, new_freq;
+ | ^~~~~~~~
+>> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable]
+ 54 | struct s3c64xx_dvfs *dvfs;
+ | ^~~~
+
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/
+Cc: 5.4+ <stable@vger.kernel.org> # v5.4+
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Link: https://patch.msgid.link/236b227e929e5adc04d1e9e7af6845a46c8e9432.1737525916.git.viresh.kumar@linaro.org
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/s3c64xx-cpufreq.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/cpufreq/s3c64xx-cpufreq.c
++++ b/drivers/cpufreq/s3c64xx-cpufreq.c
+@@ -25,6 +25,7 @@ struct s3c64xx_dvfs {
+ unsigned int vddarm_max;
+ };
+
++#ifdef CONFIG_REGULATOR
+ static struct s3c64xx_dvfs s3c64xx_dvfs_table[] = {
+ [0] = { 1000000, 1150000 },
+ [1] = { 1050000, 1150000 },
+@@ -32,6 +33,7 @@ static struct s3c64xx_dvfs s3c64xx_dvfs_
+ [3] = { 1200000, 1350000 },
+ [4] = { 1300000, 1350000 },
+ };
++#endif
+
+ static struct cpufreq_frequency_table s3c64xx_freq_table[] = {
+ { 0, 0, 66000 },
+@@ -53,15 +55,16 @@ static struct cpufreq_frequency_table s3
+ static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy,
+ unsigned int index)
+ {
+- struct s3c64xx_dvfs *dvfs;
+- unsigned int old_freq, new_freq;
++ unsigned int new_freq = s3c64xx_freq_table[index].frequency;
+ int ret;
+
++#ifdef CONFIG_REGULATOR
++ struct s3c64xx_dvfs *dvfs;
++ unsigned int old_freq;
++
+ old_freq = clk_get_rate(policy->clk) / 1000;
+- new_freq = s3c64xx_freq_table[index].frequency;
+ dvfs = &s3c64xx_dvfs_table[s3c64xx_freq_table[index].driver_data];
+
+-#ifdef CONFIG_REGULATOR
+ if (vddarm && new_freq > old_freq) {
+ ret = regulator_set_voltage(vddarm,
+ dvfs->vddarm_min,
--- /dev/null
+From 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 Mon Sep 17 00:00:00 2001
+From: Haoxiang Li <haoxiang_li2024@163.com>
+Date: Thu, 19 Dec 2024 17:02:56 +0800
+Subject: drm/komeda: Add check for komeda_get_layer_fourcc_list()
+
+From: Haoxiang Li <haoxiang_li2024@163.com>
+
+commit 79fc672a092d93a7eac24fe20a571d4efd8fa5a4 upstream.
+
+Add check for the return value of komeda_get_layer_fourcc_list()
+to catch the potential exception.
+
+Fixes: 5d51f6c0da1b ("drm/komeda: Add writeback support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
+Acked-by: Liviu Dudau <liviu.dudau@arm.com>
+Link: https://lore.kernel.org/r/20241219090256.146424-1-haoxiang_li2024@163.com
+Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
++++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+@@ -159,6 +159,10 @@ static int komeda_wb_connector_add(struc
+ formats = komeda_get_layer_fourcc_list(&mdev->fmt_tbl,
+ kwb_conn->wb_layer->layer_type,
+ &n_formats);
++ if (!formats) {
++ kfree(kwb_conn);
++ return -ENOMEM;
++ }
+
+ err = drm_writeback_connector_init(&kms->base, wb_conn,
+ &komeda_wb_connector_funcs,
--- /dev/null
+From 666e1960464140cc4bc9203c203097e70b54c95a Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Tue, 5 Nov 2024 14:38:16 +0100
+Subject: drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 666e1960464140cc4bc9203c203097e70b54c95a upstream.
+
+The code for detecting and updating the connector status in
+cdn_dp_pd_event_work() has a number of problems.
+
+- It does not aquire the locks to call the detect helper and update
+the connector status. These are struct drm_mode_config.connection_mutex
+and struct drm_mode_config.mutex.
+
+- It does not use drm_helper_probe_detect(), which helps with the
+details of locking and detection.
+
+- It uses the connector's status field to determine a change to
+the connector status. The epoch_counter field is the correct one. The
+field signals a change even if the connector status' value did not
+change.
+
+Replace the code with a call to drm_connector_helper_hpd_irq_event(),
+which fixes all these problems.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event")
+Cc: Chris Zhong <zyw@rock-chips.com>
+Cc: Guenter Roeck <groeck@chromium.org>
+Cc: Sandy Huang <hjc@rock-chips.com>
+Cc: "Heiko Stübner" <heiko@sntech.de>
+Cc: Andy Yan <andy.yan@rock-chips.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-rockchip@lists.infradead.org
+Cc: <stable@vger.kernel.org> # v4.11+
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20241105133848.480407-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +--------
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
++++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
+@@ -917,9 +917,6 @@ static void cdn_dp_pd_event_work(struct
+ {
+ struct cdn_dp_device *dp = container_of(work, struct cdn_dp_device,
+ event_work);
+- struct drm_connector *connector = &dp->connector;
+- enum drm_connector_status old_status;
+-
+ int ret;
+
+ mutex_lock(&dp->lock);
+@@ -981,11 +978,7 @@ static void cdn_dp_pd_event_work(struct
+
+ out:
+ mutex_unlock(&dp->lock);
+-
+- old_status = connector->status;
+- connector->status = connector->funcs->detect(connector, false);
+- if (old_status != connector->status)
+- drm_kms_helper_hotplug_event(dp->drm_dev);
++ drm_connector_helper_hpd_irq_event(&dp->connector);
+ }
+
+ static int cdn_dp_pd_event(struct notifier_block *nb,
--- /dev/null
+From 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 9 Oct 2024 08:04:50 -0700
+Subject: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 1e7381f3617d14b3c11da80ff5f8a93ab14cfc46 upstream.
+
+Explicitly verify the target vCPU is fully online _prior_ to clamping the
+index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will
+generate '0', i.e. KVM will return vCPU0 instead of NULL.
+
+In practice, the bug is unlikely to cause problems, as it will only come
+into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
+send interrupts to vCPU0 instead of dropping them on the floor.
+
+However, returning vCPU0 when it shouldn't exist per online_vcpus is
+problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
+to insert into the xarray before publishing the vCPU to userspace (see
+commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),
+i.e. before vCPU creation is guaranteed to succeed.
+
+As a result, incorrectly providing access to vCPU0 will trigger a
+use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
+bails out of vCPU creation due to an error and frees vCPU0. Commit
+afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
+in doing so introduced an unsolvable teardown conundrum. Preventing
+accesses to vCPU0 before it's fully online will allow reverting commit
+afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.
+
+Fixes: 1d487e9bf8ba ("KVM: fix spectrev1 gadgets")
+Cc: stable@vger.kernel.org
+Cc: Will Deacon <will@kernel.org>
+Cc: Michal Luczaj <mhal@rbox.co>
+Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>
+Acked-by: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241009150455.1057573-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/kvm_host.h | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/include/linux/kvm_host.h
++++ b/include/linux/kvm_host.h
+@@ -567,6 +567,15 @@ static inline struct kvm_io_bus *kvm_get
+ static inline struct kvm_vcpu *kvm_get_vcpu(struct kvm *kvm, int i)
+ {
+ int num_vcpus = atomic_read(&kvm->online_vcpus);
++
++ /*
++ * Explicitly verify the target vCPU is online, as the anti-speculation
++ * logic only limits the CPU's ability to speculate, e.g. given a "bad"
++ * index, clamping the index to 0 would return vCPU0, not NULL.
++ */
++ if (i >= num_vcpus)
++ return NULL;
++
+ i = array_index_nospec(i, num_vcpus);
+
+ /* Pairs with smp_wmb() in kvm_vm_ioctl_create_vcpu. */
--- /dev/null
+From 5f230f41fdd9e799f43a699348dc572bca7159aa Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Tue, 7 Jan 2025 16:43:41 +0100
+Subject: KVM: s390: vsie: fix some corner-cases when grabbing vsie pages
+
+From: David Hildenbrand <david@redhat.com>
+
+commit 5f230f41fdd9e799f43a699348dc572bca7159aa upstream.
+
+We try to reuse the same vsie page when re-executing the vsie with a
+given SCB address. The result is that we use the same shadow SCB --
+residing in the vsie page -- and can avoid flushing the TLB when
+re-running the vsie on a CPU.
+
+So, when we allocate a fresh vsie page, or when we reuse a vsie page for
+a different SCB address -- reusing the shadow SCB in different context --
+we set ihcpu=0xffff to trigger the flush.
+
+However, after we looked up the SCB address in the radix tree, but before
+we grabbed the vsie page by raising the refcount to 2, someone could reuse
+the vsie page for a different SCB address, adjusting page->index and the
+radix tree. In that case, we would be reusing the vsie page with a
+wrong page->index.
+
+Another corner case is that we might set the SCB address for a vsie
+page, but fail the insertion into the radix tree. Whoever would reuse
+that page would remove the corresponding radix tree entry -- which might
+now be a valid entry pointing at another page, resulting in the wrong
+vsie page getting removed from the radix tree.
+
+Let's handle such races better, by validating that the SCB address of a
+vsie page didn't change after we grabbed it (not reuse for a different
+SCB; the alternative would be performing another tree lookup), and by
+setting the SCB address to invalid until the insertion in the tree
+succeeded (SCB addresses are aligned to 512, so ULONG_MAX is invalid).
+
+These scenarios are rare, the effects a bit unclear, and these issues were
+only found by code inspection. Let's CC stable to be safe.
+
+Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
+Tested-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
+Message-ID: <20250107154344.1003072-2-david@redhat.com>
+Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/kvm/vsie.c | 25 +++++++++++++++++++------
+ 1 file changed, 19 insertions(+), 6 deletions(-)
+
+--- a/arch/s390/kvm/vsie.c
++++ b/arch/s390/kvm/vsie.c
+@@ -1228,8 +1228,14 @@ static struct vsie_page *get_vsie_page(s
+ page = radix_tree_lookup(&kvm->arch.vsie.addr_to_page, addr >> 9);
+ rcu_read_unlock();
+ if (page) {
+- if (page_ref_inc_return(page) == 2)
+- return page_to_virt(page);
++ if (page_ref_inc_return(page) == 2) {
++ if (page->index == addr)
++ return page_to_virt(page);
++ /*
++ * We raced with someone reusing + putting this vsie
++ * page before we grabbed it.
++ */
++ }
+ page_ref_dec(page);
+ }
+
+@@ -1259,15 +1265,20 @@ static struct vsie_page *get_vsie_page(s
+ kvm->arch.vsie.next++;
+ kvm->arch.vsie.next %= nr_vcpus;
+ }
+- radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
++ if (page->index != ULONG_MAX)
++ radix_tree_delete(&kvm->arch.vsie.addr_to_page,
++ page->index >> 9);
+ }
+- page->index = addr;
+- /* double use of the same address */
++ /* Mark it as invalid until it resides in the tree. */
++ page->index = ULONG_MAX;
++
++ /* Double use of the same address or allocation failure. */
+ if (radix_tree_insert(&kvm->arch.vsie.addr_to_page, addr >> 9, page)) {
+ page_ref_dec(page);
+ mutex_unlock(&kvm->arch.vsie.mutex);
+ return NULL;
+ }
++ page->index = addr;
+ mutex_unlock(&kvm->arch.vsie.mutex);
+
+ vsie_page = page_to_virt(page);
+@@ -1360,7 +1371,9 @@ void kvm_s390_vsie_destroy(struct kvm *k
+ vsie_page = page_to_virt(page);
+ release_gmap_shadow(vsie_page);
+ /* free the radix tree entry */
+- radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
++ if (page->index != ULONG_MAX)
++ radix_tree_delete(&kvm->arch.vsie.addr_to_page,
++ page->index >> 9);
+ __free_page(page);
+ }
+ kvm->arch.vsie.page_count = 0;
--- /dev/null
+From 0d2e820a86793595e2a776855d04701109e46663 Mon Sep 17 00:00:00 2001
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Date: Thu, 14 Nov 2024 11:13:59 +0100
+Subject: leds: lp8860: Write full EEPROM, not only half of it
+
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+
+commit 0d2e820a86793595e2a776855d04701109e46663 upstream.
+
+I struggle to explain dividing an ARRAY_SIZE() by the size of an element
+once again. As the latter equals to 2, only the half of EEPROM was ever
+written. Drop the unexplainable division and write full ARRAY_SIZE().
+
+Cc: stable@vger.kernel.org
+Fixes: 7a8685accb95 ("leds: lp8860: Introduce TI lp8860 4 channel LED driver")
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Link: https://lore.kernel.org/r/20241114101402.2562878-1-alexander.sverdlin@siemens.com
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/leds/leds-lp8860.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/leds/leds-lp8860.c
++++ b/drivers/leds/leds-lp8860.c
+@@ -267,7 +267,7 @@ static int lp8860_init(struct lp8860_led
+ goto out;
+ }
+
+- reg_count = ARRAY_SIZE(lp8860_eeprom_disp_regs) / sizeof(lp8860_eeprom_disp_regs[0]);
++ reg_count = ARRAY_SIZE(lp8860_eeprom_disp_regs);
+ for (i = 0; i < reg_count; i++) {
+ ret = regmap_write(led->eeprom_regmap,
+ lp8860_eeprom_disp_regs[i].reg,
--- /dev/null
+From 53036937a101b5faeaf98e7438555fa854a1a844 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Tue, 7 Jan 2025 10:58:56 +0100
+Subject: m68k: vga: Fix I/O defines
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 53036937a101b5faeaf98e7438555fa854a1a844 upstream.
+
+Including m68k's <asm/raw_io.h> in vga.h on nommu platforms results
+in conflicting defines with io_no.h for various I/O macros from the
+__raw_read and __raw_write families. An example error is
+
+ In file included from arch/m68k/include/asm/vga.h:12,
+ from include/video/vga.h:22,
+ from include/linux/vgaarb.h:34,
+ from drivers/video/aperture.c:12:
+>> arch/m68k/include/asm/raw_io.h:39: warning: "__raw_readb" redefined
+ 39 | #define __raw_readb in_8
+ |
+ In file included from arch/m68k/include/asm/io.h:6,
+ from include/linux/io.h:13,
+ from include/linux/irq.h:20,
+ from include/asm-generic/hardirq.h:17,
+ from ./arch/m68k/include/generated/asm/hardirq.h:1,
+ from include/linux/hardirq.h:11,
+ from include/linux/interrupt.h:11,
+ from include/linux/trace_recursion.h:5,
+ from include/linux/ftrace.h:10,
+ from include/linux/kprobes.h:28,
+ from include/linux/kgdb.h:19,
+ from include/linux/fb.h:6,
+ from drivers/video/aperture.c:5:
+ arch/m68k/include/asm/io_no.h:16: note: this is the location of the previous definition
+ 16 | #define __raw_readb(addr) \
+ |
+
+Include <asm/io.h>, which avoids raw_io.h on nommu platforms.
+Also change the defined values of some of the read/write symbols in
+vga.h to __raw_read/__raw_write as the raw_in/raw_out symbols are not
+generally available.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202501071629.DNEswlm8-lkp@intel.com/
+Fixes: 5c3f968712ce ("m68k/video: Create <asm/vga.h>")
+Cc: Geert Uytterhoeven <geert@linux-m68k.org>
+Cc: linux-fbdev@vger.kernel.org
+Cc: dri-devel@lists.freedesktop.org
+Cc: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v3.5+
+Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Link: https://lore.kernel.org/20250107095912.130530-1-tzimmermann@suse.de
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/m68k/include/asm/vga.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/m68k/include/asm/vga.h
++++ b/arch/m68k/include/asm/vga.h
+@@ -9,7 +9,7 @@
+ */
+ #ifndef CONFIG_PCI
+
+-#include <asm/raw_io.h>
++#include <asm/io.h>
+ #include <asm/kmap.h>
+
+ /*
+@@ -29,9 +29,9 @@
+ #define inw_p(port) 0
+ #define outb_p(port, val) do { } while (0)
+ #define outw(port, val) do { } while (0)
+-#define readb raw_inb
+-#define writeb raw_outb
+-#define writew raw_outw
++#define readb __raw_readb
++#define writeb __raw_writeb
++#define writew __raw_writew
+
+ #endif /* CONFIG_PCI */
+ #endif /* _ASM_M68K_VGA_H */
--- /dev/null
+From 26701574cee6777f867f89b4a5c667817e1ee0dd Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <hca@linux.ibm.com>
+Date: Tue, 7 Jan 2025 11:28:58 +0100
+Subject: s390/futex: Fix FUTEX_OP_ANDN implementation
+
+From: Heiko Carstens <hca@linux.ibm.com>
+
+commit 26701574cee6777f867f89b4a5c667817e1ee0dd upstream.
+
+The futex operation FUTEX_OP_ANDN is supposed to implement
+
+*(int *)UADDR2 &= ~OPARG;
+
+The s390 implementation just implements an AND instead of ANDN.
+Add the missing bitwise not operation to oparg to fix this.
+
+This is broken since nearly 19 years, so it looks like user space is
+not making use of this operation.
+
+Fixes: 3363fbdd6fb4 ("[PATCH] s390: futex atomic operations")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/include/asm/futex.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/s390/include/asm/futex.h
++++ b/arch/s390/include/asm/futex.h
+@@ -46,7 +46,7 @@ static inline int arch_futex_atomic_op_i
+ break;
+ case FUTEX_OP_ANDN:
+ __futex_atomic_op("lr %2,%1\nnr %2,%5\n",
+- ret, oldval, newval, uaddr, oparg);
++ ret, oldval, newval, uaddr, ~oparg);
+ break;
+ case FUTEX_OP_XOR:
+ __futex_atomic_op("lr %2,%1\nxr %2,%5\n",
net-rose-lock-the-socket-in-rose_bind.patch
netem-update-sch-q.qlen-before-qdisc_tree_reduce_bac.patch
tun-revert-fix-group-permission-check.patch
+cpufreq-s3c64xx-fix-compilation-warning.patch
+leds-lp8860-write-full-eeprom-not-only-half-of-it.patch
+s390-futex-fix-futex_op_andn-implementation.patch
+m68k-vga-fix-i-o-defines.patch
+binfmt_flat-fix-integer-overflow-bug-on-32-bit-systems.patch
+drm-rockchip-cdn-dp-use-drm_connector_helper_hpd_irq_event.patch
+arm64-dts-rockchip-increase-gmac-rx_delay-on-rk3399-puma.patch
+kvm-explicitly-verify-target-vcpu-is-online-in-kvm_get_vcpu.patch
+kvm-s390-vsie-fix-some-corner-cases-when-grabbing-vsie-pages.patch
+drm-komeda-add-check-for-komeda_get_layer_fourcc_list.patch
+bluetooth-l2cap-handle-null-sock-pointer-in-l2cap_sock_alloc.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
