The stub function returned -EOPNOTSUPP while CONFIG_NET_DEVLINK is off.
It caused false warning during driver load. Driver needs to update
devlink on a parameter value if devlink module is there, if not it
doesn't need any error code.
Fixes: ec01aeb1803e ("devlink: Add support for get/set driverinit value")
Signed-off-by: Moshe Shemesh <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
---
include/net/devlink.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index b9b89d6..b467357 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -781,7 +781,7 @@ static inline bool devlink_dpipe_table_counter_enabled(struct devlink *devlink,
devlink_param_driverinit_value_set(struct devlink *devlink, u32 param_id,
union devlink_param_value init_val)
{
- return -EOPNOTSUPP;
+ return 0;
}
static inline void
--
1.8.3.1
On 9/4/18 7:04 AM, Moshe Shemesh wrote:
> The stub function returned -EOPNOTSUPP while CONFIG_NET_DEVLINK is off.
> It caused false warning during driver load. Driver needs to update
> devlink on a parameter value if devlink module is there, if not it
> doesn't need any error code.
>
> Fixes: ec01aeb1803e ("devlink: Add support for get/set driverinit value")
> Signed-off-by: Moshe Shemesh <[email protected]>
> Acked-by: Jiri Pirko <[email protected]>
> ---
> include/net/devlink.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/devlink.h b/include/net/devlink.h
> index b9b89d6..b467357 100644
> --- a/include/net/devlink.h
> +++ b/include/net/devlink.h
> @@ -781,7 +781,7 @@ static inline bool devlink_dpipe_table_counter_enabled(struct devlink *devlink,
> devlink_param_driverinit_value_set(struct devlink *devlink, u32 param_id,
> union devlink_param_value init_val)
> {
> - return -EOPNOTSUPP;
> + return 0;
> }
>
> static inline void
>
This should be handled by the driver -- check for -EOPNOTSUPP and not
log an error.
devlink is generic infrastructure. If a call is made and the operation
is not supported, then devlink should return an error.
On 9/4/2018 7:13 PM, David Ahern wrote:
> On 9/4/18 7:04 AM, Moshe Shemesh wrote:
>> The stub function returned -EOPNOTSUPP while CONFIG_NET_DEVLINK is off.
>> It caused false warning during driver load. Driver needs to update
>> devlink on a parameter value if devlink module is there, if not it
>> doesn't need any error code.
>>
>> Fixes: ec01aeb1803e ("devlink: Add support for get/set driverinit value")
>> Signed-off-by: Moshe Shemesh <[email protected]>
>> Acked-by: Jiri Pirko <[email protected]>
>> ---
>> include/net/devlink.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/net/devlink.h b/include/net/devlink.h
>> index b9b89d6..b467357 100644
>> --- a/include/net/devlink.h
>> +++ b/include/net/devlink.h
>> @@ -781,7 +781,7 @@ static inline bool devlink_dpipe_table_counter_enabled(struct devlink *devlink,
>> devlink_param_driverinit_value_set(struct devlink *devlink, u32 param_id,
>> union devlink_param_value init_val)
>> {
>> - return -EOPNOTSUPP;
>> + return 0;
>> }
>>
>> static inline void
>>
>
> This should be handled by the driver -- check for -EOPNOTSUPP and not
> log an error.
This is a stub inline function.
The return value would be ambiguous as the non-stub function can also
return -EOPNOTSUPP, in case the driver-init mode is not supported for a
parameter.
>
> devlink is generic infrastructure. If a call is made and the operation
> is not supported, then devlink should return an error.
In general the stub functions should take care that the driver won't
feel the missing code as much as possible. That's why
devlink_params_register() returns success and so should this function.
>
On 9/5/18 6:48 AM, Moshe Shemesh wrote:
>
>
> On 9/4/2018 7:13 PM, David Ahern wrote:
>> On 9/4/18 7:04 AM, Moshe Shemesh wrote:
>>> The stub function returned -EOPNOTSUPP while CONFIG_NET_DEVLINK is off.
>>> It caused false warning during driver load. Driver needs to update
>>> devlink on a parameter value if devlink module is there, if not it
>>> doesn't need any error code.
>>>
>>> Fixes: ec01aeb1803e ("devlink: Add support for get/set driverinit
>>> value")
>>> Signed-off-by: Moshe Shemesh <[email protected]>
>>> Acked-by: Jiri Pirko <[email protected]>
>>> ---
>>> include/net/devlink.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/net/devlink.h b/include/net/devlink.h
>>> index b9b89d6..b467357 100644
>>> --- a/include/net/devlink.h
>>> +++ b/include/net/devlink.h
>>> @@ -781,7 +781,7 @@ static inline bool
>>> devlink_dpipe_table_counter_enabled(struct devlink *devlink,
>>> devlink_param_driverinit_value_set(struct devlink *devlink, u32
>>> param_id,
>>> union devlink_param_value init_val)
>>> {
>>> - return -EOPNOTSUPP;
>>> + return 0;
>>> }
>>> static inline void
>>>
>>
>> This should be handled by the driver -- check for -EOPNOTSUPP and not
>> log an error.
>
> This is a stub inline function.
> The return value would be ambiguous as the non-stub function can also
> return -EOPNOTSUPP, in case the driver-init mode is not supported for a
> parameter.
>>
>> devlink is generic infrastructure. If a call is made and the operation
>> is not supported, then devlink should return an error.
>
> In general the stub functions should take care that the driver won't
> feel the missing code as much as possible. That's why
> devlink_params_register() returns success and so should this function.
>>
A driver is accessing core infrastructure to set a value; core infra can
not because the code is not compiled in. The driver should be told that
the option is not enabled, and it is at the moment with the -EOPNOTSUPP
return code.
That is similar to devlink_dpipe_table_resource_set which returns
-EOPNOTSUPP when devlink is compiled out.
On 9/5/2018 5:26 PM, David Ahern wrote:
> On 9/5/18 6:48 AM, Moshe Shemesh wrote:
>>
>>
>> On 9/4/2018 7:13 PM, David Ahern wrote:
>>> On 9/4/18 7:04 AM, Moshe Shemesh wrote:
>>>> The stub function returned -EOPNOTSUPP while CONFIG_NET_DEVLINK is off.
>>>> It caused false warning during driver load. Driver needs to update
>>>> devlink on a parameter value if devlink module is there, if not it
>>>> doesn't need any error code.
>>>>
>>>> Fixes: ec01aeb1803e ("devlink: Add support for get/set driverinit
>>>> value")
>>>> Signed-off-by: Moshe Shemesh <[email protected]>
>>>> Acked-by: Jiri Pirko <[email protected]>
>>>> ---
>>>> include/net/devlink.h | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/net/devlink.h b/include/net/devlink.h
>>>> index b9b89d6..b467357 100644
>>>> --- a/include/net/devlink.h
>>>> +++ b/include/net/devlink.h
>>>> @@ -781,7 +781,7 @@ static inline bool
>>>> devlink_dpipe_table_counter_enabled(struct devlink *devlink,
>>>> devlink_param_driverinit_value_set(struct devlink *devlink, u32
>>>> param_id,
>>>> union devlink_param_value init_val)
>>>> {
>>>> - return -EOPNOTSUPP;
>>>> + return 0;
>>>> }
>>>> static inline void
>>>>
>>>
>>> This should be handled by the driver -- check for -EOPNOTSUPP and not
>>> log an error.
>>
>> This is a stub inline function.
>> The return value would be ambiguous as the non-stub function can also
>> return -EOPNOTSUPP, in case the driver-init mode is not supported for a
>> parameter.
>>>
>>> devlink is generic infrastructure. If a call is made and the operation
>>> is not supported, then devlink should return an error.
>>
>> In general the stub functions should take care that the driver won't
>> feel the missing code as much as possible. That's why
>> devlink_params_register() returns success and so should this function.
>>>
>
> A driver is accessing core infrastructure to set a value; core infra can
> not because the code is not compiled in. The driver should be told that
> the option is not enabled, and it is at the moment with the -EOPNOTSUPP
> return code.
>
> That is similar to devlink_dpipe_table_resource_set which returns
> -EOPNOTSUPP when devlink is compiled out.
Yes, that was my original thought when I wrote this stub, but actually
in this case the driver has the value and it wants to update devlink, so
devlink will have it too. If devlink module is not there why should it
really care ?
>