On 5/7/26 3:40 PM, Dave Marquardt wrote:
> Tyrel Datwyler <[email protected]> writes:
>
>> On 4/8/26 10:07 AM, Dave Marquardt via B4 Relay wrote:
>>> From: Dave Marquardt <[email protected]>
>>>
<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
