New patch. Its easier I think to just move efi_init() earlier. Seems
less risky and less drawbacks.
Signed-off-by: Brian Maly <bmaly@redhat>
setup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
* Brian Maly <[email protected]> wrote:
> New patch. Its easier I think to just move efi_init() earlier. Seems
> less risky and less drawbacks.
>
> Signed-off-by: Brian Maly <bmaly@redhat>
>
>
> setup.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>
> --- a/arch/x86/kernel/setup.c 2009-03-03 21:24:53.000000000 -0500
> +++ b/arch/x86/kernel/setup.c 2009-03-03 21:26:00.000000000 -0500
> @@ -770,6 +770,9 @@ void __init setup_arch(char **cmdline_p)
>
> finish_e820_parsing();
>
> + if (efi_enabled)
> + efi_init();
> +
> dmi_scan_machine();
Hm, could we ever find ourselves in the positition of having to
access the DMI strings table in the EFI init code, to implement
a quirk? I think that's quite plausible.
OTOH, with some DMI quirks in EFI tables it's a bit of a chicken
and egg problem. Can DMI strings ever be outside of EFI tables
on EFI systems?
Ingo
>Hm, could we ever find ourselves in the positition of having to
>access the DMI strings table in the EFI init code, to implement
>a quirk? I think that's quite plausible.
>OTOH, with some DMI quirks in EFI tables it's a bit of a chicken
>and egg problem. Can DMI strings ever be outside of EFI tables
>on EFI systems?
> Ingo
Right now it is EFI that loads the dmi tables (and all other tables such
as ACPI), so it is a chicken and the egg. I think that if dmi is ever
needed by EFI, the dmi scan will have to be moved inside efi_init. We
could move the dmi scan into efi_init and do the dmi scan the moment we
have the dmi table. Thats really the soonest point we could scan on EFI
systems. Im OK with moving dmi to efi_init if you prefer.
Brian
* Brian Maly <[email protected]> wrote:
>
>
>> Hm, could we ever find ourselves in the positition of having to access
>> the DMI strings table in the EFI init code, to implement a quirk? I
>> think that's quite plausible.
>
>> OTOH, with some DMI quirks in EFI tables it's a bit of a chicken and
>> egg problem. Can DMI strings ever be outside of EFI tables on EFI
>> systems?
>
>> Ingo
>
> Right now it is EFI that loads the dmi tables (and all other
> tables such as ACPI), so it is a chicken and the egg. I think
> that if dmi is ever needed by EFI, the dmi scan will have to
> be moved inside efi_init. We could move the dmi scan into
> efi_init and do the dmi scan the moment we have the dmi table.
> Thats really the soonest point we could scan on EFI systems.
> Im OK with moving dmi to efi_init if you prefer.
Your patch looks fine, but i'd like to hear the opinion of Ying
Huang as well.
Ingo
Commit-ID: ff0c0874905fb312ca1491bbdac2653b0b48c20b
Gitweb: http://git.kernel.org/tip/ff0c0874905fb312ca1491bbdac2653b0b48c20b
Author: "Brian Maly" <[email protected]>
AuthorDate: Tue, 3 Mar 2009 21:55:31 -0500
Commit: Ingo Molnar <[email protected]>
CommitDate: Wed, 4 Mar 2009 18:55:56 +0100
x86: fix DMI on EFI
Impact: reactivate DMI quirks on EFI hardware
DMI tables are loaded by EFI, so the dmi calls must happen after
efi_init() and not before.
Currently Apple hardware uses DMI to determine the framebuffer mappings
for efifb. Without DMI working you also have no video on MacBook Pro.
This patch resolves the DMI issue for EFI hardware (DMI is now properly
detected at boot), and additionally efifb now loads on Apple hardware
(i.e. video works).
Signed-off-by: Brian Maly <bmaly@redhat>
Acked-by: Yinghai Lu <[email protected]>
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
arch/x86/kernel/setup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
---
arch/x86/kernel/setup.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c461f6d..6a8811a 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -770,6 +770,9 @@ void __init setup_arch(char **cmdline_p)
finish_e820_parsing();
+ if (efi_enabled)
+ efi_init();
+
dmi_scan_machine();
dmi_check_system(bad_bios_dmi_table);
@@ -789,8 +792,6 @@ void __init setup_arch(char **cmdline_p)
insert_resource(&iomem_resource, &data_resource);
insert_resource(&iomem_resource, &bss_resource);
- if (efi_enabled)
- efi_init();
#ifdef CONFIG_X86_32
if (ppro_with_ram_bug()) {
>Your patch looks fine, but i'd like to hear the opinion of Ying
>Huang as well.
I had asked him to look at this before I posted and he had no objections. He may have an opinion on moving dmi scan into efi_init, though this can certainly be done later if and when needed.
Brian
* Brian Maly <[email protected]> wrote:
>> Your patch looks fine, but i'd like to hear the opinion of
>> Ying Huang as well.
>
>
> I had asked him to look at this before I posted and he had no
> objections. He may have an opinion on moving dmi scan into
> efi_init, though this can certainly be done later if and when
> needed.
No, i think your patch is fine as-is - moving the dmi scan to
EFI init just makes EFI bootstrap a bit less standard - hence a
bit more fragile - and that's never good.
Since your patch fixes real issues on Apple hardware i also
queued it up in tip:x86/urgent for .29-rc8.
Ingo
On Thu, 2009-03-05 at 01:54 +0800, Ingo Molnar wrote:
> * Brian Maly <[email protected]> wrote:
>
> >
> >
> >> Hm, could we ever find ourselves in the positition of having to access
> >> the DMI strings table in the EFI init code, to implement a quirk? I
> >> think that's quite plausible.
> >
> >> OTOH, with some DMI quirks in EFI tables it's a bit of a chicken and
> >> egg problem. Can DMI strings ever be outside of EFI tables on EFI
> >> systems?
> >
> >> Ingo
> >
> > Right now it is EFI that loads the dmi tables (and all other
> > tables such as ACPI), so it is a chicken and the egg. I think
> > that if dmi is ever needed by EFI, the dmi scan will have to
> > be moved inside efi_init. We could move the dmi scan into
> > efi_init and do the dmi scan the moment we have the dmi table.
> > Thats really the soonest point we could scan on EFI systems.
> > Im OK with moving dmi to efi_init if you prefer.
>
> Your patch looks fine, but i'd like to hear the opinion of Ying
> Huang as well.
This patch is OK for me.
Thanks,
Huang Ying
* Huang Ying <[email protected]> wrote:
> On Thu, 2009-03-05 at 01:54 +0800, Ingo Molnar wrote:
> > * Brian Maly <[email protected]> wrote:
> >
> > >
> > >
> > >> Hm, could we ever find ourselves in the positition of having to access
> > >> the DMI strings table in the EFI init code, to implement a quirk? I
> > >> think that's quite plausible.
> > >
> > >> OTOH, with some DMI quirks in EFI tables it's a bit of a chicken and
> > >> egg problem. Can DMI strings ever be outside of EFI tables on EFI
> > >> systems?
> > >
> > >> Ingo
> > >
> > > Right now it is EFI that loads the dmi tables (and all other
> > > tables such as ACPI), so it is a chicken and the egg. I think
> > > that if dmi is ever needed by EFI, the dmi scan will have to
> > > be moved inside efi_init. We could move the dmi scan into
> > > efi_init and do the dmi scan the moment we have the dmi table.
> > > Thats really the soonest point we could scan on EFI systems.
> > > Im OK with moving dmi to efi_init if you prefer.
> >
> > Your patch looks fine, but i'd like to hear the opinion of Ying
> > Huang as well.
>
> This patch is OK for me.
thanks. There are two EFI patches queued up for .29:
dd39ecf: x86: EFI: Back efi_ioremap with init_memory_mapping instead of FIX_MAP
ff0c087: x86: fix DMI on EFI
Ingo