[PATCH AUTOSEL 6.18-6.12] scsi: smartpqi: Add support for Hurray Data new controller PCI device

[Sasha Levin <sashal@kernel.org>]

From: David Strahan <David.Strahan@microchip.com>

[ Upstream commit 48e6b7e708029cea451e53a8c16fc8c16039ecdc ]

Add support for new Hurray Data controller.

All entries are in HEX.

Add PCI IDs for Hurray Data controllers:
                                         VID  / DID  / SVID / SDID
                                         ----   ----   ----   ----
                                         9005   028f   207d   4840

Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Signed-off-by: David Strahan <David.Strahan@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Link: https://patch.msgid.link/20251106163823.786828-4-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: smartpqi: Add support for Hurray Data new
controller PCI device

### 1. COMMIT MESSAGE ANALYSIS

**Subject/Body:** The commit adds support for a new Hurray Data storage
controller by adding its PCI device ID to the smartpqi driver's device
table.

**Tags present:**
- Multiple `Reviewed-by:` tags from Microchip engineers
- `Signed-off-by:` from driver maintainers
- **No `Fixes:` tag** - not fixing a bug
- **No `Cc: stable@vger.kernel.org`** - maintainer didn't explicitly
  request backport

### 2. CODE CHANGE ANALYSIS

The diff shows an extremely minimal change:
- **File modified:** `drivers/scsi/smartpqi/smartpqi_init.c`
- **Lines added:** 4 lines (one PCI device ID entry)
- **Change type:** Static array addition to `pqi_pci_id_table[]`

```c
{
    PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
                   0x207d, 0x4840)
},
```

The new entry uses the same vendor ID (0x207d - Hurray Data) already
present in the table with different subsystem device IDs (0x4054,
0x4084, 0x4094, 0x4140, 0x4240). This is simply adding another variant.

### 3. CLASSIFICATION

This falls under the **NEW DEVICE IDs exception** - one of the
explicitly allowed categories for stable trees:
- Adding a PCI subsystem ID to an existing, mature driver
- The smartpqi driver already supports Hurray Data controllers
- Only the specific hardware variant (SDID 0x4840) is new
- No new driver code, no feature additions - purely declarative data

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment |
|--------|------------|
| Lines changed | +4 (trivial) |
| Files touched | 1 file |
| Complexity | None - static data only |
| Subsystem maturity | High - smartpqi is a well-tested SCSI driver |
| Risk of regression | **Essentially zero** |

This is purely declarative - adding an entry to a static array. It
cannot introduce logic bugs, race conditions, or regressions. If the
hardware doesn't exist on a system, the entry has no effect whatsoever.

### 5. USER IMPACT

- **Affected users:** Anyone with a Hurray Data controller using
  subsystem device ID 0x4840
- **Without patch:** Storage controller won't be recognized; system
  likely unusable
- **With patch:** Hardware works normally
- **Impact severity:** Critical for affected users (storage controller =
  essential hardware)

### 6. STABILITY INDICATORS

- **Multiple reviews** from driver maintainers (Scott Benesh, Scott
  Teel, Mike McGowen)
- **Established pattern** - follows exactly the same format as dozens of
  other entries
- **Mature driver** - smartpqi has been stable for years

### 7. DEPENDENCY CHECK

- **No dependencies** - completely standalone change
- **Code exists in stable trees** - smartpqi driver and its PCI ID table
  are present in all active stable branches

### DECISION ANALYSIS

**For backporting:**
1. ✅ Falls squarely into the "device ID" exception category
2. ✅ Zero risk of regression - purely data addition
3. ✅ Enables critical hardware (storage controller) for affected users
4. ✅ Trivial, well-reviewed change
5. ✅ Pattern already established with many similar entries
6. ✅ Self-contained with no dependencies

**Against backporting:**
1. ⚠️ No explicit `Cc: stable` tag
2. ⚠️ Technically "new hardware support" not a bug fix

### CONCLUSION

This is a textbook example of a device ID addition suitable for stable
backporting. The stable kernel rules explicitly allow new PCI/USB device
IDs because:
- They are trivially small and well-understood
- They have near-zero risk of regression
- They enable real hardware that users have purchased

The lack of an explicit stable tag is not disqualifying for device ID
additions - these are routinely accepted into stable trees. For a
storage controller, this is particularly important as users with this
hardware variant would have non-functional systems without the ID being
recognized.

The change is obviously correct, has been reviewed by multiple
maintainers, follows an established pattern, and provides clear value to
affected users with no risk to anyone else.

**YES**

 drivers/scsi/smartpqi/smartpqi_init.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
index 03c97e60d36f6..91b01e2e01f01 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -10108,6 +10108,10 @@ static const struct pci_device_id pqi_pci_id_table[] = {
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       0x207d, 0x4240)
 	},
+	{
+		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
+			       0x207d, 0x4840)
+	},
 	{
 		PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x028f,
 			       PCI_VENDOR_ID_ADVANTECH, 0x8312)
-- 
2.51.0