Re: [PATCH 4/5] ibmvfc: use async sub-queue for FPIN messages

[Tyrel Datwyler <tyreld@linux.ibm.com>]

On 5/7/26 3:40 PM, Dave Marquardt wrote:
> Tyrel Datwyler <tyreld@linux.ibm.com> writes:
> 
>> On 4/8/26 10:07 AM, Dave Marquardt via B4 Relay wrote:
>>> From: Dave Marquardt <davemarq@linux.ibm.com>
>>>

<snip>

>>> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
>>> index 803fc3caa14d..26e39b367022 100644
>>> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
>>> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
>>> @@ -1471,6 +1471,13 @@ static void ibmvfc_gather_partition_info(struct ibmvfc_host *vhost)
>>>  	of_node_put(rootdn);
>>>  }.
>>>  
>>> +static __be64 ibmvfc_npiv_chan_caps[] = {
>>> +	cpu_to_be64(IBMVFC_CAN_USE_CHANNELS | IBMVFC_USE_ASYNC_SUBQ |
>>> +		    IBMVFC_YES_SCSI | IBMVFC_CAN_HANDLE_FPIN),
>>> +	cpu_to_be64(IBMVFC_CAN_USE_CHANNELS),
>>> +};
>>> +#define IBMVFC_NPIV_CHAN_CAPS_SIZE (sizeof(ibmvfc_npiv_chan_caps)/sizeof(__be64))
>>> +
>>
>> I really don't understand what you are doing here? You seem to be definig
>> various sets of capabilities, but how does the driver decide which set to use?
>> As far as I can tell the index is increased and the capabilities decrease each
>> time a transport event is received. This looks like maybe its just a testing hack.
> 
> My thought was to deal with an older VIOS that doesn't support the async
> sub-queue and full FPIN. But I suppose the response should just not set the
> appropriate bits. I'll go re-read the NPIV spec and figure out if this
> is actually needed.
> 

Exactly, we should blanket set everything we support, and then rely on what the
VIOS advertises as support to then setup the proper facilities on our end.

-Tyrel