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)