From: Sakari Ailus sakari.ailus@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@linux.intel.com Reviewed-by: Laurent Pinchart laurent.pinchart+renesas@ideasonboard.com Reviewed-by: Jonathan Cameron jonathan.cameron@huawei.com Link: https://patch.msgid.link/20251001104320.1272752-3-sakari.ailus@linux.intel.c... Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin sashal@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@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); }
/*