x86: sysfb: fool-proof CONFIG_X86_SYSFB
diff mbox

Message ID 1387460330-13989-1-git-send-email-dh.herrmann@gmail.com
State New, archived
Headers show

Commit Message

David Herrmann Dec. 19, 2013, 1:38 p.m. UTC
Turns out, people do not read help-texts of new config-options and enable
them nonetheless. So several reports came in with X86_SYSFB=y and
FB_SIMPLE=n, which in almost all situations prevents firmware-fbs from
being probed.

X86_SYSFB clearly states that it turns legacy vesa/efi framebuffers into a
format compatible to simplefb (and does nothing else..). So to avoid
further complaints about missing gfx-support during boot, simply depend on
FB_SIMPLE now.
As FB_SIMPLE is disabled by default and usually only enabled on selected
ARM architectures, x86 users should thus never see the X86_SYSFB
config-option. And if they do, everything is fine as simplefb will be
available.

Note that most of the sysfb code is enabled independently of X86_SYSFB.
The config option only selects a compatibility mode for simplefb. It was
introduced to ease the transition to SimpleDRM and disabling fbdev. As
this is still ongoing, there's no need for non-developers to care for
X86_SYSFB so just change the help-text recommendation to "n".

Cc: <stable@vger.kernel.org> # 3.11+
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
 arch/x86/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Ingo Molnar Dec. 19, 2013, 3:40 p.m. UTC | #1
* David Herrmann <dh.herrmann@gmail.com> wrote:

> Turns out, people do not read help-texts of new config-options and 
> enable them nonetheless. [...]

Yeah, I too don't read them either, whenever an option name seems 
obvious to enable, so this is really something that happens frequently 
;-)

> [...] So several reports came in with X86_SYSFB=y and FB_SIMPLE=n, 
> which in almost all situations prevents firmware-fbs from being 
> probed.
> 
> X86_SYSFB clearly states that it turns legacy vesa/efi framebuffers 
> into a format compatible to simplefb (and does nothing else..). So 
> to avoid further complaints about missing gfx-support during boot, 
> simply depend on FB_SIMPLE now.
>
> As FB_SIMPLE is disabled by default and usually only enabled on 
> selected ARM architectures, x86 users should thus never see the 
> X86_SYSFB config-option. And if they do, everything is fine as 
> simplefb will be available.
> 
> Note that most of the sysfb code is enabled independently of 
> X86_SYSFB. The config option only selects a compatibility mode for 
> simplefb. It was introduced to ease the transition to SimpleDRM and 
> disabling fbdev. As this is still ongoing, there's no need for 
> non-developers to care for X86_SYSFB so just change the help-text 
> recommendation to "n".
> 
> Cc: <stable@vger.kernel.org> # 3.11+
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> ---
>  arch/x86/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e903c71..9317ede 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2298,6 +2298,7 @@ source "drivers/rapidio/Kconfig"
>  
>  config X86_SYSFB
>  	bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
> +	depends on (FB_SIMPLE = y)

Could that be written as:

	depends on FB_SIMPLE

Or is there some complication with modular builds?

>  	help
>  	  Firmwares often provide initial graphics framebuffers so the BIOS,
>  	  bootloader or kernel can show basic video-output during boot for
> @@ -2320,7 +2321,7 @@ config X86_SYSFB
>  	  and others enabled as fallback if a system framebuffer is
>  	  incompatible with simplefb.
>  
> -	  If unsure, say Y.
> +	  If unsure, say N.

We might in fact leave this bit alone and suggest 'Y' - with the 
robustification fixes it's not possible anymore to crash the boot or 
to create an unintentionally headless system, right?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Herrmann Dec. 19, 2013, 3:54 p.m. UTC | #2
Hi

On Thu, Dec 19, 2013 at 4:40 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * David Herrmann <dh.herrmann@gmail.com> wrote:
>
>> Turns out, people do not read help-texts of new config-options and
>> enable them nonetheless. [...]
>
> Yeah, I too don't read them either, whenever an option name seems
> obvious to enable, so this is really something that happens frequently
> ;-)
>
>> [...] So several reports came in with X86_SYSFB=y and FB_SIMPLE=n,
>> which in almost all situations prevents firmware-fbs from being
>> probed.
>>
>> X86_SYSFB clearly states that it turns legacy vesa/efi framebuffers
>> into a format compatible to simplefb (and does nothing else..). So
>> to avoid further complaints about missing gfx-support during boot,
>> simply depend on FB_SIMPLE now.
>>
>> As FB_SIMPLE is disabled by default and usually only enabled on
>> selected ARM architectures, x86 users should thus never see the
>> X86_SYSFB config-option. And if they do, everything is fine as
>> simplefb will be available.
>>
>> Note that most of the sysfb code is enabled independently of
>> X86_SYSFB. The config option only selects a compatibility mode for
>> simplefb. It was introduced to ease the transition to SimpleDRM and
>> disabling fbdev. As this is still ongoing, there's no need for
>> non-developers to care for X86_SYSFB so just change the help-text
>> recommendation to "n".
>>
>> Cc: <stable@vger.kernel.org> # 3.11+
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> ---
>>  arch/x86/Kconfig | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index e903c71..9317ede 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -2298,6 +2298,7 @@ source "drivers/rapidio/Kconfig"
>>
>>  config X86_SYSFB
>>       bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
>> +     depends on (FB_SIMPLE = y)
>
> Could that be written as:
>
>         depends on FB_SIMPLE
>
> Or is there some complication with modular builds?

simplefb is actually "bool" so yeah, I can remove the "= y".

Note that *if* it ever is built as module, it will not get loaded
during boot, thus not showing any boot-messages. But that's true for
vesafb/efifb, too, so we're fine.

>>       help
>>         Firmwares often provide initial graphics framebuffers so the BIOS,
>>         bootloader or kernel can show basic video-output during boot for
>> @@ -2320,7 +2321,7 @@ config X86_SYSFB
>>         and others enabled as fallback if a system framebuffer is
>>         incompatible with simplefb.
>>
>> -       If unsure, say Y.
>> +       If unsure, say N.
>
> We might in fact leave this bit alone and suggest 'Y' - with the
> robustification fixes it's not possible anymore to crash the boot or
> to create an unintentionally headless system, right?

Nope, we will not cause a headless system, but the handover to other
fbdev/DRM drivers (other than the common nouveau/radeon/i915) may
still fail without the other patch (x86: sysfb: remove sysfb when
probing real hw).

I will gladly keep the Y, if no-one disagrees. Given that the other
patch is rather complex (and a no-op with X86_SYSFB=n) I wasn't quite
sure. But as SYSFB is set to 'n' now if FB_SIMPLE wasn't explicitly
selected, I think we're fine both ways.

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ingo Molnar Dec. 19, 2013, 3:58 p.m. UTC | #3
* David Herrmann <dh.herrmann@gmail.com> wrote:

> Hi
> 
> On Thu, Dec 19, 2013 at 4:40 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * David Herrmann <dh.herrmann@gmail.com> wrote:
> >
> >> Turns out, people do not read help-texts of new config-options and
> >> enable them nonetheless. [...]
> >
> > Yeah, I too don't read them either, whenever an option name seems
> > obvious to enable, so this is really something that happens frequently
> > ;-)
> >
> >> [...] So several reports came in with X86_SYSFB=y and FB_SIMPLE=n,
> >> which in almost all situations prevents firmware-fbs from being
> >> probed.
> >>
> >> X86_SYSFB clearly states that it turns legacy vesa/efi framebuffers
> >> into a format compatible to simplefb (and does nothing else..). So
> >> to avoid further complaints about missing gfx-support during boot,
> >> simply depend on FB_SIMPLE now.
> >>
> >> As FB_SIMPLE is disabled by default and usually only enabled on
> >> selected ARM architectures, x86 users should thus never see the
> >> X86_SYSFB config-option. And if they do, everything is fine as
> >> simplefb will be available.
> >>
> >> Note that most of the sysfb code is enabled independently of
> >> X86_SYSFB. The config option only selects a compatibility mode for
> >> simplefb. It was introduced to ease the transition to SimpleDRM and
> >> disabling fbdev. As this is still ongoing, there's no need for
> >> non-developers to care for X86_SYSFB so just change the help-text
> >> recommendation to "n".
> >>
> >> Cc: <stable@vger.kernel.org> # 3.11+
> >> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> >> ---
> >>  arch/x86/Kconfig | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index e903c71..9317ede 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -2298,6 +2298,7 @@ source "drivers/rapidio/Kconfig"
> >>
> >>  config X86_SYSFB
> >>       bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
> >> +     depends on (FB_SIMPLE = y)
> >
> > Could that be written as:
> >
> >         depends on FB_SIMPLE
> >
> > Or is there some complication with modular builds?
> 
> simplefb is actually "bool" so yeah, I can remove the "= y".
> 
> Note that *if* it ever is built as module, it will not get loaded
> during boot, thus not showing any boot-messages. But that's true for
> vesafb/efifb, too, so we're fine.
> 
> >>       help
> >>         Firmwares often provide initial graphics framebuffers so the BIOS,
> >>         bootloader or kernel can show basic video-output during boot for
> >> @@ -2320,7 +2321,7 @@ config X86_SYSFB
> >>         and others enabled as fallback if a system framebuffer is
> >>         incompatible with simplefb.
> >>
> >> -       If unsure, say Y.
> >> +       If unsure, say N.
> >
> > We might in fact leave this bit alone and suggest 'Y' - with the
> > robustification fixes it's not possible anymore to crash the boot or
> > to create an unintentionally headless system, right?
> 
> Nope, we will not cause a headless system, but the handover to other
> fbdev/DRM drivers (other than the common nouveau/radeon/i915) may
> still fail without the other patch (x86: sysfb: remove sysfb when
> probing real hw).
> 
> I will gladly keep the Y, if no-one disagrees. Given that the other 
> patch is rather complex (and a no-op with X86_SYSFB=n) I wasn't 
> quite sure. But as SYSFB is set to 'n' now if FB_SIMPLE wasn't 
> explicitly selected, I think we're fine both ways.

Well, as long as fixes keep coming when people report them, I see no 
problem with keeping the 'Y'. Bugs happen.

And I think we want to apply the other fix regardless of the default.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e903c71..9317ede 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2298,6 +2298,7 @@  source "drivers/rapidio/Kconfig"
 
 config X86_SYSFB
 	bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
+	depends on (FB_SIMPLE = y)
 	help
 	  Firmwares often provide initial graphics framebuffers so the BIOS,
 	  bootloader or kernel can show basic video-output during boot for
@@ -2320,7 +2321,7 @@  config X86_SYSFB
 	  and others enabled as fallback if a system framebuffer is
 	  incompatible with simplefb.
 
-	  If unsure, say Y.
+	  If unsure, say N.
 
 endmenu