| Age | Commit message (Collapse) | Author |
|---|
|
This closes a couple holes in our attribute aliasing avoidance scheme:
- The current kernel fails mmaps of some /dev/mem MMIO regions because
they don't appear in the EFI memory map. This keeps X from working
on the Intel Tiger box.
- The current kernel allows UC mmap of the 0-1MB region of
/sys/.../legacy_mem even when the chipset doesn't support UC
access. This causes an MCA when starting X on HP rx7620 and rx8620
boxes in the default configuration.
There's more detail in the Documentation/ia64/aliasing.txt file this
adds, but the general idea is that if a region might be covered by
a granule-sized kernel identity mapping, any access via /dev/mem or
mmap must use the same attribute as the identity mapping.
Otherwise, we fall back to using an attribute that is supported
according to the EFI memory map, or to using UC if the EFI memory
map doesn't mention the region.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Almost all users of the table addresses from the EFI system table want
physical addresses. So rather than doing the pa->va->pa conversion, just keep
physical addresses in struct efi.
This fixes a DMI bug: the efi structure contained the physical SMBIOS address
on x86 but the virtual address on ia64, so dmi_scan_machine() used ioremap()
on a virtual address on ia64.
This is essentially the same as an earlier patch by Matt Tolentino:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112130292316281&w=2
except that this changes all table addresses, not just ACPI addresses.
Matt's original patch was backed out because it caused MCAs on HP sx1000
systems. That problem is resolved by the ioremap() attribute checking added
for ia64.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Andi Kleen <ak@muc.de>
Acked-by: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Pass the size, not a pointer to the size, to efi_mem_attribute_range().
This function validates memory regions for the /dev/mem read/write/mmap paths.
The pointer allows arches to reduce the size of the range, but I think that's
unnecessary complexity. Simplifying it will let me use
efi_mem_attribute_range() to improve the ia64 ioremap() implementation.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: Andi Kleen <ak@muc.de>
Acked-by: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The memory descriptors that comprise the EFI memory map are not fixed in
stone such that the size could change in the future. This uses the memory
descriptor size obtained from EFI to iterate over the memory map entries
during boot. This enables the removal of an x86 specific pad (and ifdef)
in the EFI header. I also couldn't stomach the broken up nature of the
function to put EFI runtime calls into virtual mode any longer so I fixed
that up a bit as well.
For reference, this patch only impacts x86.
Signed-off-by: Matt Tolentino <matthew.e.tolentino@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
warning when building with gcc -W :
include/linux/efi.h: In function `efi_range_is_wc':
include/linux/efi.h:320: warning: comparison between signed and unsigned
It looks to me like a significantly large 'len' passed in could cause the
loop to never end. Isn't it safer to make 'i' an unsigned long as well?
Like this little patch below (which of course also kills the warning) :
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
This is a megarollup of ~60 patches which give various things static scope.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch cleans up the per-CPU MCA mess with the following changes
(and yields a UP kernel that actually boots again):
- In percpu.h, make per_cpu_init() a function-call even for the
UP case.
- In contig.c, enable per_cpu_init() even for UP since we need to
allocate the per-CPU MCA data in that case as well.
- Move the MCA-related stuff out of the cpuinfo structure into
per-CPU variables defined by mca.c.
- Rename IA64_KR_PA_CPU_INFO to IA64_KR_PER_CPU_DATA, since it really
is a per-CPU pointer now.
- In mca.h, move IA64_MCA_STACK_SIZE early enough so it gets defined
for assembly-code, too. Tidy up struct ia64_mca_struct. Add declaration
of ia64_mca_cpu_init().
- In mca_asm.[hS], replace various GET_*() macros with a single
GET_PERCPU_ADDR() which loads the physical address of an
arbitrary per-CPU variable. Remove all dependencies on the
layout of the cpuinfo structure. Replace hardcoded stack-size
with IA64_MCA_STACK_SIZE constant. Replace hardcoded references
to ar.k3 with IA64_KR(PER_CPU_DATA).
- In setup.c:cpu_init(), initialize ar.k3 to be the physical equivalent
of the per-CPU data pointer.
- Nuke silly ia64_mca_cpu_t typedef and just use struct ia64_mca_cpu instead.
- Move __per_cpu_mca[] from setup.c to mca.c.
- Rename set_mca_pointer() to ia64_mca_cpu_init() and sanitize it.
- Rename efi.c:pal_code_memdesc() to efi_get_pal_addr() and make it
return the PAL address, rather than a memory-descriptor.
- Make efi_map_pal_code() use efi_get_pal_addr().
Signed-off-by: David Mosberger-Tang <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
Ok, here you go Tony. This one fixes the loop and also fixes drm_vm.c. All
of the bits aside from the efi.h bit are ia64 specific (either under
arch/ia64 or __ia64__), so your tree is probably the right place for all of
it.
This patch adds efi_range_is_wc() to efi.h. It's used to determine whether an
address range can be mapped with the write coalescing attribute. It also
fixes up some ia64 specific callers to use the new routine instead of
unconditionally calling pgprot_writecombined, which can be dangerous if used
on ranges that don't support it.
Signed-off-by: Jesse Barnes <jbarnes@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
|
|
This changes the HCDP/PCDP support to use the early uart console
rather than using early_serial_setup().
As a consequence, ia64 serial device names will now stay constant
regardless of firmware console settings. (A serial device selected as
an EFI console device on HP ia64 boxes used to automatically become
ttyS0.)
This also removes the ia64 early-boot kludge of assuming legacy COM
ports at 0x3f8 and 0x2f8. For boxes that have legacy ports but no
HCDP, "console=ttyS0" will still work, but the console won't start
working until after the serial driver initializes and discovers the
devices.
WARNING:
If you have an HP machine and you're using the MP serial console port
(the connector labelled "console" on the 3-headed cable), this patch
will break your console!
HOW TO FIX IT:
1) The console device will change from /dev/ttyS0 to /dev/ttyS1,
ttyS2, or ttyS3, so:
1a) Edit /etc/inittab to add a getty entry for
/dev/ttyS1 (rx4640, rx5670, rx7620, rx8620, Superdome),
/dev/ttyS2 (rx1600), or
/dev/ttyS3 (rx2600).
1b) Edit /etc/securetty to add ttyS1, ttyS2, or ttyS3.
1c) Leave the existing ttyS0 entries in /etc/inittab and
/etc/securetty so you can still boot old kernels.
2) Edit /etc/elilo.conf to remove any "console=" arguments (see [1]).
3) Run elilo to install the bootloader with new configuration.
4) Reboot and use the EFI boot option maintenance menu to select
exactly one device for console output, input, and standard error.
Then do a cold reset so the changes take effect.
For the MP console, be careful to select the device with
"Acpi(HWP0002,700)/Pci(...)/Uart" in the path (see [2]).
DETAILS:
- Prior to this patch, serial device names depended on the HCDP,
which in turn depends on EFI console settings. After this patch,
the naming always stays the same, regardless of firmware settings.
For example, an rx1600 with a single built-in serial port plus
an MP has these ports:
Old Old
MMIO (EFI console (EFI console
address on builtin) on MP port) New
========== ========== ========== ======
builtin 0xff5e0000 ttyS0 ttyS1 ttyS0
MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1
MP Console 0xf8030000 ttyS2 ttyS0 ttyS2
MP 2 0xf8030010 ttyS3 ttyS3 ttyS3
MP 3 0xf8030038 ttyS4 ttyS4 ttyS4
- If you want to have multiple devices in the EFI console path, you
can, but Linux won't be able to deduce which console to use, so it
will default to using VGA. You can use "console=hcdp" (the UART
device from the EFI path) or "console=ttyS<n>" to select the
device directly.
TROUBLESHOOTING:
- No kernel output after "Uncompressing Linux... done":
-> You're using an MP port as the console and specified
"console=ttyS0". This port is now named something else.
Remove the "console=" option.
-> Multiple UARTs selected as EFI console devices, and you're
looking at the wrong one. Make sure only one UART is
selected (use the EFI Boot Manager "Boot option maintenance"
menu).
-> You're physically connected to the MP port but have a
non-MP UART selected as EFI console device. Either move
the console cable to the non-MP UART, or change the EFI
console path to the MP UART (the MP UART is the one with
"Acpi(HWP0002,700)/Pci(...)/Uart" in it.)
- Long pause (60+ seconds) between "Uncompressing Linux... done"
and start of kernel output:
-> No early console, probably because you used "console=ttyS<n>".
Remove the "console=" option.
- Kernel and init script output works fine, but no "login:" prompt:
-> Add getty entry to /etc/inittab for console tty. Use the table
in (1a) above or look for the "Adding console on ttyS<n>" message
that tells you which device is the console.
- "login:" prompt, but can't login as root:
-> Add entry to /etc/securetty for console tty.
[1] When the EFI console path contains exactly one device (either
serial or VGA), 2.6.6 and newer kernels default to that device
automatically. So if you remove "console=" arguments, you can use
the same elilo configuration to boot any 2.6.6 or newer kernel
with or without this patch.
If you need to boot kernels older than 2.6.6 (including RHEL3 and
SLES9), keep an 'append="console=ttyS0"' line in those elilo.conf
stanzas.
Non-HP machines will still need "console=" for serial consoles
because they don't supply the HCDP table.
[2] The HP management card (MP) causes confusion because it is always
active as an EFI console, even if it doesn't appear in the EFI
console path. If your console path is set to a non-MP UART, and
you happen to be attached to the MP UART, everything works in EFI,
but the kernel will think the non-MP UART is the console, so you
won't see any kernel output.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
efi.h declares a function type, and then uses that as an argument to
another function, and expects the compiler to magically demote the
function to a function pointer.
Even a gcc person (rth) was surprised that this was legal, and it
doesn't match any other use of a function pointer in the kernel, and
sparse doesn't like the implicit type-conversion.
So make the type sane in the first place, instead of depending on
a very weird corner case of the C language.
|
|
Add support for the EFI/DIG PCDP console discovery table (see
http://www.dig64.org/specifications/DIG64_HCDPv20_042804.pdf).
This moves the code from drivers/serial/8250_hcdp.[ch] to
drivers/firmware/pcdp.[ch], since it's no longer 8250-specific. It also
obsoletes CONFIG_SERIAL_8250_HCDP, replacing it with CONFIG_EFI_PCDP (which
defaults to Y for ia64).
In a nutshell, HCDP tells us "these UARTs are available for use as a
console," and it's up to the user to explicitly specify the console device.
The kernel can guess in some cases, but not all.
The PCDP (aka HCDP v2) tells us what we really want to know, namely, "this
UART or VGA device is the console device." (It also has provision for
support for new device types.)
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
The /proc support for efi 'stuff' isn't used/needed anymore, yet the
efi_dir declaration remains. This removes it.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Patch from Bjorn Helgaas
This adds efi_uart_console_only() so we can default to using a serial
console if the EFI console path only contains UARTs.
|
|
From: Andi Kleen <ak@muc.de>
Just many more warning fixes for a gcc 3.4 snapshot.
It warns for a lot of things now, e.g. for ?: and ({ ... }) and casts as
lvalues. And for functions marked inline in headers, but no body.
Actually there are more warnings, i stopped fixing at some point. Some of
the warnings seem to be dubious (e.g. the binfmt_elf.c one, which looks
more like a compiler bug to me)
I also fixed the _exit() prototype to be void because gcc was complaining
about this.
|
|
From: David Mosberger <davidm@napali.hpl.hp.com>
There is some EFI-related code which is present in the ia64 build but is not
needed: variable efi_enabled is always zero.
The patch fiddles with the efi_enabled definition to arrange for
`efi_enabled' to be constant zero or constant one in those situations where
this can be guaranteed.
|
|
From: Jesper Juhl <juhl-lkml@dif.dk>
I'm compiling 2.6.1-rc1-mm1 with "-W -Wall" to look for potential problems
and minor stuff to clean up.
One of the things that enabling the extra warnings turn up is errors about
the placement of the inline keyword.
|
|
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
Attached is a patch that enables EFI boot-up support in ia32 kernels.
In order to continue to determine whether the kernel should initialize using
EFI tables, I've temporarily added a check on the LOADER_TYPE boot parameter.
Although I haven't requested that elilo be assigned an id for this yet, I've
used this to determine whether the kernel should use the EFI initialization
path as well as a check to see if the EFI_SYSTAB boot parameter contains
anything. If someone has a better suggestion for determining this, I'm
open...
This patch also uses the existing ioremapping functions to map the efi tables
into kernel virtual address space. I've added an option such that I could
use Dave Hansen's boot_ioremap() before paging_init(). After paging_init, I
then remap the efi memmap using bt_ioremap for use later. This has
eliminated the need for several functions...thanks for the suggestions and
thanks for your help Dave. Still this could use a look-see.
|
|
From Matt Tolentino:
Here's a small patch to change several data types from u64 to
unsigned long in efi.h. These changes enable the use of the
same data structures and function prototypes for ia32 EFI kernels.
|
|
|
|
It makes no sense to keep efi.h as an ia64-specific header (there really
are x86 machines coming out with optional EFI BIOS support).
|
