From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
Ard Biesheuvel <ardb@kernel.org>,
linux-efi <linux-efi@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Bhupesh Sharma <bhsharma@redhat.com>,
Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Subject: Re: [PATCH 6/6] efi/earlycon: Remap entire framebuffer after page initialization
Date: Wed, 11 Dec 2019 10:55:03 -0500 [thread overview]
Message-ID: <20191211155503.GA204038@rani.riverdale.lan> (raw)
In-Reply-To: <CAKv+Gu_VUAEw0auwhOyEAHn4BjDBPc9P4a+WBwJuRb_cBVi0NQ@mail.gmail.com>
On Wed, Dec 11, 2019 at 11:26:17AM +0000, Ard Biesheuvel wrote:
> On Tue, 10 Dec 2019 at 21:05, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > Thanks. Another q -- I tried out the earlycon=efifb, and it seems like
> > it gets disabled (without keep_bootcon) as soon as dummycon takes over,
> > which is well before the real console.
> >
> > DUMMY_CONSOLE is defined as
> > depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y
> > default y
> >
> > so it seems like it will pretty much always be enabled, as it doesn't
> > seem likely that VGA_CONSOLE=y and SGI_NEWPORT_CONSOLE=y would ever be
> > true simultaneously.
> >
> > Am I missing something or is this the way it's supposed to work? So
> > keep_bootcon seems almost necessary with the EFI boot console? Would a
> > patch to not disable boot console when dummycon is initialized, but wait
> > for a real console, be useful?
> >
>
> Well spotted!
>
> I have traced this down to [0] which combined various arch specific
> definitions into one, and obviously chose the wrong boolean operator
> for combining the conditions.
>
> Patches welcome.
>
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/drivers/video/console/Kconfig?id=31d2a7d36d6989c714b792ec00358ada24c039e7
Thanks! I was a little mistaken about what actually disables it though,
it seems to be when vt_console_driver gets registered, and at that point
the vt is still using dummy_con. I had thought dummy_con itself was a
console driver.
prev parent reply other threads:[~2019-12-11 15:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-06 16:55 [GIT PULL 0/6] EFI fixes for v5.5 Ard Biesheuvel
2019-12-06 16:55 ` [PATCH 1/6] efi/memreserve: register reservations as 'reserved' in /proc/iomem Ard Biesheuvel
2019-12-08 13:33 ` [tip: efi/urgent] efi/memreserve: Register " tip-bot2 for Ard Biesheuvel
2019-12-06 16:55 ` [PATCH 2/6] efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs Ard Biesheuvel
2019-12-08 13:33 ` [tip: efi/urgent] " tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 3/6] efi/gop: Return EFI_SUCCESS if a usable GOP was found Ard Biesheuvel
2019-12-08 13:33 ` [tip: efi/urgent] " tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 4/6] efi/gop: Fix memory leak from __gop_query32/64 Ard Biesheuvel
2019-12-08 13:33 ` [tip: efi/urgent] efi/gop: Fix memory leak in __gop_query32/64() tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 5/6] efi: fix type of unload field in efi_loaded_image_t Ard Biesheuvel
2019-12-08 13:33 ` [tip: efi/urgent] efi: Fix efi_loaded_image_t::unload type tip-bot2 for Arvind Sankar
2019-12-06 16:55 ` [PATCH 6/6] efi/earlycon: Remap entire framebuffer after page initialization Ard Biesheuvel
2019-12-08 13:33 ` [tip: efi/urgent] " tip-bot2 for Andy Shevchenko
2019-12-09 19:12 ` [PATCH 6/6] " Arvind Sankar
2019-12-09 19:24 ` Ard Biesheuvel
2019-12-10 20:05 ` Arvind Sankar
2019-12-11 11:26 ` Ard Biesheuvel
2019-12-11 15:55 ` Arvind Sankar [this message]
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=20191211155503.GA204038@rani.riverdale.lan \
--to=nivedita@alum.mit.edu \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=ardb@kernel.org \
--cc=bhsharma@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.mizuma@jp.fujitsu.com \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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.