1. 30 Jan, 2013 2 commits
    • Matt Fleming's avatar
      samsung-laptop: Disable on EFI hardware · e0094244
      Matt Fleming authored
      It has been reported that running this driver on some Samsung laptops
      with EFI can cause those machines to become bricked as detailed in the
      following report,
      There have also been reports of this driver causing Machine Check
      Exceptions on recent EFI-enabled Samsung laptops,
      So disable it if booting from EFI since this driver relies on
      grovelling around in the BIOS memory map which isn't going to work.
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
    • Matt Fleming's avatar
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming authored
      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,
      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,
      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
      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>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  2. 28 Jan, 2013 1 commit
    • Wang YanQing's avatar
      smp: Fix SMP function call empty cpu mask race · f44310b9
      Wang YanQing authored
      I get the following warning every day with v3.7, once or
      twice a day:
        [ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8()
      As explained by Linus as well:
       | Once we've done the "list_add_rcu()" to add it to the
       | queue, we can have (another) IPI to the target CPU that can
       | now see it and clear the mask.
       | So by the time we get to actually send the IPI, the mask might
       | have been cleared by another IPI.
      This patch also fixes a system hang problem, if the data->cpumask
      gets cleared after passing this point:
              if (WARN_ONCE(!mask, "empty IPI mask"))
      then the problem in commit 83d349f3
       ("x86: don't send an IPI to
      the empty set of CPU's") will happen again.
      Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: peterz@infradead.org
      Cc: mina86@mina86.org
      Cc: srivatsa.bhat@linux.vnet.ibm.com
      Cc: <stable@kernel.org>
      Link: http://lkml.kernel.org/r/20130126075357.GA3205@udknight
      [ Tidied up the changelog and the comment in the code. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  3. 24 Jan, 2013 5 commits
  4. 19 Jan, 2013 1 commit
    • H. Peter Anvin's avatar
      x86-32: Start out cr0 clean, disable paging before modifying cr3/4 · 021ef050
      H. Peter Anvin authored
       x86-32: Start out eflags and cr4 clean
      ... made x86-32 match x86-64 in that we initialize %eflags and %cr4
      from scratch.  This broke OLPC XO-1.5, because the XO enters the
      kernel with paging enabled, which the kernel doesn't expect.
      Since we no longer support 386 (the source of most of the variability
      in %cr0 configuration), we can simply match further x86-64 and
      initialize %cr0 to a fixed value -- the one variable part remaining in
      %cr0 is for FPU control, but all that is handled later on in
      initialization; in particular, configuring %cr0 as if the FPU is
      present until proven otherwise is correct and necessary for the probe
      to work.
      To deal with the XO case sanely, explicitly disable paging in %cr0
      before we muck with %cr3, %cr4 or EFER -- those operations are
      inherently unsafe with paging enabled.
      NOTE: There is still a lot of 386-related junk in head_32.S which we
      can and should get rid of, however, this is intended as a minimal fix
      whereas the cleanup can be deferred to the next merge window.
      Reported-by: default avatarAndres Salomon <dilinger@queued.net>
      Tested-by: default avatarDaniel Drake <dsd@laptop.org>
      Link: http://lkml.kernel.org/r/50FA0661.2060400@linux.intel.com
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  5. 17 Jan, 2013 2 commits
  6. 16 Jan, 2013 25 commits
  7. 15 Jan, 2013 3 commits
  8. 14 Jan, 2013 1 commit
    • Takashi Iwai's avatar
      Merge tag 'asoc-atmel-pinctrl' of... · 2e4c4dbe
      Takashi Iwai authored
      Merge tag 'asoc-atmel-pinctrl' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      ASoC: atmel: Fixes for pinctrl
      Due to a series of problems with the handling of Atmel, a combination of
      making changes that make other branches instantly buggy and a general
      failure to deal with the resulting issues effectively, v3.8 Atmel audio
      currently won't work at all for DT boards without adding pinctrl
      definitions and a request for those.