linux.git/arch/x86/platform, branch v3.2

Revert "x86, efi: Calling __pa() with an ioremap()ed address is invalid"

2011-12-12T17:25:56+00:00

This hangs my MacBook Air at boot time; I get no console
messages at all. I reverted this on top of -rc5 and my machine
boots again.

This reverts commit e8c7106280a305e1ff2a3a8a4dfce141469fb039.

Signed-off-by: Matt Fleming 
Signed-off-by: Keith Packard 
Acked-by: H. Peter Anvin 
Cc: Matthew Garrett 
Cc: Zhang Rui 
Cc: Huang Ying 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console
Signed-off-by: Ingo Molnar

x86, efi: Make efi_call_phys_{prelog,epilog} CONFIG_RELOCATABLE-aware

2011-12-10T00:39:11+00:00

efi_call_phys_prelog() sets up a 1:1 mapping of the physical address
range in swapper_pg_dir. Instead of replacing then restoring entries
in swapper_pg_dir we should be using initial_page_table which already
contains the 1:1 mapping.

It's safe to blindly switch back to swapper_pg_dir in the epilog
because the physical EFI routines are only called before
efi_enter_virtual_mode(), e.g. before any user processes have been
forked. Therefore, we don't need to track which pgd was in %cr3 when
we entered the prelog.

The previous code actually contained a bug because it assumed that the
kernel was loaded at a physical address within the first 8MB of ram,
usually at 0x100000. However, this isn't the case with a
CONFIG_RELOCATABLE=y kernel which could have been loaded anywhere in
the physical address space.

Also delete the ancient (and bogus) comments about the page table
being restored after the lock is released. There is no locking.

Cc: Matthew Garrett 
Cc: Darrent Hart 
Signed-off-by: Matt Fleming 
Link: http://lkml.kernel.org/r/1323346250.3894.74.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin

x86, efi: Calling __pa() with an ioremap()ed address is invalid

2011-12-09T07:32:26+00:00

If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set
in ->attribute we currently call set_memory_uc(), which in turn
calls __pa() on a potentially ioremap'd address.

On CONFIG_X86_32 this is invalid, resulting in the following
oops on some machines:

  BUG: unable to handle kernel paging request at f7f22280
  IP: [] reserve_ram_pages_type+0x89/0x210
  [...]

  Call Trace:
   [] ? page_is_ram+0x1a/0x40
   [] reserve_memtype+0xdf/0x2f0
   [] set_memory_uc+0x49/0xa0
   [] efi_enter_virtual_mode+0x1c2/0x3aa
   [] start_kernel+0x291/0x2f2
   [] ? loglevel+0x1b/0x1b
   [] i386_start_kernel+0xbf/0xc8

A better approach to this problem is to map the memory region
with the correct attributes from the start, instead of modifying
it after the fact. The uncached case can be handled by
ioremap_nocache() and the cached by ioremap_cache().

Despite first impressions, it's not possible to use
ioremap_cache() to map all cached memory regions on
CONFIG_X86_64 because EFI_RUNTIME_SERVICES_DATA regions really
don't like being mapped into the vmalloc space, as detailed in
the following bug report,

	https://bugzilla.redhat.com/show_bug.cgi?id=748516

Therefore, we need to ensure that any EFI_RUNTIME_SERVICES_DATA
regions are covered by the direct kernel mapping table on
CONFIG_X86_64. To accomplish this we now map E820_RESERVED_EFI
regions via the direct kernel mapping with the initial call to
init_memory_mapping() in setup_arch(), whereas previously these
regions wouldn't be mapped if they were after the last E820_RAM
region until efi_ioremap() was called. Doing it this way allows
us to delete efi_ioremap() completely.

Signed-off-by: Matt Fleming 
Cc: H. Peter Anvin 
Cc: Matthew Garrett 
Cc: Zhang Rui 
Cc: Huang Ying 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console-pimps.org
Signed-off-by: Ingo Molnar

x86, mrst: Change the pmic_gpio device type to IPC

2011-12-05T11:42:15+00:00

In latest firmware's SFI tables, pmic_gpio has been set to
IPC type of device, so we need handle it too.

Signed-off-by: Feng Tang 
Signed-off-by: Alan Cox 
Signed-off-by: Ingo Molnar

mrst: Added some platform data for the SFI translations

2011-12-05T11:42:13+00:00

Add SFI glue for the following devices:

tca6416: a gpio expander compatible with max7315
mpu3050: gyro sensor

Both of these actual drivers are already upstream

Signed-off-by: Jekyll Lai 
Signed-off-by: Alan Cox 
Signed-off-by: Ingo Molnar

x86,mrst: Power control commands update

2011-12-05T11:42:11+00:00

On the Intel MID devices SCU commands are issued to manage power
off and the like. We need to issue different ones for
non-Lincroft based devices.

Signed-off-by: Alek Du 
Signed-off-by: Jacob Pan 
Signed-off-by: Alan Cox 
Signed-off-by: Ingo Molnar

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2011-11-19T00:16:18+00:00

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  random: Fix handing of arch_get_random_long in get_random_bytes()
  x86: Call stop_machine_text_poke() on all CPUs
  x86, ioapic: Only print ioapic debug information for IRQs belonging to an ioapic chip
  x86/mrst: Avoid reporting wrong nmi status
  x86/mrst: Add support for Penwell clock calibration
  x86/apic: Allow use of lapic timer early calibration result
  x86/apic: Do not clear nr_irqs_gsi if no legacy irqs
  x86/platform: Add a wallclock_init func to x86_platforms ops
  x86/mce: Make mce_chrdev_ops 'static const'

bma023: Add SFI translation for this device

2011-11-12T01:58:58+00:00

This needed the sfi IRQ 0xFF fix to go in first. It simply plumbs in the
bma023 driver with the firmware naming of it.

Signed-off-by: William Douglas 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds

vrtc: change its year offset from 1960 to 1972

2011-11-12T01:58:58+00:00

Real world year equals the value in vrtc YEAR register plus an offset.
We used 1960 as the offset to make leap year consistent, but for a
device's first use, its YEAR register is 0 and the system year will
be parsed as 1960 which is not a valid UNIX time and will cause many
applications to fail mysteriously. So we use 1972 instead to fix this
issue.

Updated patch which adds a sanity check suggested by Mathias

This isn't a change in behaviour for systems, because 1972 is the one we
actually use. It's the old version in upstream which is out of sync with
all devices.

Signed-off-by: Feng Tang 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds

ce4100: fix a build error

2011-11-12T01:58:58+00:00

Fix a build error. CE4100 with no serial errors because the alternate
function is only a prototype not a null function as intended.

Signed-off-by: Zhang Rui 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds