Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

80 participants
123768 discussions

[PATCH] hwmon: (ibmpex) Fix use-after-free in sysfs removal

by Junrui Luo

There is a use-after-free vulnerability in the ibmpex driver where the driver frees the sensors array while sysfs read operations via ibmpex_show_sensor() are still in progress. Fix this by reordering cleanup operations in ibmpex_bmc_delete(). Reported-by: Yuhao Jiang <danisjiang(a)gmail.com> Reported-by: Junrui Luo <moonafterrain(a)outlook.com> Fixes: 57c7c3a0fdea ("hwmon: IBM power meter driver") Cc: stable(a)vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain(a)outlook.com> --- drivers/hwmon/ibmpex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c index 228c5f6c6f38..578549f44154 100644 --- a/drivers/hwmon/ibmpex.c +++ b/drivers/hwmon/ibmpex.c @@ -508,6 +508,7 @@ static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data) { int i, j; + hwmon_device_unregister(data->hwmon_dev); device_remove_file(data->bmc_device, &sensor_dev_attr_reset_high_low.dev_attr); device_remove_file(data->bmc_device, &dev_attr_name.attr); @@ -522,7 +523,6 @@ static void ibmpex_bmc_delete(struct ibmpex_bmc_data *data) list_del(&data->list); dev_set_drvdata(data->bmc_device, NULL); - hwmon_device_unregister(data->hwmon_dev); ipmi_destroy_user(data->user); kfree(data->sensors); kfree(data); --- base-commit: cfd4039213e7b5a828c5b78e1b5235cac91af53d change-id: 20251218-fixes-25f078f93a1c Best regards, -- Junrui Luo <moonafterrain(a)outlook.com>

2 weeks, 2 days

[PATCH AUTOSEL 6.18-6.6] iomap: adjust read range correctly for non-block-aligned positions

by Sasha Levin

From: Joanne Koong <joannelkoong(a)gmail.com> [ Upstream commit 7aa6bc3e8766990824f66ca76c19596ce10daf3e ] iomap_adjust_read_range() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio. Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks. Signed-off-by: Joanne Koong <joannelkoong(a)gmail.com> Tested-by: syzbot(a)syzkaller.appspotmail.com Reviewed-by: Brian Foster <bfoster(a)redhat.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Now I have all the information needed for a comprehensive analysis. Let me compile my findings. --- ## COMPREHENSIVE ANALYSIS: iomap_adjust_read_range() Bug Fix ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `iomap: adjust read range correctly for non-block-aligned positions` **Key Points from Message:** - The function `iomap_adjust_read_range()` **assumes block-aligned positions**, but this assumption is violated - Bug was discovered via **syzbot testing with erofs** filesystem - Causes "too many bytes to be skipped for uptodate blocks" - Results in **incorrect position and length to read** - If all blocks are uptodate: **underflows length** and **returns position beyond the folio** **Tags Analysis:** - ✅ `Tested-by: syzbot(a)syzkaller.appspotmail.com` - Automated testing confirmed - ✅ `Reviewed-by: Brian Foster <bfoster(a)redhat.com>` - Red Hat filesystem expert - ✅ `Reviewed-by: Christoph Hellwig <hch(a)lst.de>` - Major iomap author - ✅ `Signed-off-by: Christian Brauner <brauner(a)kernel.org>` - VFS maintainer - ❌ **No `Cc: stable(a)vger.kernel.org`** tag - ❌ **No `Fixes:` tag** pointing to original buggy commit ### 2. CODE CHANGE ANALYSIS **Bug Location:** `fs/iomap/buffered-io.c`, function `iomap_adjust_read_range()` **The Buggy Code (lines 246-253 before fix):** ```c for (i = first; i <= last; i++) { if (!ifs_block_is_uptodate(ifs, i)) break; *pos += block_size; // Bug: assumes pos is block-aligned poff += block_size; plen -= block_size; first++; } ``` **Technical Root Cause:** When `*pos` has a sub-block offset (e.g., `pos = 512` in a 1024-byte block): - `first = poff >> block_bits` computes the block index correctly (block 0) - But the loop skips a full `block_size` per block, ignoring the offset **Example demonstrating the bug:** - Block size: 1024 bytes - Position: 512 (half-way into block 0) - Block 0 is uptodate **Old buggy calculation:** - Skip full 1024 bytes → `pos = 1536`, overshoots by 512 bytes - `plen -= 1024` → underflows if `plen < 1024` **Fixed calculation:** ```c blocks_skipped = i - first; if (blocks_skipped) { unsigned long block_offset = *pos & (block_size - 1); // = 512 unsigned bytes_skipped = (blocks_skipped << block_bits) - block_offset; // = 1024 - 512 = 512 *pos += bytes_skipped; // Correct: pos = 1024 poff += bytes_skipped; plen -= bytes_skipped; } ``` **Consequences of the Bug:** 1. **Integer underflow**: `plen` becomes huge (wraps around as unsigned) 2. **Position beyond folio**: `*pos` can point past the folio boundary 3. **Incorrect read ranges**: Wrong data read, potential corruption 4. **Potential crashes**: Invalid memory access from bad ranges ### 3. CLASSIFICATION - **Type:** BUG FIX (arithmetic/logic error causing incorrect calculations) - **NOT:** Feature addition, cleanup, or optimization - **Severity:** HIGH - affects filesystem data integrity - **Scope:** Core iomap buffered I/O infrastructure ### 4. SCOPE AND RISK ASSESSMENT **Change Size:** - 13 insertions, 6 deletions - Single file: `fs/iomap/buffered-io.c` - Localized to one function **Risk Level:** LOW - Fix is mathematically straightforward - Does not change control flow significantly - Well-reviewed by iomap experts - Tested by syzbot **Affected Subsystem:** `fs/iomap/` - mature, widely-used infrastructure **Affected Filesystems:** Multiple major filesystems use iomap: - **XFS** - Primary enterprise Linux filesystem - **GFS2** - Cluster filesystem - **erofs** - Read-only filesystem (Android) - **zonefs** - Zoned storage filesystem - **fuse** - User-space filesystems ### 5. USER IMPACT **Who is affected?** - ALL users of XFS, GFS2, erofs, zonefs, and fuse filesystems - Particularly affects systems with: - Block sizes smaller than page size - Partial folio reads/writes at non-block-aligned offsets **How severe?** - Can cause **incorrect data reads** - Potential **data corruption** in read paths - Possible **kernel crashes** from invalid memory access - **Data integrity** issues for critical filesystems **Triggered by:** syzbot (automated fuzzing) - confirms this is a real triggerable bug ### 6. STABILITY INDICATORS - ✅ `Tested-by: syzbot` - Confirmed fix works - ✅ Two expert reviewers (Brian Foster, Christoph Hellwig) - ✅ Merged by VFS maintainer (Christian Brauner) - ⚠️ Relatively new commit (September 2025) ### 7. DEPENDENCY CHECK **Bug Origin:** Commit `9dc55f1389f95` ("iomap: add support for sub- pagesize buffered I/O without buffer heads") from **v4.19-rc1** (2018) **Dependencies for backport:** - The fix is self-contained - May need minor adaptation for older kernels: - v5.x: Uses `struct iomap_page` and pages (not folios) - v6.x: Uses `struct iomap_folio_state` and folios - Core logic remains the same across versions **Related commits:** - `8e3c15ee0d292` - Minor loop syntax change (`for` → `while`), NOT a dependency - `9d875e0eef8ec` - Related fix for unaligned END offsets (separate issue) ### 8. HISTORICAL CONTEXT The bug has existed for **~6 years** (since v4.19). It was latent because: - Most callers pass block-aligned positions - erofs triggered an edge case with non-aligned positions - syzbot's extensive testing exposed it The original code assumed callers would always pass block-aligned positions, which is a reasonable assumption violated in specific edge cases. --- ## BACKPORT RECOMMENDATION ### Arguments FOR backporting: 1. **Fixes a real bug** discovered by automated testing (syzbot) 2. **Affects critical filesystems** (XFS, GFS2) used in production 3. **Small, surgical fix** - 13 lines added, 6 removed 4. **Low regression risk** - mathematically correct fix 5. **Expert-reviewed** by iomap maintainers 6. **Bug existed since v4.19** - all stable trees are affected 7. **Can cause data integrity issues** - serious for a filesystem bug ### Arguments AGAINST backporting: 1. **No `Cc: stable` tag** - maintainers didn't explicitly request backport 2. **No `Fixes:` tag** - doesn't identify the buggy commit 3. **Relatively new commit** - hasn't had extensive mainline testing yet 4. **Needs adaptation** for older kernels (page vs folio APIs) ### Conclusion: Despite the missing stable tags, this commit should be backported because: - It fixes a **real, triggerable bug** found by syzbot - The bug can cause **incorrect data reads and potential corruption** - It affects **major filesystems** (XFS, GFS2) used in production environments - The fix is **small, contained, and well-reviewed** - The **risk of NOT fixing** (data corruption) outweighs the risk of the fix (minimal) The absence of `Cc: stable` may be an oversight, as this clearly meets stable criteria. **YES** fs/iomap/buffered-io.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 8b847a1e27f13..1c95a0a7b302d 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -240,17 +240,24 @@ static void iomap_adjust_read_range(struct inode *inode, struct folio *folio, * to avoid reading in already uptodate ranges. */ if (ifs) { - unsigned int i; + unsigned int i, blocks_skipped; /* move forward for each leading block marked uptodate */ - for (i = first; i <= last; i++) { + for (i = first; i <= last; i++) if (!ifs_block_is_uptodate(ifs, i)) break; - *pos += block_size; - poff += block_size; - plen -= block_size; - first++; + + blocks_skipped = i - first; + if (blocks_skipped) { + unsigned long block_offset = *pos & (block_size - 1); + unsigned bytes_skipped = + (blocks_skipped << block_bits) - block_offset; + + *pos += bytes_skipped; + poff += bytes_skipped; + plen -= bytes_skipped; } + first = i; /* truncate len if we find any trailing uptodate block(s) */ while (++i <= last) { -- 2.51.0

2 weeks, 2 days

[PATCH 0/2] net: qrtr: Drop the MHI 'auto_queue' feature

by Manivannan Sadhasivam via B4 Relay

Hi, This series intends to fix the race between the MHI stack and the MHI client drivers due to the MHI 'auto_queue' feature. As it turns out often, the best way to fix an issue in a feature is to drop the feature itself and this series does exactly that. There is no real benefit in having the 'auto_queue' feature in the MHI stack, other than saving a few lines of code in the client drivers. Since the QRTR is the only client driver which makes use of this feature, this series reworks the QRTR driver to manage the buffer on its own. Testing ======= Tested on Qcom X1E based Lenovo Thinkpad T14s laptop with WLAN device. Merge Strategy ============== Since this series modifies many subsystem drivers, I'd like to get acks from relevant subsystem maintainers and take the series through MHI tree. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com> --- Manivannan Sadhasivam (2): net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels bus: mhi: host: Drop the auto_queue support drivers/accel/qaic/mhi_controller.c | 44 ------------------- drivers/bus/mhi/host/init.c | 10 ----- drivers/bus/mhi/host/internal.h | 3 -- drivers/bus/mhi/host/main.c | 81 +---------------------------------- drivers/bus/mhi/host/pci_generic.c | 20 +-------- drivers/net/wireless/ath/ath11k/mhi.c | 4 -- drivers/net/wireless/ath/ath12k/mhi.c | 4 -- include/linux/mhi.h | 14 ------ net/qrtr/mhi.c | 67 ++++++++++++++++++++++++----- 9 files changed, 60 insertions(+), 187 deletions(-) --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251217-qrtr-fix-c058251d8d1a Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com>

2 weeks, 2 days

[PATCH v5 01/24] drm/xe/svm: Fix a debug printout

by Thomas Hellström

Avoid spamming the log with drm_info(). Use drm_dbg() instead. Fixes: cc795e041034 ("drm/xe/svm: Make xe_svm_range_needs_migrate_to_vram() public") Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.17+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> --- drivers/gpu/drm/xe/xe_svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c index 93550c7c84ac..bab8e6cbe53d 100644 --- a/drivers/gpu/drm/xe/xe_svm.c +++ b/drivers/gpu/drm/xe/xe_svm.c @@ -937,7 +937,7 @@ bool xe_svm_range_needs_migrate_to_vram(struct xe_svm_range *range, struct xe_vm xe_assert(vm->xe, IS_DGFX(vm->xe)); if (xe_svm_range_in_vram(range)) { - drm_info(&vm->xe->drm, "Range is already in VRAM\n"); + drm_dbg(&vm->xe->drm, "Range is already in VRAM\n"); return false; } -- 2.51.1

2 weeks, 2 days

[PATCH] RDMA/cxgb4: fix a memory leak in pass_accept_req() error path

by Wentao Liang

In the alloc_ep_skb_list() failure path, the c4iw_put_ep() is incorrectly used instead of the kfree(). Since the child_ep's reference count hasn't been properly established at this point, the c4iw_put_ep() won't actually free the memory, resulting in permanent memory leak. Fix by releasing child_ep correctly in the fail path. Fixes: 4a740838bf44 ("RDMA/iw_cxgb4: Low resource fixes for connection manager") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/infiniband/hw/cxgb4/cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c index b3b45c49077d..a09eeb48775f 100644 --- a/drivers/infiniband/hw/cxgb4/cm.c +++ b/drivers/infiniband/hw/cxgb4/cm.c @@ -2665,7 +2665,7 @@ static int pass_accept_req(struct c4iw_dev *dev, struct sk_buff *skb) } goto out; fail: - c4iw_put_ep(&child_ep->com); + kfree(child_ep); reject: reject_cr(dev, hwtid, skb); out: -- 2.34.1

2 weeks, 3 days

[PATCH] RDMA/cxgb4: fix dst refcount leak in pass_accept_req() error path

by Wentao Liang

Add missing dst_release() when alloc_ep_skb_list() fails to prevent reference count leak of the dst obtained from route lookup. Fixes: 4a740838bf44 ("RDMA/iw_cxgb4: Low resource fixes for connection manager") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/infiniband/hw/cxgb4/cm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c index b3b45c49077d..3490b8920cf0 100644 --- a/drivers/infiniband/hw/cxgb4/cm.c +++ b/drivers/infiniband/hw/cxgb4/cm.c @@ -2665,6 +2665,7 @@ static int pass_accept_req(struct c4iw_dev *dev, struct sk_buff *skb) } goto out; fail: + dst_release(dst); c4iw_put_ep(&child_ep->com); reject: reject_cr(dev, hwtid, skb); -- 2.34.1

2 weeks, 3 days

[PATCH v5] w1: therm: Fix off-by-one buffer overflow in alarms_store

by Thorsten Blum

The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code. Cc: stable(a)vger.kernel.org Fixes: e2c94d6f5720 ("w1_therm: adding alarm sysfs entry") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Compile-tested only. Changes in v5: - Replace gotos with return size (Krzysztof) - Link to v4: https://lore.kernel.org/lkml/20251111204422.41993-2-thorsten.blum@linux.dev/ Changes in v4: - Use simple_strtoll because kstrtoint also parses long long internally - Return -ERANGE in addition to -EINVAL to match kstrtoint's behavior - Remove any changes unrelated to fixing the buffer overflow (Krzysztof) while maintaining the same behavior and return values as before - Link to v3: https://lore.kernel.org/lkml/20251030155614.447905-1-thorsten.blum@linux.de… Changes in v3: - Add integer range check for 'temp' to match kstrtoint() behavior - Explicitly cast 'temp' to int when calling int_to_short() - Link to v2: https://lore.kernel.org/lkml/20251029130045.70127-2-thorsten.blum@linux.dev/ Changes in v2: - Fix buffer overflow instead of truncating the copy using strscpy() - Parse buffer directly using simple_strtol() as suggested by David - Update patch subject and description - Link to v1: https://lore.kernel.org/lkml/20251017170047.114224-2-thorsten.blum@linux.de… --- drivers/w1/slaves/w1_therm.c | 63 ++++++++++++------------------------ 1 file changed, 20 insertions(+), 43 deletions(-) diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c index 9ccedb3264fb..5c4e40883400 100644 --- a/drivers/w1/slaves/w1_therm.c +++ b/drivers/w1/slaves/w1_therm.c @@ -1836,55 +1836,36 @@ static ssize_t alarms_store(struct device *device, struct w1_slave *sl = dev_to_w1_slave(device); struct therm_info info; u8 new_config_register[3]; /* array of data to be written */ - int temp, ret; - char *token = NULL; + long long temp; + int ret = 0; s8 tl, th; /* 1 byte per value + temp ring order */ - char *p_args, *orig; - - p_args = orig = kmalloc(size, GFP_KERNEL); - /* Safe string copys as buf is const */ - if (!p_args) { - dev_warn(device, - "%s: error unable to allocate memory %d\n", - __func__, -ENOMEM); - return size; - } - strcpy(p_args, buf); - - /* Split string using space char */ - token = strsep(&p_args, " "); - - if (!token) { - dev_info(device, - "%s: error parsing args %d\n", __func__, -EINVAL); - goto free_m; - } - - /* Convert 1st entry to int */ - ret = kstrtoint (token, 10, &temp); + const char *p = buf; + char *endp; + + temp = simple_strtoll(p, &endp, 10); + if (p == endp || *endp != ' ') + ret = -EINVAL; + else if (temp < INT_MIN || temp > INT_MAX) + ret = -ERANGE; if (ret) { dev_info(device, "%s: error parsing args %d\n", __func__, ret); - goto free_m; + return size; } tl = int_to_short(temp); - /* Split string using space char */ - token = strsep(&p_args, " "); - if (!token) { - dev_info(device, - "%s: error parsing args %d\n", __func__, -EINVAL); - goto free_m; - } - /* Convert 2nd entry to int */ - ret = kstrtoint (token, 10, &temp); + p = endp + 1; + temp = simple_strtoll(p, &endp, 10); + if (p == endp) + ret = -EINVAL; + else if (temp < INT_MIN || temp > INT_MAX) + ret = -ERANGE; if (ret) { dev_info(device, "%s: error parsing args %d\n", __func__, ret); - goto free_m; + return size; } - /* Prepare to cast to short by eliminating out of range values */ th = int_to_short(temp); @@ -1905,7 +1886,7 @@ static ssize_t alarms_store(struct device *device, dev_info(device, "%s: error reading from the slave device %d\n", __func__, ret); - goto free_m; + return size; } /* Write data in the device RAM */ @@ -1913,7 +1894,7 @@ static ssize_t alarms_store(struct device *device, dev_info(device, "%s: Device not supported by the driver %d\n", __func__, -ENODEV); - goto free_m; + return size; } ret = SLAVE_SPECIFIC_FUNC(sl)->write_data(sl, new_config_register); @@ -1922,10 +1903,6 @@ static ssize_t alarms_store(struct device *device, "%s: error writing to the slave device %d\n", __func__, ret); -free_m: - /* free allocated memory */ - kfree(orig); - return size; } -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

2 weeks, 3 days

[PATCH v2] net: nfc: nci: Fix parameter validation for packet data

by Michael Thalmeier

Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). For these cases it is only possible to check for minimum packet length. Fixes: 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") Cc: stable(a)vger.kernel.org Signed-off-by: Michael Thalmeier <michael.thalmeier(a)hale.at> --- Changes in v2: - Reference correct commit hash --- net/nfc/nci/ntf.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c index 418b84e2b260..5161e94f067f 100644 --- a/net/nfc/nci/ntf.c +++ b/net/nfc/nci/ntf.c @@ -58,7 +58,8 @@ static int nci_core_conn_credits_ntf_packet(struct nci_dev *ndev, struct nci_conn_info *conn_info; int i; - if (skb->len < sizeof(struct nci_core_conn_credit_ntf)) + /* Minimal packet size for num_entries=1 is 1 x __u8 + 1 x conn_credit_entry */ + if (skb->len < (sizeof(__u8) + sizeof(struct conn_credit_entry))) return -EINVAL; ntf = (struct nci_core_conn_credit_ntf *)skb->data; @@ -364,7 +365,8 @@ static int nci_rf_discover_ntf_packet(struct nci_dev *ndev, const __u8 *data; bool add_target = true; - if (skb->len < sizeof(struct nci_rf_discover_ntf)) + /* Minimal packet size is 5 if rf_tech_specific_params_len=0 */ + if (skb->len < (5 * sizeof(__u8))) return -EINVAL; data = skb->data; @@ -596,7 +598,10 @@ static int nci_rf_intf_activated_ntf_packet(struct nci_dev *ndev, const __u8 *data; int err = NCI_STATUS_OK; - if (skb->len < sizeof(struct nci_rf_intf_activated_ntf)) + /* Minimal packet size is 11 if + * f_tech_specific_params_len=0 and activation_params_len=0 + */ + if (skb->len < (11 * sizeof(__u8))) return -EINVAL; data = skb->data; -- 2.52.0

2 weeks, 3 days

[PATCH v2] i2c: riic: Move suspend handling to NOIRQ phase

by Tommaso Merciai

Commit 53326135d0e0 ("i2c: riic: Add suspend/resume support") added suspend support for the Renesas I2C driver and following this change on RZ/G3E the following WARNING is seen on entering suspend ... [ 134.275704] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 134.285536] ------------[ cut here ]------------ [ 134.290298] i2c i2c-2: Transfer while suspended [ 134.295174] WARNING: drivers/i2c/i2c-core.h:56 at __i2c_smbus_xfer+0x1e4/0x214, CPU#0: systemd-sleep/388 [ 134.365507] Tainted: [W]=WARN [ 134.368485] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT) [ 134.375961] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 134.382935] pc : __i2c_smbus_xfer+0x1e4/0x214 [ 134.387329] lr : __i2c_smbus_xfer+0x1e4/0x214 [ 134.391717] sp : ffff800083f23860 [ 134.395040] x29: ffff800083f23860 x28: 0000000000000000 x27: ffff800082ed5d60 [ 134.402226] x26: 0000001f4395fd74 x25: 0000000000000007 x24: 0000000000000001 [ 134.409408] x23: 0000000000000000 x22: 000000000000006f x21: ffff800083f23936 [ 134.416589] x20: ffff0000c090e140 x19: ffff0000c090e0d0 x18: 0000000000000006 [ 134.423771] x17: 6f63657320313030 x16: 2e30206465737061 x15: ffff800083f23280 [ 134.430953] x14: 0000000000000000 x13: ffff800082b16ce8 x12: 0000000000000f09 [ 134.438134] x11: 0000000000000503 x10: ffff800082b6ece8 x9 : ffff800082b16ce8 [ 134.445315] x8 : 00000000ffffefff x7 : ffff800082b6ece8 x6 : 80000000fffff000 [ 134.452495] x5 : 0000000000000504 x4 : 0000000000000000 x3 : 0000000000000000 [ 134.459672] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c9ee9e80 [ 134.466851] Call trace: [ 134.469311] __i2c_smbus_xfer+0x1e4/0x214 (P) [ 134.473715] i2c_smbus_xfer+0xbc/0x120 [ 134.477507] i2c_smbus_read_byte_data+0x4c/0x84 [ 134.482077] isl1208_i2c_read_time+0x44/0x178 [rtc_isl1208] [ 134.487703] isl1208_rtc_read_time+0x14/0x20 [rtc_isl1208] [ 134.493226] __rtc_read_time+0x44/0x88 [ 134.497012] rtc_read_time+0x3c/0x68 [ 134.500622] rtc_suspend+0x9c/0x170 The warning is triggered because I2C transfers can still be attempted while the controller is already suspended, due to inappropriate ordering of the system sleep callbacks. If the controller is autosuspended, there is no way to wake it up once runtime PM disabled (in suspend_late()). During system resume, the I2C controller will be available only after runtime PM is re-enabled (in resume_early()). However, this may be too late for some devices. Wake up the controller in the suspend() callback while runtime PM is still enabled. The I2C controller will remain available until the suspend_noirq() callback (pm_runtime_force_suspend()) is called. During resume, the I2C controller can be restored by the resume_noirq() callback (pm_runtime_force_resume()). Finally, the resume() callback re-enables autosuspend. As a result, the I2C controller can remain available until the system enters suspend_noirq() and from resume_noirq(). Cc: stable(a)vger.kernel.org Fixes: 53326135d0e0 ("i2c: riic: Add suspend/resume support") Signed-off-by: Tommaso Merciai <tommaso.merciai.xr(a)bp.renesas.com> --- v1->v2: - Taking as reference commit: 4262df2a69c3 ("i2c: imx-lpi2c: make controller available until the system enters suspend_noirq() and from resume_noirq().") reworked the patch with a similar approach. Updated commit body accordingly. drivers/i2c/busses/i2c-riic.c | 46 +++++++++++++++++++++++++++++------ 1 file changed, 39 insertions(+), 7 deletions(-) diff --git a/drivers/i2c/busses/i2c-riic.c b/drivers/i2c/busses/i2c-riic.c index 3e8f126cb7f7..9e3595b3623e 100644 --- a/drivers/i2c/busses/i2c-riic.c +++ b/drivers/i2c/busses/i2c-riic.c @@ -670,12 +670,39 @@ static const struct riic_of_data riic_rz_t2h_info = { static int riic_i2c_suspend(struct device *dev) { - struct riic_dev *riic = dev_get_drvdata(dev); - int ret; + /* + * Some I2C devices may need the I2C controller to remain active + * during resume_noirq() or suspend_noirq(). If the controller is + * autosuspended, there is no way to wake it up once runtime PM is + * disabled (in suspend_late()). + * + * During system resume, the I2C controller will be available only + * after runtime PM is re-enabled (in resume_early()). However, this + * may be too late for some devices. + * + * Wake up the controller in the suspend() callback while runtime PM + * is still enabled. The I2C controller will remain available until + * the suspend_noirq() callback (pm_runtime_force_suspend()) is + * called. During resume, the I2C controller can be restored by the + * resume_noirq() callback (pm_runtime_force_resume()). + * + * Finally, the resume() callback re-enables autosuspend, ensuring + * the I2C controller remains available until the system enters + * suspend_noirq() and from resume_noirq(). + */ + return pm_runtime_resume_and_get(dev); +} - ret = pm_runtime_resume_and_get(dev); - if (ret) - return ret; +static int riic_i2c_resume(struct device *dev) +{ + pm_runtime_put_autosuspend(dev); + + return 0; +} + +static int riic_i2c_suspend_noirq(struct device *dev) +{ + struct riic_dev *riic = dev_get_drvdata(dev); i2c_mark_adapter_suspended(&riic->adapter); @@ -683,12 +710,12 @@ static int riic_i2c_suspend(struct device *dev) riic_clear_set_bit(riic, ICCR1_ICE, 0, RIIC_ICCR1); pm_runtime_mark_last_busy(dev); - pm_runtime_put_sync(dev); + pm_runtime_force_suspend(dev); return reset_control_assert(riic->rstc); } -static int riic_i2c_resume(struct device *dev) +static int riic_i2c_resume_noirq(struct device *dev) { struct riic_dev *riic = dev_get_drvdata(dev); int ret; @@ -697,6 +724,10 @@ static int riic_i2c_resume(struct device *dev) if (ret) return ret; + ret = pm_runtime_force_resume(dev); + if (ret) + return ret; + ret = riic_init_hw(riic); if (ret) { /* @@ -714,6 +745,7 @@ static int riic_i2c_resume(struct device *dev) } static const struct dev_pm_ops riic_i2c_pm_ops = { + NOIRQ_SYSTEM_SLEEP_PM_OPS(riic_i2c_suspend_noirq, riic_i2c_resume_noirq) SYSTEM_SLEEP_PM_OPS(riic_i2c_suspend, riic_i2c_resume) }; -- 2.43.0

2 weeks, 3 days

[PATCH v5 0/2] Enable 1GHz OPP am335x-bonegreen-eco

by Kory Maincent (TI.com)

The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used. Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably. Changes in v5: - Add a error message. - Link to v4: https://lore.kernel.org/r/20251112-fix_tps65219-v4-0-696a0f55d5d8@bootlin.c… Changes in v4: - Move the registers unlock in the probe instead of a custom regmap write operation. - Link to v3: https://lore.kernel.org/r/20251112-fix_tps65219-v3-0-e49bab4c01ce@bootlin.c… Changes in v3: - Remove an unused variable - Link to v2: https://lore.kernel.org/r/20251106-fix_tps65219-v2-0-a7d608c4272f@bootlin.c… Changes in v2: - Setup a custom regmap_bus only for the TPS65214 instead of checking the chip_id every time reg_write is called. - Add the am335x-bonegreen-eco devicetree change in the same patch series. Signed-off-by: Kory Maincent (TI.com) <kory.maincent(a)bootlin.com> --- Kory Maincent (TI.com) (2): mfd: tps65219: Implement LOCK register handling for TPS65214 ARM: dts: am335x-bonegreen-eco: Enable 1GHz OPP by increasing vdd_mpu voltage arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts | 2 +- drivers/mfd/tps65219.c | 9 +++++++++ include/linux/mfd/tps65219.h | 2 ++ 3 files changed, 12 insertions(+), 1 deletion(-) --- base-commit: 2bb202416d33347102b12bbd1db4837fb6685617 change-id: 20251106-fix_tps65219-dd62141d22cf Best regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com

2 weeks, 3 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror