--- /dev/null
+From 89384a2b656b9dace4c965432a209d5c9c3a2a6f Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Sat, 16 Mar 2024 23:56:57 +0100
+Subject: dt-bindings: iio: health: maxim,max30102: fix compatible check
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 89384a2b656b9dace4c965432a209d5c9c3a2a6f upstream.
+
+The "maxim,green-led-current-microamp" property is only available for
+the max30105 part (it provides an extra green LED), and must be set to
+false for the max30102 part.
+
+Instead, the max30100 part has been used for that, which is not
+supported by this binding (it has its own binding).
+
+This error was introduced during the txt to yaml conversion.
+
+Fixes: 5a6a65b11e3a ("dt-bindings:iio:health:maxim,max30102: txt to yaml conversion")
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Acked-by: Conor Dooley <conor.dooley@microchip.com>
+Link: https://lore.kernel.org/r/20240316-max30102_binding_fix-v1-1-e8e58f69ef8a@gmail.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml
++++ b/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml
+@@ -42,7 +42,7 @@ allOf:
+ properties:
+ compatible:
+ contains:
+- const: maxim,max30100
++ const: maxim,max30102
+ then:
+ properties:
+ maxim,green-led-current-microamp: false
--- /dev/null
+From 57a1592784d622ecee0b71940c65429173996b33 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Tue, 26 Mar 2024 12:36:59 +0100
+Subject: iio: accel: mxc4005: Interrupt handling fixes
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 57a1592784d622ecee0b71940c65429173996b33 upstream.
+
+There are 2 issues with interrupt handling in the mxc4005 driver:
+
+1. mxc4005_set_trigger_state() writes MXC4005_REG_INT_MASK1_BIT_DRDYE
+(0x01) to INT_MASK1 to enable the interrupt, but to disable the interrupt
+it writes ~MXC4005_REG_INT_MASK1_BIT_DRDYE which is 0xfe, so it enables
+all other interrupt sources in the INT_SRC1 register. On the MXC4005 this
+is not an issue because only bit 0 of the register is used. On the MXC6655
+OTOH this is a problem since bit7 is used as TC (Temperature Compensation)
+disable bit and writing 1 to this disables Temperature Compensation which
+should only be done when running self-tests on the chip.
+
+Write 0 instead of ~MXC4005_REG_INT_MASK1_BIT_DRDYE to disable
+the interrupts to fix this.
+
+2. The datasheets for the MXC4005 / MXC6655 do not state what the reset
+value for the INT_MASK0 and INT_MASK1 registers is and since these are
+write only we also cannot learn this from the hw. Presumably the reset
+value for both is all 0, which means all interrupts disabled.
+
+Explicitly set both registers to 0 from mxc4005_chip_init() to ensure
+both masks are actually set to 0.
+
+Fixes: 79846e33aac1 ("iio: accel: mxc4005: add support for mxc6655")
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20240326113700.56725-2-hdegoede@redhat.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/accel/mxc4005.c | 24 +++++++++++++++++-------
+ 1 file changed, 17 insertions(+), 7 deletions(-)
+
+--- a/drivers/iio/accel/mxc4005.c
++++ b/drivers/iio/accel/mxc4005.c
+@@ -27,9 +27,13 @@
+ #define MXC4005_REG_ZOUT_UPPER 0x07
+ #define MXC4005_REG_ZOUT_LOWER 0x08
+
++#define MXC4005_REG_INT_MASK0 0x0A
++
+ #define MXC4005_REG_INT_MASK1 0x0B
+ #define MXC4005_REG_INT_MASK1_BIT_DRDYE 0x01
+
++#define MXC4005_REG_INT_CLR0 0x00
++
+ #define MXC4005_REG_INT_CLR1 0x01
+ #define MXC4005_REG_INT_CLR1_BIT_DRDYC 0x01
+
+@@ -113,7 +117,9 @@ static bool mxc4005_is_readable_reg(stru
+ static bool mxc4005_is_writeable_reg(struct device *dev, unsigned int reg)
+ {
+ switch (reg) {
++ case MXC4005_REG_INT_CLR0:
+ case MXC4005_REG_INT_CLR1:
++ case MXC4005_REG_INT_MASK0:
+ case MXC4005_REG_INT_MASK1:
+ case MXC4005_REG_CONTROL:
+ return true;
+@@ -330,17 +336,13 @@ static int mxc4005_set_trigger_state(str
+ {
+ struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
+ struct mxc4005_data *data = iio_priv(indio_dev);
++ unsigned int val;
+ int ret;
+
+ mutex_lock(&data->mutex);
+- if (state) {
+- ret = regmap_write(data->regmap, MXC4005_REG_INT_MASK1,
+- MXC4005_REG_INT_MASK1_BIT_DRDYE);
+- } else {
+- ret = regmap_write(data->regmap, MXC4005_REG_INT_MASK1,
+- ~MXC4005_REG_INT_MASK1_BIT_DRDYE);
+- }
+
++ val = state ? MXC4005_REG_INT_MASK1_BIT_DRDYE : 0;
++ ret = regmap_write(data->regmap, MXC4005_REG_INT_MASK1, val);
+ if (ret < 0) {
+ mutex_unlock(&data->mutex);
+ dev_err(data->dev, "failed to update reg_int_mask1");
+@@ -382,6 +384,14 @@ static int mxc4005_chip_init(struct mxc4
+
+ dev_dbg(data->dev, "MXC4005 chip id %02x\n", reg);
+
++ ret = regmap_write(data->regmap, MXC4005_REG_INT_MASK0, 0);
++ if (ret < 0)
++ return dev_err_probe(data->dev, ret, "writing INT_MASK0\n");
++
++ ret = regmap_write(data->regmap, MXC4005_REG_INT_MASK1, 0);
++ if (ret < 0)
++ return dev_err_probe(data->dev, ret, "writing INT_MASK1\n");
++
+ return 0;
+ }
+
--- /dev/null
+From 74a72baf204fd509bbe8b53eec35e39869d94341 Mon Sep 17 00:00:00 2001
+From: Ramona Gradinariu <ramona.bolboaca13@gmail.com>
+Date: Fri, 5 Apr 2024 07:53:09 +0300
+Subject: iio:imu: adis16475: Fix sync mode setting
+
+From: Ramona Gradinariu <ramona.bolboaca13@gmail.com>
+
+commit 74a72baf204fd509bbe8b53eec35e39869d94341 upstream.
+
+Fix sync mode setting by applying the necessary shift bits.
+
+Fixes: fff7352bf7a3 ("iio: imu: Add support for adis16475")
+Signed-off-by: Ramona Gradinariu <ramona.bolboaca13@gmail.com>
+Reviewed-by: Nuno Sa <nuno.sa@analog.com>
+Link: https://lore.kernel.org/r/20240405045309.816328-2-ramona.bolboaca13@gmail.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/adis16475.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/imu/adis16475.c
++++ b/drivers/iio/imu/adis16475.c
+@@ -1126,6 +1126,7 @@ static int adis16475_config_sync_mode(st
+ struct device *dev = &st->adis.spi->dev;
+ const struct adis16475_sync *sync;
+ u32 sync_mode;
++ u16 val;
+
+ /* default to internal clk */
+ st->clk_freq = st->info->int_clk * 1000;
+@@ -1187,8 +1188,9 @@ static int adis16475_config_sync_mode(st
+ * I'm keeping this for simplicity and avoiding extra variables
+ * in chip_info.
+ */
++ val = ADIS16475_SYNC_MODE(sync->sync_mode);
+ ret = __adis_update_bits(&st->adis, ADIS16475_REG_MSG_CTRL,
+- ADIS16475_SYNC_MODE_MASK, sync->sync_mode);
++ ADIS16475_SYNC_MODE_MASK, val);
+ if (ret)
+ return ret;
+
--- /dev/null
+From 90d1f14cbb9ddbfc532e2da13bf6e0ed8320e792 Mon Sep 17 00:00:00 2001
+From: Alexander Potapenko <glider@google.com>
+Date: Fri, 26 Apr 2024 11:16:22 +0200
+Subject: kmsan: compiler_types: declare __no_sanitize_or_inline
+
+From: Alexander Potapenko <glider@google.com>
+
+commit 90d1f14cbb9ddbfc532e2da13bf6e0ed8320e792 upstream.
+
+It turned out that KMSAN instruments READ_ONCE_NOCHECK(), resulting in
+false positive reports, because __no_sanitize_or_inline enforced inlining.
+
+Properly declare __no_sanitize_or_inline under __SANITIZE_MEMORY__, so
+that it does not __always_inline the annotated function.
+
+Link: https://lkml.kernel.org/r/20240426091622.3846771-1-glider@google.com
+Fixes: 5de0ce85f5a4 ("kmsan: mark noinstr as __no_sanitize_memory")
+Signed-off-by: Alexander Potapenko <glider@google.com>
+Reported-by: syzbot+355c5bb8c1445c871ee8@syzkaller.appspotmail.com
+Link: https://lkml.kernel.org/r/000000000000826ac1061675b0e3@google.com
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Marco Elver <elver@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/compiler_types.h | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/include/linux/compiler_types.h
++++ b/include/linux/compiler_types.h
+@@ -226,6 +226,17 @@ struct ftrace_likely_data {
+ # define __no_kcsan
+ #endif
+
++#ifdef __SANITIZE_MEMORY__
++/*
++ * Similarly to KASAN and KCSAN, KMSAN loses function attributes of inlined
++ * functions, therefore disabling KMSAN checks also requires disabling inlining.
++ *
++ * __no_sanitize_or_inline effectively prevents KMSAN from reporting errors
++ * within the function and marks all its outputs as initialized.
++ */
++# define __no_sanitize_or_inline __no_kmsan_checks notrace __maybe_unused
++#endif
++
+ #ifndef __no_sanitize_or_inline
+ #define __no_sanitize_or_inline __always_inline
+ #endif
--- /dev/null
+From fb7a0d334894206ae35f023a82cad5a290fd7386 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Mon, 29 Apr 2024 20:00:31 +0200
+Subject: mptcp: ensure snd_nxt is properly initialized on connect
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit fb7a0d334894206ae35f023a82cad5a290fd7386 upstream.
+
+Christoph reported a splat hinting at a corrupted snd_una:
+
+ WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
+ Modules linked in:
+ CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
+ Workqueue: events mptcp_worker
+ RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
+ Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
+ 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
+ <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
+ RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
+ RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
+ RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
+ RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
+ R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
+ R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
+ FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
+ Call Trace:
+ <TASK>
+ __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
+ mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
+ __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
+ mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
+ process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
+ process_scheduled_works kernel/workqueue.c:3335 [inline]
+ worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
+ kthread+0x121/0x170 kernel/kthread.c:388
+ ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
+ ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
+ </TASK>
+
+When fallback to TCP happens early on a client socket, snd_nxt
+is not yet initialized and any incoming ack will copy such value
+into snd_una. If the mptcp worker (dumbly) tries mptcp-level
+re-injection after such ack, that would unconditionally trigger a send
+buffer cleanup using 'bad' snd_una values.
+
+We could easily disable re-injection for fallback sockets, but such
+dumb behavior already helped catching a few subtle issues and a very
+low to zero impact in practice.
+
+Instead address the issue always initializing snd_nxt (and write_seq,
+for consistency) at connect time.
+
+Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect")
+Cc: stable@vger.kernel.org
+Reported-by: Christoph Paasch <cpaasch@apple.com>
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485
+Tested-by: Christoph Paasch <cpaasch@apple.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -3754,6 +3754,9 @@ static int mptcp_connect(struct sock *sk
+ MPTCP_INC_STATS(sock_net(ssock->sk), MPTCP_MIB_TOKENFALLBACKINIT);
+ mptcp_subflow_early_fallback(msk, subflow);
+ }
++
++ WRITE_ONCE(msk->write_seq, subflow->idsn);
++ WRITE_ONCE(msk->snd_nxt, subflow->idsn);
+ if (likely(!__mptcp_check_fallback(msk)))
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEACTIVE);
+
alsa-hda-realtek-fix-mute-led-of-hp-laptop-15-da3001tu.patch
btrfs-add-missing-mutex_unlock-in-btrfs_relocate_sys_chunks.patch
mm-slab-make-__free-kfree-accept-error-pointers.patch
+mptcp-ensure-snd_nxt-is-properly-initialized-on-connect.patch
+dt-bindings-iio-health-maxim-max30102-fix-compatible-check.patch
+iio-imu-adis16475-fix-sync-mode-setting.patch
+iio-accel-mxc4005-interrupt-handling-fixes.patch
+kmsan-compiler_types-declare-__no_sanitize_or_inline.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
