On Mon, Dec 3, 2012 at 12:02 PM, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: > On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote: >> On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett <mjg@xxxxxxxxxx> wrote: >> > V3 just fixes all the casting issues and incorporates David's change in >> > search ordering. >> >> I think there's still a section mismatch issue with these patches, so >> I haven't merged them yet. >> >> I rebased my pci/mjg-pci-roms-from-efi branch to v3.7-rc2, and if we >> get this issue fixed I'll put it in -next as v3.8 material. > > I still don't see this series in -next, so I take it the section > mismatch was never fixed? How about the following? > > > > From ece31852159a6b2cf9a059031638354e9817a6a6 Mon Sep 17 00:00:00 2001 > From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx> > Date: Mon, 3 Dec 2012 13:55:50 -0600 > Subject: [PATCH] x86: Don't discard boot_params > > boot_params is now used at runtime on EFI systems to stash option ROMs > that aren't available after exiting boot services, so it can no longer > be marked __initdata. > > Signed-off-by: Seth Forshee <seth.forshee@xxxxxxxxxxxxx> > --- > arch/x86/kernel/setup.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 468e98d..6e13035 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -143,11 +143,7 @@ int default_check_phys_apicid_present(int phys_apicid) > } > #endif > > -#ifndef CONFIG_DEBUG_BOOT_PARAMS > -struct boot_params __initdata boot_params; > -#else > struct boot_params boot_params; > -#endif > > /* > * Machine setup.. No, that is not a right fix We should only cache pointer to setup_data. at the same time we should export setup_data into /sys, so kexec could append this pointer to command of second kernel, just like kexec append acpi_rsdp. That should address DavidW's concern. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
