linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-efi@vger.kernel.org, mfleming@intel.com,
	dwmw2@infradead.org
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: Use PCI ROMs from EFI boot services
Date: Wed, 5 Dec 2012 13:09:25 -0700	[thread overview]
Message-ID: <CAErSpo7S2+Vt+9bkGLx_=AY9aSGCvAnkHfqu01gTj=eKs7btNw@mail.gmail.com> (raw)
In-Reply-To: <20121203200241.GG5906@thinkpad-t410>

On Mon, Dec 3, 2012 at 1:02 PM, Seth Forshee <seth.forshee@canonical.com> 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@redhat.com> 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?

That's right; nobody stepped up to fix the section mismatch.  I'm
happy to fold in your fix, especially if Matthew acks it.

David, Eric, what about the kexec question?  It looks to me like this
wouldn't make things worse than they are today.  If I understand
correctly, today we don't use ROM data from EFI on either an initial
boot or a kexec.  After this patch, we could use EFI ROM data on the
initial boot, but not after a kexec.  So it's worse in the sense that
the kexec case doesn't match the initial boot, but at least it's not
something that used to work and is now broken.

> From ece31852159a6b2cf9a059031638354e9817a6a6 Mon Sep 17 00:00:00 2001
> From: Seth Forshee <seth.forshee@canonical.com>
> 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@canonical.com>
> ---
>  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..
> --
> 1.7.9.5
>

  reply	other threads:[~2012-12-05 20:09 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23 16:36 Use PCI ROMs from EFI boot services Matthew Garrett
2012-08-23 16:36 ` [PATCH V3 1/4] EFI: Stash ROMs if they're not in the PCI BAR Matthew Garrett
2012-08-23 23:44   ` Bjorn Helgaas
2012-08-24  4:09     ` Matthew Garrett
2012-09-04 13:45     ` Matthew Garrett
2012-09-06 13:59       ` Bjorn Helgaas
2012-09-06 17:36         ` [PATCH] x86: Fix build warning on 32-bit Matthew Garrett
2012-09-06 20:02           ` Bjorn Helgaas
2012-08-23 16:36 ` [PATCH V3 2/4] PCI: Add pcibios_add_device Matthew Garrett
2012-08-23 16:36 ` [PATCH V3 3/4] PCI: Add support for non-BAR ROMs Matthew Garrett
2012-09-05  2:18   ` Don Dutile
2012-09-05  2:29     ` Matthew Garrett
2012-09-05 12:46       ` Alan Cox
2012-09-05 13:20         ` Matthew Garrett
2012-09-05 13:30           ` Alan Cox
2012-09-05 13:44             ` Matthew Garrett
2012-08-23 16:36 ` [PATCH V3 4/4] X86: Use PCI setup data Matthew Garrett
2012-08-24  9:30 ` Use PCI ROMs from EFI boot services David Woodhouse
2012-08-24 12:53   ` Matthew Garrett
2012-10-25 17:35 ` Bjorn Helgaas
2012-12-03 20:02   ` Seth Forshee
2012-12-05 20:09     ` Bjorn Helgaas [this message]
2012-12-05 20:22       ` Matthew Garrett
2012-12-05 22:21         ` Bjorn Helgaas
2012-12-05 21:06       ` David Woodhouse
2012-12-06  0:15     ` Yinghai Lu
2012-12-06  0:18       ` Matthew Garrett
2012-12-06  0:21         ` H. Peter Anvin
2012-12-06  0:30           ` Yinghai Lu
2012-12-06  0:36             ` H. Peter Anvin
2012-12-06  0:57               ` Matthew Garrett
2012-12-06  1:04                 ` H. Peter Anvin
2012-12-06  1:13                   ` Matthew Garrett
2012-12-06  1:21                     ` H. Peter Anvin
2012-12-06  6:19                       ` Matthew Garrett
2012-12-06  1:00           ` Matthew Garrett
2012-12-06  0:22         ` Yinghai Lu
2012-12-06  0:23         ` Eric W. Biederman
2012-12-06  0:36       ` H. Peter Anvin
2012-12-06  0:51         ` Yinghai Lu
2012-12-06  0:52           ` Yinghai Lu
2012-12-06 18:19             ` Bjorn Helgaas
2012-12-06 18:26               ` H. Peter Anvin
2012-12-06 18:54                 ` Matthew Garrett
2012-12-06 18:57                   ` Yinghai Lu
2012-12-06 21:44                   ` Bjorn Helgaas
2012-12-06  0:56           ` H. Peter Anvin

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='CAErSpo7S2+Vt+9bkGLx_=AY9aSGCvAnkHfqu01gTj=eKs7btNw@mail.gmail.com' \
    --to=bhelgaas@google.com \
    --cc=dwmw2@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mfleming@intel.com \
    --cc=mjg59@srcf.ucam.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).