Re: [PATCH ethtool-next v3 10/16] qsfp: Add JSON output handling to --module-info in SFF8636 modules

[Vadim Fedorenko <vadim.fedorenko@linux.dev>]

On 05/02/2025 12:13, Danielle Ratson wrote:
>> From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
>> Sent: Wednesday, 5 February 2025 12:48
>> To: Jakub Kicinski <kuba@kernel.org>; Danielle Ratson <danieller@nvidia.com>
>> Cc: netdev@vger.kernel.org; mkubecek@suse.cz; matt@traverse.com.au;
>> daniel.zahka@gmail.com; Amit Cohen <amcohen@nvidia.com>; NBU-mlxsw
>> <nbu-mlxsw@exchange.nvidia.com>
>> Subject: Re: [PATCH ethtool-next v3 10/16] qsfp: Add JSON output handling
>> to --module-info in SFF8636 modules
>>
>> On 05/02/2025 02:34, Jakub Kicinski wrote:
>>> On Tue, 4 Feb 2025 15:39:51 +0200 Danielle Ratson wrote:
>>>> +#define YESNO(x) (((x) != 0) ? "Yes" : "No") #define ONOFF(x) (((x)
>>>> +!= 0) ? "On" : "Off")
>>>
>>> Are these needed ? It appears we have them defined twice after this
>>> series:
>>>
>>> $ git grep 'define YES'
>>> cmis.h:#define YESNO(x) (((x) != 0) ? "Yes" : "No")
>>> module-common.h:#define YESNO(x) (((x) != 0) ? "Yes" : "No")
>>
>> Are we strict on capital first letter here? If not then maybe try to use
>> str_yes_no() and remove this definition completely?
> 
> I only moved it to a different file, I didn’t find a reason to change it right now.
> I can add a separate patch to change all the YESNO and ONOFF uses, and remove those definitions, do you want me to do that?
> To be honest, I don’t know if there is a justification to do it in that patchset, considering it is a pretty long anyway.

Well, I do really know that pure refactoring to str_yes_no() and
str_on_off() are not appreciated in netdev. I thought that we may
combine these changes, but no strong feeling. We may keep it as is.