- Linux-stable-mirror - lists.linaro.org

[PATCH AUTOSEL 6.18-6.17] crypto: ccp - Add support for PCI device 0x115A

by Sasha Levin

From: "Mario Limonciello (AMD)" <superm1(a)kernel.org> [ Upstream commit 9fc6290117259a8dbf8247cb54559df62fd1550f ] PCI device 0x115A is similar to pspv5, except it doesn't have platform access mailbox support. Signed-off-by: Mario Limonciello (AMD) <superm1(a)kernel.org> Acked-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Comprehensive Analysis ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `crypto: ccp - Add support for PCI device 0x115A` **Key Information:** - PCI device 0x115A is a new AMD security processor variant - The commit message states it's "similar to pspv5, except it doesn't have platform access mailbox support" - Signed off by Mario Limonciello (AMD engineer) and Tom Lendacky (AMD) - Merged by Herbert Xu (crypto maintainer) **Tags Present:** - `Signed-off-by`: 3 (proper sign-off chain) - `Acked-by`: Tom Lendacky (driver maintainer acknowledgment) - **NO** `Cc: stable(a)vger.kernel.org` tag - **NO** `Fixes:` tag (this is expected - it's not fixing a bug, it's enabling hardware) ### 2. CODE CHANGE ANALYSIS The commit adds: **A) New `pspv7` structure (~10 lines):** ```c static const struct psp_vdata pspv7 = { .tee = &teev2, .cmdresp_reg = 0x10944, .cmdbuff_addr_lo_reg = 0x10948, .cmdbuff_addr_hi_reg = 0x1094c, .bootloader_info_reg = 0x109ec, .feature_reg = 0x109fc, .inten_reg = 0x10510, .intsts_reg = 0x10514, }; ``` This is **identical to pspv5** except it omits the `.platform_access = &pa_v2` field. This is the explicit difference mentioned in the commit message. **B) New `dev_vdata[9]` entry (~6 lines):** ```c { /* 9 */ .bar = 2, #ifdef CONFIG_CRYPTO_DEV_SP_PSP .psp_vdata = &pspv7, #endif }, ``` **C) New PCI device ID entry (1 line):** ```c { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, ``` ### 3. CLASSIFICATION **This is a NEW DEVICE ID addition** - one of the explicitly allowed exceptions for stable kernel backports. The commit: - Does NOT add new features or APIs - Does NOT change existing behavior - Only enables existing PSP driver functionality on new hardware - Uses established patterns already in the driver ### 4. SCOPE AND RISK ASSESSMENT **Change size:** ~17 lines total - Small, contained data-only change - No logic changes whatsoever - Follows identical patterns used by existing pspv1-pspv6 structures **Risk assessment: VERY LOW** - The driver already handles NULL `platform_access` - verified in `psp- dev.c`: ```c if (psp->vdata->platform_access) { ret = platform_access_dev_init(psp); ... } ``` - Several existing structures (pspv1, pspv4, pspv6) already omit `platform_access` - The `teev2` structure referenced already exists since v6.5 - All register offsets are identical to pspv5 ### 5. USER IMPACT **Who is affected:** - Users with AMD PCI device 0x115A (new AMD security processor variant) - Without this patch, this hardware is completely non-functional **Severity:** HIGH for affected users - enables critical security hardware (TPM-like functionality) ### 6. STABILITY INDICATORS **Positive signals:** - Acked by Tom Lendacky (the original driver author and AMD maintainer) - Follows exact same pattern as 10+ previous device ID additions in this driver - Same author (Mario Limonciello) has successfully added similar devices before (0x17E0, 0x156E, etc.) ### 7. DEPENDENCY CHECK **Required in stable tree:** - `teev2` structure - added in v6.5 (commit 4aa0931be8f0a) - Verified present in v6.6 and later **Recent related commits:** - 52e8ae868a824: "Add missing bootloader info reg for pspv5" (May 2025) - 72942d6538564: "Add missing tee info reg for teev2" (May 2025) The pspv7 structure in this commit already includes the `bootloader_info_reg` correctly, so it was created after these fixes. ### 8. COMPARISON WITH SIMILAR COMMITS This commit follows the exact same pattern as: - `bb4185e595e47`: "Add support for PCI device 0x156E" - Added pspv6 + dev_vdata[8] + PCI ID - `4aa0931be8f0a`: "Add support for PCI device 0x17E0" - Added pspv5/teev2 + dev_vdata[7] + PCI ID - `6cb345939b8cc`: "Add support for PCI device 0x1134" - Added PCI ID only - `63935e2ee1f2a`: "Add support for PCI device 0x17D8" - Added PCI ID only These similar device ID additions are routinely considered for stable trees. --- ## Final Assessment **Should this be backported?** **YES**, for the following reasons: 1. **Falls under the NEW DEVICE ID exception** - explicitly allowed per stable kernel rules for enabling real hardware 2. **Trivial, data-only change** - ~17 lines, no logic changes 3. **Uses existing, proven infrastructure** - teev2 exists, NULL platform_access handling exists 4. **Follows established patterns** - identical to 10+ previous similar commits in this driver 5. **Zero risk of regression** - only affects users with the specific 0x115A device 6. **Enables real hardware** - without this, users with this AMD security processor cannot use it at all 7. **Properly reviewed** - Acked by AMD maintainer, merged by crypto subsystem maintainer **Concerns:** - Requires stable tree to have v6.6+ (for teev2 structure) - May need the bootloader_info_reg fixes backported first for consistency (commits 52e8ae868a824 and 72942d6538564) The change is obviously correct, well-tested (used same patterns as existing code), and enables hardware support that users need. This is exactly the type of device ID addition that stable trees accept. **YES** drivers/crypto/ccp/sp-pci.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c index e7bb803912a6d..8891ceee1d7d0 100644 --- a/drivers/crypto/ccp/sp-pci.c +++ b/drivers/crypto/ccp/sp-pci.c @@ -459,6 +459,17 @@ static const struct psp_vdata pspv6 = { .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ }; +static const struct psp_vdata pspv7 = { + .tee = &teev2, + .cmdresp_reg = 0x10944, /* C2PMSG_17 */ + .cmdbuff_addr_lo_reg = 0x10948, /* C2PMSG_18 */ + .cmdbuff_addr_hi_reg = 0x1094c, /* C2PMSG_19 */ + .bootloader_info_reg = 0x109ec, /* C2PMSG_59 */ + .feature_reg = 0x109fc, /* C2PMSG_63 */ + .inten_reg = 0x10510, /* P2CMSG_INTEN */ + .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ +}; + #endif static const struct sp_dev_vdata dev_vdata[] = { @@ -525,6 +536,13 @@ static const struct sp_dev_vdata dev_vdata[] = { .psp_vdata = &pspv6, #endif }, + { /* 9 */ + .bar = 2, +#ifdef CONFIG_CRYPTO_DEV_SP_PSP + .psp_vdata = &pspv7, +#endif + }, + }; static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x1537), (kernel_ulong_t)&dev_vdata[0] }, @@ -539,6 +557,7 @@ static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x17E0), (kernel_ulong_t)&dev_vdata[7] }, { PCI_VDEVICE(AMD, 0x156E), (kernel_ulong_t)&dev_vdata[8] }, { PCI_VDEVICE(AMD, 0x17D8), (kernel_ulong_t)&dev_vdata[8] }, + { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, /* Last entry must be zero */ { 0, } }; -- 2.51.0

2 weeks, 1 day

1
2
0 0

[PATCH] hwmon: (dell-smm): Fix off-by-one error in dell_smm_is_visible()

by Armin Wolf

The documentation states that on machines supporting only global fan mode control, the pwmX_enable attributes should only be created for the first fan channel (pwm1_enable, aka channel 0). Fix the off-by-one error caused by the fact that fan channels have a zero-based index. Cc: stable(a)vger.kernel.org Fixes: 1c1658058c99 ("hwmon: (dell-smm) Add support for automatic fan mode") Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/hwmon/dell-smm-hwmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c index 683baf361c4c..a34753fc2973 100644 --- a/drivers/hwmon/dell-smm-hwmon.c +++ b/drivers/hwmon/dell-smm-hwmon.c @@ -861,9 +861,9 @@ static umode_t dell_smm_is_visible(const void *drvdata, enum hwmon_sensor_types if (auto_fan) { /* * The setting affects all fans, so only create a - * single attribute. + * single attribute for the first fan channel. */ - if (channel != 1) + if (channel != 0) return 0; /* -- 2.39.5

2 weeks, 1 day

2
1
0 0

[PATCH] hwmon: (w83791d) Convert macros to functions to avoid TOCTOU

by Gui-Dong Han

The macro FAN_FROM_REG evaluates its arguments multiple times. When used in lockless contexts involving shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors. Convert the macro to a static function. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions. Additionally, in store_fan_div, move the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data. Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z… Fixes: 9873964d6eb2 ("[PATCH] HWMON: w83791d: New hardware monitoring driver for the Winbond W83791D") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> --- Based on the discussion in the link, I will submit a series of patches to address TOCTOU issues in the hwmon subsystem by converting macros to functions or adjusting locking where appropriate. --- drivers/hwmon/w83791d.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/hwmon/w83791d.c b/drivers/hwmon/w83791d.c index ace854b370a0..996e36951f9d 100644 --- a/drivers/hwmon/w83791d.c +++ b/drivers/hwmon/w83791d.c @@ -218,9 +218,14 @@ static u8 fan_to_reg(long rpm, int div) return clamp_val((1350000 + rpm * div / 2) / (rpm * div), 1, 254); } -#define FAN_FROM_REG(val, div) ((val) == 0 ? -1 : \ - ((val) == 255 ? 0 : \ - 1350000 / ((val) * (div)))) +static int fan_from_reg(int val, int div) +{ + if (val == 0) + return -1; + if (val == 255) + return 0; + return 1350000 / (val * div); +} /* for temp1 which is 8-bit resolution, LSB = 1 degree Celsius */ #define TEMP1_FROM_REG(val) ((val) * 1000) @@ -521,7 +526,7 @@ static ssize_t show_##reg(struct device *dev, struct device_attribute *attr, \ struct w83791d_data *data = w83791d_update_device(dev); \ int nr = sensor_attr->index; \ return sprintf(buf, "%d\n", \ - FAN_FROM_REG(data->reg[nr], DIV_FROM_REG(data->fan_div[nr]))); \ + fan_from_reg(data->reg[nr], DIV_FROM_REG(data->fan_div[nr]))); \ } show_fan_reg(fan); @@ -585,10 +590,10 @@ static ssize_t store_fan_div(struct device *dev, struct device_attribute *attr, if (err) return err; + mutex_lock(&data->update_lock); /* Save fan_min */ - min = FAN_FROM_REG(data->fan_min[nr], DIV_FROM_REG(data->fan_div[nr])); + min = fan_from_reg(data->fan_min[nr], DIV_FROM_REG(data->fan_div[nr])); - mutex_lock(&data->update_lock); data->fan_div[nr] = div_to_reg(nr, val); switch (nr) { -- 2.43.0

2 weeks, 1 day

2
1
0 0

[PATCH AUTOSEL 6.18-5.10] ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint() only

by Sasha Levin

From: Sakari Ailus <sakari.ailus(a)linux.intel.com> [ Upstream commit 5d010473cdeaabf6a2d3a9e2aed2186c1b73c213 ] Calling fwnode_get_next_child_node() in ACPI implementation of the fwnode property API is somewhat problematic as the latter is used in the impelementation of the former. Instead of using fwnode_get_next_child_node() in acpi_graph_get_next_endpoint(), call acpi_get_next_subnode() directly instead. Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Reviewed-by: Jonathan Cameron <jonathan.cameron(a)huawei.com> Link: https://patch.msgid.link/20251001104320.1272752-3-sakari.ailus@linux.intel.… Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Analysis ### 1. COMMIT MESSAGE ANALYSIS The commit message states: - Problem: `acpi_graph_get_next_endpoint()` calls `fwnode_get_next_child_node()`, which dispatches back to ACPI code, creating unnecessary indirection. - Solution: Call `acpi_get_next_subnode()` directly instead. No "Cc: stable(a)vger.kernel.org" tag, no "Fixes:" tag, no explicit bug report link. The message says "somewhat problematic," indicating an architectural issue rather than a critical bug. ### 2. CODE CHANGE ANALYSIS The diff shows 4 replacements in `acpi_graph_get_next_endpoint()`: - Line 1475: `fwnode_get_next_child_node(fwnode, port)` → `acpi_get_next_subnode(fwnode, port)` - Line 1493: `fwnode_get_next_child_node(port, prev)` → `acpi_get_next_subnode(port, prev)` - Line 1495: `fwnode_get_next_child_node(fwnode, port)` → `acpi_get_next_subnode(fwnode, port)` - Line 1499: `fwnode_get_next_child_node(port, NULL)` → `acpi_get_next_subnode(port, NULL)` Call chain: 1. `fwnode_get_next_child_node()` dispatches via `fwnode_call_ptr_op()` to the fwnode-specific implementation. 2. For ACPI fwnodes, it calls `acpi_get_next_present_subnode()` (registered at line 1747). 3. `acpi_get_next_present_subnode()` filters non-present device nodes and calls `acpi_get_next_subnode()`. Why the change is safe: - Graph endpoints are ACPI data nodes (checked by `is_acpi_graph_node()` at line 1448: `is_acpi_data_node(fwnode)`). - `acpi_get_next_present_subnode()` only filters non-present device nodes (lines 1407-1408), not data nodes. - Therefore, for graph endpoints, `acpi_get_next_subnode()` and `fwnode_get_next_child_node()` behave the same. ### 3. CLASSIFICATION This is a bug fix addressing an architectural issue: - Removes unnecessary indirection in ACPI-specific code. - Avoids a circular dependency pattern (ACPI → generic → ACPI). - Functionally equivalent for graph endpoints. Not a feature addition, not a new API, not a refactor. ### 4. SCOPE AND RISK ASSESSMENT - Scope: 4 lines changed in one function in one file. - Risk: Very low — same behavior for graph endpoints, cleaner architecture. - Complexity: Low — direct function call replacement. ### 5. USER IMPACT - Who is affected: Users of ACPI graph endpoints (e.g., camera/media drivers, device tree-like ACPI usage). - Severity: Low — architectural improvement, not a visible bug fix. - Likelihood: The "somewhat problematic" wording suggests no immediate user-visible issue. ### 6. STABILITY INDICATORS - Reviewed-by: Laurent Pinchart, Jonathan Cameron - Signed-off-by: Rafael J. Wysocki (ACPI maintainer) - No "Tested-by:" tags - Commit date: October 1, 2025 (recent) ### 7. DEPENDENCY CHECK - `acpi_get_next_subnode()` exists in the same file and has been present for years. - No external dependencies introduced. - Should apply cleanly to stable trees that have this code. ### 8. HISTORICAL CONTEXT Related commits: - `79389a83bc388`: Introduced `acpi_graph_get_next_endpoint()` with `fwnode_get_next_child_node()` calls. - `48698e6cf44c3`: Introduced `acpi_get_next_present_subnode()` to filter non-present devices. - `5d010473cdeaa` (this commit): Removes the indirection. The pattern existed since the function was introduced; this commit cleans it up. ### 9. STABLE KERNEL CRITERIA EVALUATION - Obviously correct: Yes — direct call instead of indirection. - Fixes a real bug: Yes — architectural issue that could cause problems. - Important issue: Moderate — architectural improvement, not a critical bug. - Small and contained: Yes — 4 lines, single function. - No new features: Yes — same behavior, cleaner code. - Applies cleanly: Yes — should apply without conflicts. ### 10. RISK VS BENEFIT Benefits: - Removes unnecessary indirection. - Avoids circular dependency pattern. - Improves code clarity. - No functional change for graph endpoints. Risks: - Very low — functionally equivalent change. - No new code paths or logic changes. ### 11. CONCERNS AND CONSIDERATIONS - No "Cc: stable" tag, but that alone doesn't disqualify. - Recent commit (Oct 2025) — hasn't been in mainline long. - No explicit bug report or user complaint mentioned. - Architectural improvement rather than a critical fix. ### CONCLUSION This is a small, correct fix that removes unnecessary indirection in ACPI code. It fixes an architectural issue and is functionally equivalent for graph endpoints. It meets stable kernel criteria: correct, fixes a real issue, small scope, no new features, and should apply cleanly. However, it's an architectural improvement rather than a critical bug fix, and there's no explicit stable tag or user-visible bug report. The "somewhat problematic" wording suggests it may not cause immediate visible problems. Given the conservative nature of stable trees and the lack of evidence of user-visible impact, this is borderline but leans toward acceptable for stable backporting due to its correctness, small scope, and architectural benefit. **YES** drivers/acpi/property.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c index 43d5e457814e1..76158b1399029 100644 --- a/drivers/acpi/property.c +++ b/drivers/acpi/property.c @@ -1472,7 +1472,7 @@ static struct fwnode_handle *acpi_graph_get_next_endpoint( if (!prev) { do { - port = fwnode_get_next_child_node(fwnode, port); + port = acpi_get_next_subnode(fwnode, port); /* * The names of the port nodes begin with "port@" * followed by the number of the port node and they also @@ -1490,13 +1490,13 @@ static struct fwnode_handle *acpi_graph_get_next_endpoint( if (!port) return NULL; - endpoint = fwnode_get_next_child_node(port, prev); + endpoint = acpi_get_next_subnode(port, prev); while (!endpoint) { - port = fwnode_get_next_child_node(fwnode, port); + port = acpi_get_next_subnode(fwnode, port); if (!port) break; if (is_acpi_graph_node(port, "port")) - endpoint = fwnode_get_next_child_node(port, NULL); + endpoint = acpi_get_next_subnode(port, NULL); } /* -- 2.51.0

2 weeks, 1 day

1
6
0 0

[PATCH net] net: phy: marvell-88q2xxx: Fix clamped value in mv88q2xxx_hwmon_write

by Thorsten Blum

The local variable 'val' was never clamped to -75000 or 180000 because the return value of clamp_val() was not used. Fix this by assigning the clamped value back to 'val', and use clamp() instead of clamp_val(). Cc: stable(a)vger.kernel.org Fixes: a557a92e6881 ("net: phy: marvell-88q2xxx: add support for temperature sensor") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/net/phy/marvell-88q2xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/marvell-88q2xxx.c b/drivers/net/phy/marvell-88q2xxx.c index f3d83b04c953..201dee1a1698 100644 --- a/drivers/net/phy/marvell-88q2xxx.c +++ b/drivers/net/phy/marvell-88q2xxx.c @@ -698,7 +698,7 @@ static int mv88q2xxx_hwmon_write(struct device *dev, switch (attr) { case hwmon_temp_max: - clamp_val(val, -75000, 180000); + val = clamp(val, -75000, 180000); val = (val / 1000) + 75; val = FIELD_PREP(MDIO_MMD_PCS_MV_TEMP_SENSOR3_INT_THRESH_MASK, val); -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

2 weeks, 1 day

4
3
0 0

[PATCH 1/1] phy: tegra: xusb: Fix UTMI AO sleepwalk trigger programming sequence

by Wayne Chang

From: Haotien Hsu <haotienh(a)nvidia.com> The UTMIP sleepwalk programming sequence requires asserting both LINEVAL_WALK_EN and WAKE_WALK_EN when enabling the sleepwalk logic. However, the current code mistakenly cleared WAKE_WALK_EN, which prevents the sleepwalk trigger from operating correctly. Fix this by asserting WAKE_WALK_EN together with LINEVAL_WALK_EN. Fixes: 1f9cab6cc20c ("phy: tegra: xusb: Add wake/sleepwalk for Tegra186") Cc: stable(a)vger.kernel.org Signed-off-by: Haotien Hsu <haotienh(a)nvidia.com> Signed-off-by: Wayne Chang <waynec(a)nvidia.com> --- drivers/phy/tegra/xusb-tegra186.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c index e818f6c3980e..b2a76710c0c4 100644 --- a/drivers/phy/tegra/xusb-tegra186.c +++ b/drivers/phy/tegra/xusb-tegra186.c @@ -401,8 +401,7 @@ static int tegra186_utmi_enable_phy_sleepwalk(struct tegra_xusb_lane *lane, /* enable the trigger of the sleepwalk logic */ value = ao_readl(priv, XUSB_AO_UTMIP_SLEEPWALK_CFG(index)); - value |= LINEVAL_WALK_EN; - value &= ~WAKE_WALK_EN; + value |= LINEVAL_WALK_EN | WAKE_WALK_EN; ao_writel(priv, value, XUSB_AO_UTMIP_SLEEPWALK_CFG(index)); /* reset the walk pointer and clear the alarm of the sleepwalk logic, -- 2.25.1

2 weeks, 1 day

2
2
0 0

[PATCH RESEND] drm: mipi-dsi: Fix an API misuse in mipi_dsi_device_register_full()

by Haoxiang Li

mipi_dsi_device_alloc() calls device_initialize() to initialize value "&dsi->dev". Thus "dsi" should be freed using put_device() in error handling path. Fixes: 068a00233969 ("drm: Add MIPI DSI bus support") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> --- drivers/gpu/drm/drm_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index a712e177b350..e47950009126 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -233,7 +233,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host, ret = mipi_dsi_device_add(dsi); if (ret) { dev_err(host->dev, "failed to add DSI device %d\n", ret); - kfree(dsi); + put_device(&dsi->dev); return ERR_PTR(ret); } -- 2.25.1

2 weeks, 1 day

1
0
0 0

[PATCH 6.6] net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()

by Chen Yu

From: Vladimir Oltean <vladimir.oltean(a)nxp.com> [ Upstream commit 5f2b28b79d2d1946ee36ad8b3dc0066f73c90481 ] There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page. Fixes: 6666cebc5e30 ("net: dsa: sja1105: Add support for VLAN operations") Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250318115716.2124395-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Chen Yu <xnguchen(a)sina.cn> --- drivers/net/dsa/sja1105/sja1105_static_config.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c index baba204ad62f..2ac91fe2a79b 100644 --- a/drivers/net/dsa/sja1105/sja1105_static_config.c +++ b/drivers/net/dsa/sja1105/sja1105_static_config.c @@ -1921,8 +1921,10 @@ int sja1105_table_delete_entry(struct sja1105_table *table, int i) if (i > table->entry_count) return -ERANGE; - memmove(entries + i * entry_size, entries + (i + 1) * entry_size, - (table->entry_count - i) * entry_size); + if (i + 1 < table->entry_count) { + memmove(entries + i * entry_size, entries + (i + 1) * entry_size, + (table->entry_count - i - 1) * entry_size); + } table->entry_count--; -- 2.17.1

2 weeks, 1 day

1
0
0 0

[GIT PULL] virtio,vhost: fixes, cleanups

by Michael S. Tsirkin

get_user/put_user change didn't spend time in next and seems a bit too risky to rush. I'm keeping it in my tree and we'll get it in the next cycle. The following changes since commit ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d: Linux 6.18-rc7 (2025-11-23 14:53:16 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to 205dd7a5d6ad6f4c8e8fcd3c3b95a7c0e7067fee: virtio_pci: drop kernel.h (2025-11-30 18:02:43 -0500) ---------------------------------------------------------------- virtio,vhost: fixes, cleanups Just a bunch of fixes and cleanups, mostly very simple. Several features are merged through net-next this time around. Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> ---------------------------------------------------------------- Alok Tiwari (3): virtio_vdpa: fix misleading return in void function vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues vdpa/pds: use %pe for ERR_PTR() in event handler registration Kriish Sharma (1): virtio: fix kernel-doc for mapping/free_coherent functions Marco Crivellari (2): virtio_balloon: add WQ_PERCPU to alloc_workqueue users vduse: add WQ_PERCPU to alloc_workqueue users Miaoqian Lin (1): virtio: vdpa: Fix reference count leak in octep_sriov_enable() Michael S. Tsirkin (11): virtio: fix typo in virtio_device_ready() comment virtio: fix whitespace in virtio_config_ops virtio: fix grammar in virtio_queue_info docs virtio: fix grammar in virtio_map_ops docs virtio: standardize Returns documentation style virtio: fix virtqueue_set_affinity() docs virtio: fix map ops comment virtio: clean up features qword/dword terms vhost/test: add test specific macro for features vhost: switch to arrays of feature bits virtio_pci: drop kernel.h Mike Christie (1): vhost: Fix kthread worker cgroup failure handling drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +- drivers/vdpa/octeon_ep/octep_vdpa_main.c | 1 + drivers/vdpa/pds/vdpa_dev.c | 2 +- drivers/vdpa/vdpa_user/vduse_dev.c | 3 ++- drivers/vhost/net.c | 29 +++++++++++----------- drivers/vhost/scsi.c | 9 ++++--- drivers/vhost/test.c | 10 ++++++-- drivers/vhost/vhost.c | 4 ++- drivers/vhost/vhost.h | 42 ++++++++++++++++++++++++++------ drivers/vhost/vsock.c | 10 +++++--- drivers/virtio/virtio.c | 12 ++++----- drivers/virtio/virtio_balloon.c | 3 ++- drivers/virtio/virtio_debug.c | 10 ++++---- drivers/virtio/virtio_pci_modern_dev.c | 6 ++--- drivers/virtio/virtio_ring.c | 7 +++--- drivers/virtio/virtio_vdpa.c | 2 +- include/linux/virtio.h | 2 +- include/linux/virtio_config.h | 24 +++++++++--------- include/linux/virtio_features.h | 29 +++++++++++----------- include/linux/virtio_pci_modern.h | 8 +++--- include/uapi/linux/virtio_pci.h | 2 +- 21 files changed, 131 insertions(+), 86 deletions(-)

2 weeks, 1 day

2
1
0 0

[PATCH v2 1/9] crypto: virtio: Add spinlock protection with virtqueue notification

by Bibo Mao

When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well. Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Cc: stable(a)vger.kernel.org Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- drivers/crypto/virtio/virtio_crypto_core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/virtio/virtio_crypto_core.c b/drivers/crypto/virtio/virtio_crypto_core.c index 3d241446099c..ccc6b5c1b24b 100644 --- a/drivers/crypto/virtio/virtio_crypto_core.c +++ b/drivers/crypto/virtio/virtio_crypto_core.c @@ -75,15 +75,20 @@ static void virtcrypto_done_task(unsigned long data) struct data_queue *data_vq = (struct data_queue *)data; struct virtqueue *vq = data_vq->vq; struct virtio_crypto_request *vc_req; + unsigned long flags; unsigned int len; + spin_lock_irqsave(&data_vq->lock, flags); do { virtqueue_disable_cb(vq); while ((vc_req = virtqueue_get_buf(vq, &len)) != NULL) { + spin_unlock_irqrestore(&data_vq->lock, flags); if (vc_req->alg_cb) vc_req->alg_cb(vc_req, len); + spin_lock_irqsave(&data_vq->lock, flags); } } while (!virtqueue_enable_cb(vq)); + spin_unlock_irqrestore(&data_vq->lock, flags); } static void virtcrypto_dataq_callback(struct virtqueue *vq) -- 2.39.3

2 weeks, 1 day

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror