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.kalever@xxxxxxxxxx>
>> ---
>> 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.
