On 04/10/2018 04:11 AM, Xiubo Li wrote:
> 
> On 2018/4/9 19:44, Prasanna Kumar Kalever wrote:
>> Problem:
>> -------
>> $ cat /sys/kernel/config/target/core/user_0/block/attrib/qfull_time_out
>> -1
>>
>> $ echo "-1" >
>> /sys/kernel/config/target/core/user_0/block/attrib/qfull_time_out
>> -bash: echo: write error: Invalid argument
>>
>> Fix:
>> ---
>> This patch will help reset qfull_time_out to its default i.e.
>> qfull_time_out=-1
>>
>> Signed-off-by: Prasanna Kumar Kalever <prasanna.kale...@redhat.com>
>> ---
>>   drivers/target/target_core_user.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/target/target_core_user.c
>> b/drivers/target/target_core_user.c
>> index 4ad89ea71a70..4f26bdc3d1dc 100644
>> --- a/drivers/target/target_core_user.c
>> +++ b/drivers/target/target_core_user.c
>> @@ -2121,6 +2121,8 @@ static ssize_t tcmu_qfull_time_out_store(struct
>> config_item *item,
>>         if (val >= 0) {
>>           udev->qfull_time_out = val * MSEC_PER_SEC;
>> +    } else if (val == -1) {
>> +        udev->qfull_time_out = val;
>>       } else {
>>           printk(KERN_ERR "Invalid qfull timeout value %d\n", val);
>>           return -EINVAL;
> 
> This looks fine to me.
> 
> @Mike, IMO the -1 could also be settable just like this case. And does
> it have any other special meaning expects to compatible to cmd_time_out ?
> 

It was just for backwards compat. It was not meant to be settable,
because I didn't think someone would actually want to set it then reset
it to the compat mode again.

It seems fine.

Reply via email to