An error occurred fetching the project authors.
  1. 09 May, 2015 8 commits
  2. 03 Jan, 2014 1 commit
  3. 26 Oct, 2013 1 commit
  4. 06 Feb, 2013 1 commit
    • Matt Fleming's avatar
      efi: Make 'efi_enabled' a function to query EFI facilities · 06c73e44
      Matt Fleming authored
      commit 83e68189 upstream.
      
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      [bwh: Backported to 3.2:
       - Adjust context (a lot)
       - Add efi_is_native() function from commit 5189c2a7
         ('x86: efi: Turn off efi_enabled after setup on mixed fw/kernel')
       - Make efi_init() bail out when booted non-native, as it would previously
         not be called in this case
       - Drop inapplicable changes to start_kernel()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      06c73e44
  5. 25 Jul, 2012 1 commit
  6. 05 Dec, 2011 2 commits
  7. 10 Oct, 2011 1 commit
  8. 21 Jul, 2011 2 commits
  9. 13 Jul, 2011 1 commit
  10. 06 Jul, 2011 1 commit
  11. 06 Apr, 2011 1 commit
    • Matthew Garrett's avatar
      x86: Reorder reboot method preferences · 660e34ce
      Matthew Garrett authored
      We have a never ending stream of 'reboot quirks' for new boxes
      that will not reboot properly under Linux (they will hang on
      reboot).
      
      The reason is widespread 'Windows compatible' assumption of modern
      x86 hardware, which expects the following reboot sequence:
      
       - hitting the ACPI reboot vector (if available)
       - trying the keyboard controller
       - hitting the ACPI reboot vector again
       - then giving the keyboard controller one last go
      
      This sequence expectation gets more and more embedded in modern
      hardware, which often lacks a keyboard controller and may even
      lock up if the legacy io ports are hit - and which hardware is
      often not tested with Linux during development.
      
      The end result is that reboot works under Windows-alike OSs but not
      under Linux.
      
      Rework our reboot process to meet this hardware externality a little
      better and match this assumption of newer x86 hardware.
      
      In addition to the ACPI,kbd,ACPI,kbd sequence we'll still fall
      through to attempting a legacy triple fault if nothing else
      works - and keep trying that and the kbd reset.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      [ this commit will also save special casing Oaktrail boards ]
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Leann Ogasawara <leann.ogasawara@canonical.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Len Brown <len.brown@intel.com>
      LKML-Reference: <1301939705-2404-1-git-send-email-mjg@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      660e34ce
  12. 29 Mar, 2011 1 commit
    • Jean Delvare's avatar
      x86: Stop including <linux/delay.h> in two asm header files · ca444564
      Jean Delvare authored
      Stop including <linux/delay.h> in x86 header files which don't
      need it. This will let the compiler complain when this header is
      not included by source files when it should, so that
      contributors can fix the problem before building on other
      architectures starts to fail.
      
      Credits go to Geert for the idea.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Cc: James E.J. Bottomley <James.Bottomley@suse.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20110325152014.297890ec@endymion.delvare>
      [ this also fixes an upstream build bug in drivers/media/rc/ite-cir.c ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ca444564
  13. 21 Feb, 2011 1 commit
  14. 18 Feb, 2011 1 commit
  15. 07 Jan, 2011 2 commits
    • Don Zickus's avatar
      x86, NMI: Remove DIE_NMI_IPI · c410b830
      Don Zickus authored
      With priorities in place and no one really understanding the difference between
      DIE_NMI and DIE_NMI_IPI, just remove DIE_NMI_IPI and convert everyone to DIE_NMI.
      
      This also simplifies default_do_nmi() a little bit.  Instead of calling the
      die_notifier in both the if and else part, just pull it out and call it before
      the if-statement.  This has the side benefit of avoiding a call to the ioport
      to see if there is an external NMI sitting around until after the (more frequent)
      internal NMIs are dealt with.
      Patch-Inspired-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294348732-15030-5-git-send-email-dzickus@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c410b830
    • Don Zickus's avatar
      x86, NMI: Add priorities to handlers · 166d7514
      Don Zickus authored
      In order to consolidate the NMI die_chain events, we need to setup the priorities
      for the die notifiers.
      
      I started by defining a bunch of common priorities that can be used by the
      notifier blocks.  Then I modified the notifier blocks to use the newly created
      priorities.
      
      Now that the priorities are straightened out, it should be easier to remove the
      event DIE_NMI_IPI.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1294348732-15030-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      166d7514
  16. 21 Oct, 2010 1 commit
    • Alok Kataria's avatar
      x86, kexec: Make sure to stop all CPUs before exiting the kernel · 76fac077
      Alok Kataria authored
      x86 smp_ops now has a new op, stop_other_cpus which takes a parameter
      "wait" this allows the caller to specify if it wants to stop until all
      the cpus have processed the stop IPI.  This is required specifically
      for the kexec case where we should wait for all the cpus to be stopped
      before starting the new kernel.  We now wait for the cpus to stop in
      all cases except for panic/kdump where we expect things to be broken
      and we are doing our best to make things work anyway.
      
      This patch fixes a legitimate regression, which was introduced during
      2.6.30, by commit id 4ef702c1.
      Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
      LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: <stable@kernel.org> v2.6.30-36
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      76fac077
  17. 20 Oct, 2010 1 commit
  18. 12 Aug, 2010 1 commit
  19. 20 Jun, 2010 1 commit
  20. 17 Feb, 2010 1 commit
  21. 28 Jan, 2010 1 commit
  22. 05 Dec, 2009 1 commit
    • Leann Ogasawara's avatar
      x86: ASUS P4S800 reboot=bios quirk · 4832ddda
      Leann Ogasawara authored
      Bug reporter noted their system with an ASUS P4S800 motherboard would
      hang when rebooting unless reboot=b was specified.  Their dmidecode
      didn't contain descriptive System Information for Manufacturer or
      Product Name, so I used their Base Board Information to create a
      reboot quirk patch.  The bug reporter confirmed this patch resolves
      the reboot hang.
      
      Handle 0x0001, DMI type 1, 25 bytes
      System Information
             Manufacturer: System Manufacturer
             Product Name: System Name
             Version: System Version
             Serial Number: SYS-1234567890
             UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F
             Wake-up Type: Power Switch
      
      Handle 0x0002, DMI type 2, 8 bytes
      Base Board Information
           Manufacturer: ASUSTeK Computer INC.
           Product Name: P4S800
           Version: REV 1.xx
           Serial Number: xxxxxxxxxxx
      
      BugLink: http://bugs.launchpad.net/bugs/366682
      
      ASUS P4S800 will hang when rebooting unless reboot=b is specified.
      Add a quirk to reboot through the bios.
      Signed-off-by: default avatarLeann Ogasawara <leann.ogasawara@canonical.com>
      LKML-Reference: <1259972107.4629.275.camel@emiko>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      4832ddda
  23. 08 Nov, 2009 1 commit
    • FUJITA Tomonori's avatar
      x86: Use x86_platform for iommu_shutdown · 338bac52
      FUJITA Tomonori authored
      This patch cleans up pci_iommu_shutdown() a bit to use
      x86_platform (similar to how IA64 initializes an IOMMU driver).
      
      This adds iommu_shutdown() to x86_platform to avoid calling
      every IOMMUs' shutdown functions in pci_iommu_shutdown() in
      order. The IOMMU shutdown functions are platform specific (we
      don't have multiple different IOMMU hardware) so the current way
      is pointless.
      
      An IOMMU driver sets x86_platform.iommu_shutdown to the shutdown
      function if necessary.
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: joerg.roedel@amd.com
      LKML-Reference: <20091027163358F.fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      338bac52
  24. 02 Nov, 2009 1 commit
  25. 11 Oct, 2009 1 commit
  26. 02 Sep, 2009 1 commit
  27. 10 Aug, 2009 1 commit
  28. 08 Aug, 2009 1 commit
  29. 03 Aug, 2009 1 commit
    • Paul Mackerras's avatar
      x86: Add quirk to make Apple MacBook5,2 use reboot=pci · 6c6c51e4
      Paul Mackerras authored
      The latest Apple MacBook (MacBook5,2) doesn't reboot successfully
      under Linux; neither the EFI reboot method nor the default method
      using the keyboard controller works (the system just hangs and doesn't
      reset).  However, the method using the "PCI reset register" at 0xcf9
      does work.
      
      This adds a quirk to detect this machine via DMI and force the
      reboot_type to BOOT_CF9.  With this it reboots successfully without
      requiring a command-line option.  Note that the EFI code forces
      reboot_type to BOOT_EFI when the machine is booted via EFI, but this
      overrides that since the core_initcall runs after the EFI
      initialization code.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      6c6c51e4
  30. 21 Jul, 2009 1 commit
    • Joseph Cihula's avatar
      x86, intel_txt: Intel TXT reboot/halt shutdown support · 840c2baf
      Joseph Cihula authored
      Support for graceful handling of kernel reboots after an Intel(R) TXT launch.
      
      Without this patch, attempting to reboot or halt the system will cause the
      TXT hardware to lock memory upon system restart because the secrets-in-memory
      flag that was set on launch was never cleared.  This will in turn cause BIOS
      to execute a TXT Authenticated Code Module (ACM) that will scrub all of memory
      and then unlock it.  Depending on the amount of memory in the system and its type,
      this may take some time.
      
      This patch creates a 1:1 address mapping to the tboot module and then calls back
      into tboot so that it may properly and securely clean up system state and clear
      the secrets-in-memory flag.  When it has completed these steps, the tboot module
      will reboot or halt the system.
      
       arch/x86/kernel/reboot.c |    8 ++++++++
       init/main.c              |    3 +++
       2 files changed, 11 insertions(+)
      Signed-off-by: default avatarJoseph Cihula <joseph.cihula@intel.com>
      Signed-off-by: default avatarShane Wang <shane.wang@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      840c2baf