On Tuesday, October 28, 2014 9:11 AM, Dmitry Torokhov wrote: > On Tue, Oct 28, 2014 at 09:02:44AM +0900, Jingoo Han wrote: > > On Tuesday, October 28, 2014 8:38 AM, Dmitry Torokhov wrote: > > > On Mon, Oct 27, 2014 at 09:32:58PM +0900, Jingoo Han wrote: > > > > Add CONFIG_PM_SLEEP to suspend/resume functions > > > > > > > > Add CONFIG_PM_SLEEP to suspend/resume functions instead of > > > > CONFIG_PM to fix the following build warning when CONFIG_PM_SLEEP > > > > is not selected and CONFIG_PM is selected. This is because sleep > > > > PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the > > > > CONFIG_PM_SLEEP is enabled. > > > > > > Recently I've become a fan of __maybe_unused markings as they insulate > > > us from various CONFIG changes in unrelated subsystems, I'll transform > > > this patch to use them instead. > > > > OK, I see. I have no objection. > > Then, how about changing other usages of CONFIG_PM_SLEEP/CONFIG_PM > > to __maybe_unused annotation? Personally, I prefer to increase build > > coverage than using #ifdef guards. Someone, however, argued that #ifdef > > guards should be used in this case because the size of binary can be > > reduced. How about your opinion? > > The optimizer is supposed to drop functions marked as '__maybe_unused' > if they are indeed unused so size of the binary should not change. Sorry for annoying you. I built 'spear-keyboard' and got the binaries as below. spear-keyboard.o 89500 bytes, <-- CONFIG_PM_SLEEP=n spear-keyboard.o 92352 bytes, <-- CONFIG_PM_SLEEP=y spear-keyboard.o 92352 bytes, <-- Marked as __maybe_unused As presented above, when CONFIG_PM_SLEEP is used instead of __maybe_unused, the size of binary is reduced. So, someone complained me to use #ifdef guards. But, I agree with your opinion. Personally, I DON'T want to use #ifdef guards, because I prefer to increase build coverage. Thank you. > > Thanks. > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
