From: Ingo Molnar <mingo@kernel.org>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.de>,
x86@kernel.org, linux-fbdev@vger.kernel.org,
stable@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86: sysfb: fool-proof CONFIG_X86_SYSFB
Date: Thu, 19 Dec 2013 15:40:20 +0000 [thread overview]
Message-ID: <20131219154020.GB20044@gmail.com> (raw)
In-Reply-To: <1387460330-13989-1-git-send-email-dh.herrmann@gmail.com>
* 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
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.de>,
x86@kernel.org, linux-fbdev@vger.kernel.org,
stable@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86: sysfb: fool-proof CONFIG_X86_SYSFB
Date: Thu, 19 Dec 2013 16:40:20 +0100 [thread overview]
Message-ID: <20131219154020.GB20044@gmail.com> (raw)
In-Reply-To: <1387460330-13989-1-git-send-email-dh.herrmann@gmail.com>
* 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
next prev parent reply other threads:[~2013-12-19 15:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-19 13:38 [PATCH] x86: sysfb: fool-proof CONFIG_X86_SYSFB David Herrmann
2013-12-19 13:38 ` David Herrmann
2013-12-19 15:40 ` Ingo Molnar [this message]
2013-12-19 15:40 ` Ingo Molnar
2013-12-19 15:54 ` David Herrmann
2013-12-19 15:54 ` David Herrmann
2013-12-19 15:58 ` Ingo Molnar
2013-12-19 15:58 ` Ingo Molnar
2013-12-19 16:18 ` [PATCH v2] " David Herrmann
2013-12-19 16:18 ` David Herrmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131219154020.GB20044@gmail.com \
--to=mingo@kernel.org \
--cc=dh.herrmann@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tiwai@suse.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.