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
>>
>
>
