* [PATCH AUTOSEL 6.18-6.6] spi: hisi-kunpeng: Fixed the wrong debugfs node name in hisi_spi debugfs initialization
[not found] <20260202214643.212290-1-sashal@kernel.org>
@ 2026-02-02 21:46 ` Sasha Levin
2026-02-02 21:46 ` [PATCH AUTOSEL 6.18] spi: intel-pci: Add support for Nova Lake SPI serial flash Sasha Levin
1 sibling, 0 replies; 3+ messages in thread
From: Sasha Levin @ 2026-02-02 21:46 UTC (permalink / raw)
To: patches, stable; +Cc: Devyn Liu, Yang Shen, Mark Brown, Sasha Levin, linux-spi
From: Devyn Liu <liudingyuan@h-partners.com>
[ Upstream commit b062a899c997df7b9ce29c62164888baa7a85833 ]
In hisi_spi_debugfs_init, spi controller pointer is calculated
by container_of macro, and the member is hs->dev. But the host
cannot be calculated offset directly by this. (hs->dev) points
to (pdev->dev), and it is the (host->dev.parent) rather than
(host->dev) points to the (pdev->dev), which is set in
__spi_alloc_controller.
In this patch, this issues is fixed by getting the spi_controller
data from pdev->dev by dev_get_drvdata() directly. (dev->driver_data)
points to the spi controller data in the probe stage.
Signed-off-by: Devyn Liu <liudingyuan@h-partners.com>
Reviewed-by: Yang Shen <shenyang39@huawei.com>
Link: https://patch.msgid.link/20260108075323.3831574-1-liudingyuan@h-partners.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
In `struct spi_controller`, `dev` is at offset 0. So when `container_of`
is used with an incorrect pointer, it will calculate the "base" of the
spi_controller by subtracting 0 from the address - meaning it will use
`hs->dev` (pdev->dev) directly as if it were an spi_controller!
This would cause the access to `host->bus_num` (used in the snprintf for
creating debugfs directory name) to read from the wrong memory location.
Looking at struct spi_controller, `bus_num` is at around offset 72-80
bytes (after `dev` and `list`), so it would be reading random data from
the platform_device structure.
Let me analyze the severity:
1. **Best case**: Random garbage `bus_num` value → debugfs directory
created with garbage name like "hisi_spi-1234567" or some nonsense
2. **Worst case**: Could potentially read out of bounds if pdev->dev is
at the end of an allocation
The fix is simple, correct, and uses the proper method to retrieve the
spi_controller pointer.
## Summary Analysis
### 1. COMMIT MESSAGE ANALYSIS
The commit message clearly explains:
- The bug: `container_of` is incorrectly used - `hs->dev` points to
`pdev->dev`, not `host->dev`
- The fix: Use `dev_get_drvdata()` to correctly get the spi_controller
pointer
### 2. CODE CHANGE ANALYSIS
**The Bug:**
- `hs->dev = dev` where `dev = &pdev->dev` (platform device's device)
- `host = container_of(hs->dev, struct spi_controller, dev)` computes
wrong offset
- Since `dev` is at offset 0 in spi_controller, this treats `pdev->dev`
as if it were the spi_controller
- Accessing `host->bus_num` reads garbage from wrong memory location
**The Fix:**
- Uses `dev_get_drvdata(hs->dev)` to correctly retrieve the
spi_controller pointer
- This works because `platform_set_drvdata(pdev, host)` was called in
probe
**The fix is obviously correct:** It mirrors how other parts of the
driver (e.g., interrupt handler) retrieve the spi_controller.
### 3. CLASSIFICATION
- **Bug fix**: Yes, this fixes a real bug where incorrect memory is
accessed
- **Category**: Bug fix for incorrect pointer calculation
### 4. SCOPE AND RISK ASSESSMENT
- **Lines changed**: Net -4 lines, very small change
- **Files touched**: 1 driver file
- **Risk**: Very low - changes a local variable initialization in a
debugfs init function
- **Could break something else?**: No, this is a purely local fix
### 5. USER IMPACT
- **Who is affected**: Users of HiSilicon Kunpeng SoC SPI controllers
with debugfs enabled
- **Severity**: The bug causes incorrect debugfs directory naming and
potentially reads garbage memory
- **Hardware support**: This driver is for specific Kunpeng server SoCs
### 6. STABILITY INDICATORS
- Has "Reviewed-by:" tag from another Huawei engineer
- The fix is straightforward and mirrors existing patterns in the driver
### 7. DEPENDENCY CHECK
- The driver exists since v5.13, so this is relevant for 5.15.y, 6.1.y,
6.6.y, etc.
- No dependencies on other commits - standalone fix
## Conclusion
This commit fixes a real bug in pointer calculation that causes
incorrect memory access. The fix is:
- Small and surgical (changes one variable initialization)
- Obviously correct (uses the same pattern as other code in the driver)
- Fixes a real bug (incorrect container_of usage)
- Low risk (only affects debugfs, but still fixes incorrect memory
access)
The bug could cause reading garbage values or potentially undefined
behavior. While debugfs is primarily a debugging interface, the
incorrect memory access is still a real bug that should be fixed in
stable trees.
**YES**
drivers/spi/spi-hisi-kunpeng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/spi/spi-hisi-kunpeng.c b/drivers/spi/spi-hisi-kunpeng.c
index dadf558dd9c0c..80a1a15de0bc3 100644
--- a/drivers/spi/spi-hisi-kunpeng.c
+++ b/drivers/spi/spi-hisi-kunpeng.c
@@ -161,10 +161,8 @@ static const struct debugfs_reg32 hisi_spi_regs[] = {
static int hisi_spi_debugfs_init(struct hisi_spi *hs)
{
char name[32];
+ struct spi_controller *host = dev_get_drvdata(hs->dev);
- struct spi_controller *host;
-
- host = container_of(hs->dev, struct spi_controller, dev);
snprintf(name, 32, "hisi_spi%d", host->bus_num);
hs->debugfs = debugfs_create_dir(name, NULL);
if (IS_ERR(hs->debugfs))
--
2.51.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* [PATCH AUTOSEL 6.18] spi: intel-pci: Add support for Nova Lake SPI serial flash
[not found] <20260202214643.212290-1-sashal@kernel.org>
2026-02-02 21:46 ` [PATCH AUTOSEL 6.18-6.6] spi: hisi-kunpeng: Fixed the wrong debugfs node name in hisi_spi debugfs initialization Sasha Levin
@ 2026-02-02 21:46 ` Sasha Levin
1 sibling, 0 replies; 3+ messages in thread
From: Sasha Levin @ 2026-02-02 21:46 UTC (permalink / raw)
To: patches, stable
Cc: Alan Borzeszkowski, Mika Westerberg, Mark Brown, Sasha Levin,
linux-spi
From: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
[ Upstream commit caa329649259d0f90c0056c9860ca659d4ba3211 ]
Add Intel Nova Lake PCH-S SPI serial flash PCI ID to the list of
supported devices. This is the same controller found in previous
generations.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260115120305.10080-1-alan.borzeszkowski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Comprehensive Backport Analysis
### 1. COMMIT MESSAGE ANALYSIS
**Subject:** "spi: intel-pci: Add support for Nova Lake SPI serial
flash"
**Key information from message:**
- Adds a new PCI ID for Intel Nova Lake PCH-S SPI serial flash
controller
- Explicitly states: "This is the same controller found in previous
generations"
- Has proper sign-offs from Intel developer and maintainer
acknowledgment
- Link to patch message provided for traceability
**Notable:** No Fixes: tag or Cc: stable tag, but as noted in the
analysis guidelines, this is expected for commits requiring manual
review.
### 2. CODE CHANGE ANALYSIS
The diff shows a **single-line addition**:
```c
{ PCI_VDEVICE(INTEL, 0x6e24), (unsigned long)&cnl_info },
```
This adds PCI device ID `0x6e24` to the `intel_spi_pci_ids[]` table,
using the existing `cnl_info` configuration structure (Cannon Lake
info).
**Technical details:**
- The change adds one entry to the PCI device ID table
- Uses the well-established `PCI_VDEVICE()` macro
- References `cnl_info`, which already exists and is used by many other
device IDs in this driver
- The insertion is alphabetically ordered (0x6e24 is placed between
0x5825 and 0x7723)
- No new code paths, functions, or logic introduced
### 3. CLASSIFICATION
**This is a NEW DEVICE ID addition** - one of the explicitly listed
exceptions in the stable kernel rules.
From the guidelines:
> **NEW DEVICE IDs (Very Common):**
> - Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers
> - These are trivial one-line additions that enable hardware support
> - Rule: The driver must already exist in stable; only the ID is new
This commit fits this exception perfectly:
- The `spi-intel-pci` driver already exists in stable kernels
- Only the PCI ID is being added
- Uses existing configuration (`cnl_info`)
### 4. SCOPE AND RISK ASSESSMENT
**Scope:**
- **Lines changed:** 1 line added
- **Files touched:** 1 file (`drivers/spi/spi-intel-pci.c`)
- **Complexity:** Minimal - just a table entry
**Risk assessment:**
- **Extremely LOW risk** - This is one of the safest possible changes
- The new ID only matches Nova Lake hardware
- Existing hardware continues to work exactly as before
- If the ID is somehow wrong, only Nova Lake devices would be affected
- The `cnl_info` structure is already well-tested with many other Intel
platforms
### 5. USER IMPACT
**Who benefits:**
- Users with Intel Nova Lake PCH-S systems
- Enterprise customers deploying on newer Intel hardware
- Without this patch, SPI flash on Nova Lake systems won't be recognized
**Impact assessment:**
- **Positive impact:** Enables SPI flash access on new hardware
- **Negative impact potential:** None for existing users
- **Hardware scope:** This is a platform-level chipset, so all Nova Lake
systems are affected
### 6. STABILITY INDICATORS
- **Acked-by:** Mika Westerberg (Intel kernel maintainer) - positive
signal
- **Signed-off-by:** Mark Brown (SPI subsystem maintainer) - indicates
proper review
- The commit message explicitly states this uses the "same controller
found in previous generations" - this suggests the hardware is
compatible and doesn't need new code
### 7. DEPENDENCY CHECK
**Dependencies:** None
- This commit is completely self-contained
- It only adds an entry to an existing table
- No prerequisites needed - the driver infrastructure is already in
place
**Stable tree compatibility:**
- The `spi-intel-pci.c` driver has been in the kernel for years
- The `cnl_info` structure exists in all relevant stable trees
- This patch will apply cleanly to any stable kernel that has this
driver
### 8. VERDICT REASONING
**Why this SHOULD be backported:**
1. **Explicitly allowed by stable rules:** New device IDs are a
documented exception that IS appropriate for stable trees
2. **Zero regression risk:** Adding a new PCI ID to a table cannot
possibly break existing functionality
3. **Minimal change:** Single line addition is as small and contained as
possible
4. **Real user benefit:** Users with Nova Lake hardware need this to
have functional SPI flash support
5. **Mature driver:** The intel-spi-pci driver is well-established and
the cnl_info configuration is used by many other platforms
6. **Proper review:** Has maintainer acks from both Intel and SPI
subsystem maintainers
**No concerns:**
- No dependencies
- No backport adjustments needed
- Will apply cleanly
- No new code paths or features
This is a textbook example of a commit that should be backported to
stable - it's a trivial device ID addition that enables hardware support
using existing, well-tested driver code.
**YES**
drivers/spi/spi-intel-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-intel-pci.c b/drivers/spi/spi-intel-pci.c
index b8c572394aac2..bce3d149bea18 100644
--- a/drivers/spi/spi-intel-pci.c
+++ b/drivers/spi/spi-intel-pci.c
@@ -81,6 +81,7 @@ static const struct pci_device_id intel_spi_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x54a4), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x5794), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x5825), (unsigned long)&cnl_info },
+ { PCI_VDEVICE(INTEL, 0x6e24), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x7723), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x7a24), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x7aa4), (unsigned long)&cnl_info },
--
2.51.0
^ permalink raw reply related [flat|nested] 3+ messages in thread