Re: [PATCH 6/6] PM/FB/gxfb: add config option that allows disabling of VT switch during suspend
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2008-03-10 22:30:26
Also in:
lkml
On Mon, 10 Mar 2008 18:14:46 -0400 Andres Salomon [off-list ref] wrote:
On Mon, 10 Mar 2008 14:51:18 -0700 Andrew Morton [off-list ref] wrote:quoted
On Mon, 10 Mar 2008 17:44:24 -0400 Andres Salomon [off-list ref] wrote:quoted
On Mon, 10 Mar 2008 14:19:39 -0700 Andrew Morton [off-list ref] wrote:quoted
It would be far preferable to do this via a kernel boot parameter rather than via a kernel rebuild.Well, it shouldn't be supported at _all_ unless the framebuffer driver supports it; you're asking for it to be converted to something like the following? #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH static int no_vt_switch; #endif int pm_prepare_console(void) { #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH if (no_vt_switch) return 0; #endif ... } #ifdef CONFIG_FBDEV_SUPPORTS_NOSWITCH module_param(no_vt_switch, int, 0); MODULE_PARM_DESC(no_vt_switch, "..."); #endif If so, that means extra #ifdef's sprinkled throughout the code. Note that most framebuffer drivers won't be supporting this, and those that do will almost certainly always want vt switching turned off..I don't think you need any ifdefs or config options at all, do you? Just add a new module parameter to this driver and some little interface into the PM core which allows the driver to set no_vt_switch?That's a possibility, but doesn't adding hooks into PM core for two drivers (lxfb and gxfb) seems like overkill?
It's just a few bytes of code?
I also don't really see anyone needing to switch back and forth between VT_SWITCH and NO_VT_SWITCH other than to work around possible bugs in the register save/restore code..
Making driver behaviour depend upon compile-time settings is really to be avoided. A distributor has to choose one setting or the other, and a) that means that some people will get the wrong setting and b) there's a decent chance that the distributor will get it wrong. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/