On 11/27/20 9:45 AM, Brian King wrote:
> On 11/25/20 7:48 PM, Tyrel Datwyler wrote:
>> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h
>> index 9d58cfd774d3..8225bdbb127e 100644
>> --- a/drivers/scsi/ibmvscsi/ibmvfc.h
>> +++ b/drivers/scsi/ibmvscsi/ibmvfc.h
>> @@ -41,6 +41,11 @@
>>  #define IBMVFC_DEFAULT_LOG_LEVEL    2
>>  #define IBMVFC_MAX_CDB_LEN          16
>>  #define IBMVFC_CLS3_ERROR           0
>> +#define IBMVFC_MQ                   0
> 
> Given that IBMVFC_MQ is getting set to 0 here, that means mq_enabled is also
> always zero, so am I correct that a lot of this code being added is not
> yet capable of being executed?

Not with out a direct intervention from a hard coding a different value when
building the code. See comment below.

> 
>> +#define IBMVFC_SCSI_CHANNELS                0
> 
> Similar comment here...
> 
>> +#define IBMVFC_SCSI_HW_QUEUES               1
> 
> I don't see any subsequent patches in this series that would ever result
> in nr_hw_queues getting set to anything other than 1. Is that future work
> planned or am I missing something?

Yes, there is still some changes to EH that need to be included before those
values are safe to be set to anything else by the average user.

-Tyrel

> 
>> +#define IBMVFC_MIG_NO_SUB_TO_CRQ    0
>> +#define IBMVFC_MIG_NO_N_TO_M                0
>>  
>>  /*
>>   * Ensure we have resources for ERP and initialization:
>> @@ -826,6 +831,10 @@ struct ibmvfc_host {
>>      int delay_init;
>>      int scan_complete;
>>      int logged_in;
>> +    int mq_enabled;
>> +    int using_channels;
>> +    int do_enquiry;
>> +    int client_scsi_channels;
>>      int aborting_passthru;
>>      int events_to_log;
>>  #define IBMVFC_AE_LINKUP    0x0001
>>
> 
> 

Reply via email to