From: Leon Romanovsky <leon@xxxxxxxxxx> 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@xxxxxxxxx> >>> 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@xxxxxxx 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
