As found in the PR, submitted by Prasad B M <email@example.com>.
The code seems fine, other than the weird msi_tupelo which randomly seems to be the same as msi_enabled, but only some of the time. A comment is needed to explain why the oddity.
This needs a comment. It kinda sorta seems like it duplicates msi_enabled, but it kinda doesn't in all cases. It's weird and after studying the code for a bit, I'm still at a loss to understand why it's needed (apart from "to work" which is unsatisfying an answer). msi_enabled appears to be overloaded for a few other things, but it's unclear why from reading the code w/o firmware interface docs.
According to Prasad:
"msi_tupelo" is used for ARC series 6 controller which initially did not support MSI interrupt, later support was added with only one MSI interrupt. Basically it means it supports only MSI interrupt.
where as "msi_enabled" indicates that it supports both MSI and MSI-X interrupt based on the System Config. this is usually used for Series 7 & 8 ARC controller.
I'm marking this as accepted despite my individual comments.
This ultimately gets passed to cam_path_inquiry->initiator_id which is an unsigned int. It's an almost irrelevant semantic difference in this case but could cause a compiler warning in the future. It's a bug in CAM that there isn't a suitable constant available to express this correctly. For now I'd just set it to businfo.TargetsPerBus+1, unless that evaluates into an overflow.
Would it make better sense to always treat MSI as having a single vector, rename msi_enabled as msix_enabled, and rename msi_tupelo to msi_enabled? You could then flag the Gen6 behavior as a quirk in the device table in aacraid_pci.c .