netdev - Re: [PATCH v7 net-next 2/8] sfc: add devlink info support for ef100

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cf18fcc9-d56d-bfe0-d993-128ef27c60e5@intel.com>
Date:   Wed, 15 Feb 2023 18:07:01 +0100
From:   Alexander Lobakin <aleksander.lobakin@...el.com>
To:     "Lucero Palau, Alejandro" <alejandro.lucero-palau@....com>
CC:     Leon Romanovsky <leon@...nel.org>,
        Edward Cree <ecree.xilinx@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-net-drivers (AMD-Xilinx)" <linux-net-drivers@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "habetsm.xilinx@...il.com" <habetsm.xilinx@...il.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "corbet@....net" <corbet@....net>,
        "jiri@...dia.com" <jiri@...dia.com>
Subject: Re: [PATCH v7 net-next 2/8] sfc: add devlink info support for ef100

From: Leon Romanovsky <leon@...nel.org>
Date: Wed, 15 Feb 2023 14:22:16 +0200

> On Wed, Feb 15, 2023 at 08:43:21AM +0000, Lucero Palau, Alejandro wrote:
>>
>> On 2/14/23 16:56, Alexander Lobakin wrote:
>>> From: Edward Cree <ecree.xilinx@...il.com>
>>> Date: Tue, 14 Feb 2023 15:28:24 +0000
>>>
>>>> On 14/02/2023 07:39, Leon Romanovsky wrote:
>>>>> On Mon, Feb 13, 2023 at 06:34:22PM +0000, alejandro.lucero-palau@....com wrote:
>>>>>> +#ifdef CONFIG_RTC_LIB
>>>>>> +	u64 tstamp;
>>>>>> +#endif
>>>>> If you are going to resubmit the series.
>>>>>
>>>>> Documentation/process/coding-style.rst
>>>>>    1140 21) Conditional Compilation
>>>>>    1141 ---------------------------
>>>>> ....
>>>>>    1156 If you have a function or variable which may potentially go unused in a
>>>>>    1157 particular configuration, and the compiler would warn about its definition
>>>>>    1158 going unused, mark the definition as __maybe_unused rather than wrapping it in
>>>>>    1159 a preprocessor conditional.  (However, if a function or variable *always* goes
>>>>>    1160 unused, delete it.)
>>>>>
>>>>> Thanks
>>>> FWIW, the existing code in sfc all uses the preprocessor
>>>>   conditional approach; maybe it's better to be consistent
>>>>   within the driver?
>>>>
>>> When it comes to "consistency vs start doing it right" thing, I always
>>> go for the latter. This "we'll fix it all one day" moment often tends to
>>> never happen and it's applicable to any vendor or subsys. Stop doing
>>> things the discouraged way often is a good (and sometimes the only) start.
>>
>>
>> It is not clear to me what you prefer, if fixing this now or leaving it 
>> and fixing it later.
> 
> He asked to fix.

Correct. What I meant is that I always prefer to send stuff already done
right and not continue adding more todo-stuff to the kernel just because
there are tons of similar todo-stuff in the kernel already :D

> 
> Thanks
> 
>>
>> The first sentence in your comment suggest the latter to me. The rest of 
>> the comment suggests the fix it now.
>>
>> Anyway, patchwork says changes requested, so I'll send v8.
>>
>> Thanks
>>
>>> Thanks,
>>> Olek

Thanks,
Olek