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. 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
