[PATCH AUTOSEL 6.18-6.6] spi: hisi-kunpeng: Fixed the wrong debugfs node name in hisi_spi debugfs initialization

[PATCH AUTOSEL 6.18-6.6] spi: hisi-kunpeng: Fixed the wrong debugfs node name in hisi_spi debugfs initialization

[Sasha Levin]

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

[PATCH AUTOSEL 6.18-6.6] spi: hisi-kunpeng: Fixed the wrong debugfs node name in hisi_spi debugfs initialization

[Sasha Levin]

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

[PATCH AUTOSEL 6.18] spi: intel-pci: Add support for Nova Lake SPI serial flash

[Sasha Levin]

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