Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 1月, 2011 11 次提交
  3. 06 1月, 2011 1 次提交
    • G
      m68k/sun3: Kill pte_unmap() warnings · 0eefed84
      由 Geert Uytterhoeven 提交于 
      Since commit 31c91132 ("mm: check the argument
of kunmap on architectures without highmem"), we get lots of warnings like

arch/m68k/kernel/sys_m68k.c:508: warning: passing argument 1 of ‘kunmap’ from incompatible pointer type

As m68k doesn't support highmem anyway, open code the calls to kmap() and
kunmap() (the latter is a no-op) to kill the warnings, like is done on most
other architectures without CONFIG_HIGHPTE.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Sam Creasey <sammy@sammy.net>
      0eefed84
  5. 04 1月, 2011 1 次提交
  7. 03 1月, 2011 5 次提交
    • A
      ARM: pxa: fix page table corruption on resume · 24c78557
      由 Aric D. Blumer 提交于 
      Before this patch, the following error would sometimes occur after a
resume on pxa3xx:

    /path/to/mm/memory.c:144: bad pmd 8040542e.

The problem was that a temporary page table mapping was being improperly
restored.

The PXA3xx resume code creates a temporary mapping of resume_turn_on_mmu
to avoid a prefetch abort.  The pxa3xx_resume_after_mmu code requires
that the r1 register holding the address of this mapping not be
modified, however, resume_turn_on_mmu does modify it. It is mostly
correct in that r1 receives the base table address, but it may also
get other bits in 13:0.  This results in pxa3xx_resume_after_mmu
restoring the original mapping to the wrong place, corrupting memory
and leaving the temporary mapping in place.
Signed-off-by: NMatt Reimer <mreimer@sdgsystems.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      24c78557
    • M
      ARM: it8152: add IT8152_LAST_IRQ definition to fix build error · 823a2df2
      由 Mike Rapoport 提交于 
      The commit 6ac6b817 (ARM: pxa: encode
IRQ number into .nr_irqs) removed definition of ITE_LAST_IRQ which
caused the following build error:

CC      arch/arm/common/it8152.o
arch/arm/common/it8152.c: In function 'it8152_init_irq':
arch/arm/common/it8152.c:86: error: 'IT8152_LAST_IRQ' undeclared (first use in this function)
arch/arm/common/it8152.c:86: error: (Each undeclared identifier is reported only once
arch/arm/common/it8152.c:86: error: for each function it appears in.)
make[2]: *** [arch/arm/common/it8152.o] Error 1

Defining the IT8152_LAST_IRQ in the arch/arm/include/hardware/it8152.c
fixes the build.
Signed-off-by: NMike Rapoport <mike@compulab.co.il>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      823a2df2
    • L
      ARM: pxa: PXA_ESERIES depends on FB_W100. · 82427de2
      由 Lennert Buytenhek 提交于 
      As arch/arm/mach-pxa/eseries.c references w100fb_gpio_{read,write}()
directly.
Signed-off-by: NLennert Buytenhek <buytenh@secretlab.ca>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      82427de2
    • R
      arch/x86/oprofile/op_model_amd.c: Perform initialisation on a single CPU · c7c25802
      由 Robert Richter 提交于 
      Disable preemption in init_ibs(). The function only checks the
ibs capabilities and sets up pci devices (if necessary). It runs
only on one cpu but operates with the local APIC and some MSRs,
thus it is better to disable preemption.

[    7.034377] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/483
[    7.034385] caller is setup_APIC_eilvt+0x155/0x180
[    7.034389] Pid: 483, comm: modprobe Not tainted 2.6.37-rc1-20101110+ #1
[    7.034392] Call Trace:
[    7.034400]  [<ffffffff812a2b72>] debug_smp_processor_id+0xd2/0xf0
[    7.034404]  [<ffffffff8101e985>] setup_APIC_eilvt+0x155/0x180
[ ... ]

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22812

Reported-by: <atswartz@gmail.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Cc: oprofile-list@lists.sourceforge.net <oprofile-list@lists.sourceforge.net>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>         [2.6.37.x]
LKML-Reference: <20110103111514.GM4739@erda.amd.com>
[ small cleanups ]
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7c25802
    • A
      ARM: 6605/1: Add missing include "asm/memory.h" · 7c0ab43e
      由 Axel Lin 提交于 
      This patch fixes below build error by adding the missing asm/memory.h,
which is needed for arch_is_coherent().

$ make pxa3xx_defconfig; make
  CC      init/do_mounts_rd.o
In file included from include/linux/list_bl.h:5,
                 from include/linux/rculist_bl.h:7,
                 from include/linux/dcache.h:7,
                 from include/linux/fs.h:381,
                 from init/do_mounts_rd.c:3:
include/linux/bit_spinlock.h: In function 'bit_spin_unlock':
include/linux/bit_spinlock.h:61: error: implicit declaration of function 'arch_is_coherent'
make[1]: *** [init/do_mounts_rd.o] Error 1
make: *** [init] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NPeter Huewe <peterhuewe@gmx.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7c0ab43e
  9. 02 1月, 2011 1 次提交
  11. 29 12月, 2010 2 次提交
  13. 27 12月, 2010 1 次提交
    • J
      x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree() · 5cdd2de0
      由 Jesper Juhl 提交于 
      In arch/x86/kernel/microcode_intel.c::generic_load_microcode()
we have  this:

	while (leftover) {
		...
		if (get_ucode_data(mc, ucode_ptr, mc_size) ||
		    microcode_sanity_check(mc) < 0) {
			vfree(mc);
			break;
		}
		...
	}

	if (mc)
		vfree(mc);

This will cause a double free of 'mc'. This patch fixes that by
just  removing the vfree() call in the loop since 'mc' will be
freed nicely just  after we break out of the loop.

There's also a second change in the patch. I noticed a lot of
checks for  pointers being NULL before passing them to vfree().
That's completely  redundant since vfree() deals gracefully with
being passed a NULL pointer.  Removing the redundant checks
yields a nice size decrease for the object  file.

Size before the patch:
   text    data     bss     dec     hex filename
   4578     240    1032    5850    16da arch/x86/kernel/microcode_intel.o
Size after the patch:
   text    data     bss     dec     hex filename
   4489     240     984    5713    1651 arch/x86/kernel/microcode_intel.o
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Acked-by: NTigran Aivazian <tigran@aivazian.fsnet.co.uk>
Cc: Shaohua Li <shaohua.li@intel.com>
LKML-Reference: <alpine.LNX.2.00.1012251946100.10759@swampdragon.chaosbits.net>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cdd2de0
  15. 24 12月, 2010 6 次提交
  17. 22 12月, 2010 1 次提交
  19. 21 12月, 2010 1 次提交
  21. 20 12月, 2010 3 次提交
    • N
      ARM: fix cache-feroceon-l2 after stack based kmap_atomic() · 6d3e6d36
      由 Nicolas Pitre 提交于 
      Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is actively
wrong to rely on fixed kmap type indices (namely KM_L2_CACHE) as
kmap_atomic() totally ignores them and a concurrent instance of it may
happily reuse any slot for any purpose.  Because kmap_atomic() is now
able to deal with reentrancy, we can get rid of the ad hoc mapping here.

While the code is made much simpler, there is a needless cache flush
introduced by the usage of __kunmap_atomic().  It is not clear if the
performance difference to remove that is worth the cost in code
maintenance (I don't think there are that many highmem users on that
platform anyway) but that should be reconsidered when/if someone cares
enough to do some measurements.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      6d3e6d36
    • N
      ARM: fix cache-xsc3l2 after stack based kmap_atomic() · 25cbe454
      由 Nicolas Pitre 提交于 
      Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is actively
wrong to rely on fixed kmap type indices (namely KM_L2_CACHE) as
kmap_atomic() totally ignores them and a concurrent instance of it may
happily reuse any slot for any purpose.  Because kmap_atomic() is now
able to deal with reentrancy, we can get rid of the ad hoc mapping here,
and we even don't have to disable IRQs anymore (highmem case).

While the code is made much simpler, there is a needless cache flush
introduced by the usage of __kunmap_atomic().  It is not clear if the
performance difference to remove that is worth the cost in code
maintenance (I don't think there are that many highmem users on that
platform if at all anyway).
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      25cbe454
    • N
      ARM: get rid of kmap_high_l1_vipt() · 39af22a7
      由 Nicolas Pitre 提交于 
      Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is no longer
necessary to carry an ad hoc version of kmap_atomic() added in commit
7e5a69e8 "ARM: 6007/1: fix highmem with VIPT cache and DMA" to cope
with reentrancy.

In fact, it is now actively wrong to rely on fixed kmap type indices
(namely KM_L1_CACHE) as kmap_atomic() totally ignores them now and a
concurrent instance of it may reuse any slot for any purpose.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      39af22a7
  23. 18 12月, 2010 7 次提交
    • R
      ARM: smp: avoid incrementing mm_users on CPU startup · 1ae1b5f0
      由 Russell King 提交于 
      We should not be incrementing mm_users when we startup a secondary
CPU - doing so results in mm_users incrementing by one each time we
hotplug a CPU, which will eventually wrap, and will cause problems.

Other architectures such as x86 do not increment mm_users, but only
mm_count, so we follow that pattern.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1ae1b5f0
    • H
      x86, kexec: Limit the crashkernel address appropriately · 7f8595bf
      由 H. Peter Anvin 提交于 
      Keep the crash kernel address below 512 MiB for 32 bits and 896 MiB
for 64 bits.  For 32 bits, this retains compatibility with earlier
kernel releases, and makes it work even if the vmalloc= setting is
adjusted.

For 64 bits, we should be able to increase this substantially once a
hard-coded limit in kexec-tools is fixed.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20101217195035.GE14502@redhat.com>
      7f8595bf
    • C
      arch/tile: handle rt_sigreturn() more cleanly · 81711cee
      由 Chris Metcalf 提交于 
      The current tile rt_sigreturn() syscall pattern uses the common idiom
of loading up pt_regs with all the saved registers from the time of
the signal, then anticipating the fact that we will clobber the ABI
"return value" register (r0) as we return from the syscall by setting
the rt_sigreturn return value to whatever random value was in the pt_regs
for r0.

However, this breaks in our 64-bit kernel when running "compat" tasks,
since we always sign-extend the "return value" register to properly
handle returned pointers that are in the upper 2GB of the 32-bit compat
address space.  Doing this to the sigreturn path then causes occasional
random corruption of the 64-bit r0 register.

Instead, we stop doing the crazy "load the return-value register"
hack in sigreturn.  We already have some sigreturn-specific assembly
code that we use to pass the pt_regs pointer to C code.  We extend that
code to also set the link register to point to a spot a few instructions
after the usual syscall return address so we don't clobber the saved r0.
Now it no longer matters what the rt_sigreturn syscall returns, and the
pt_regs structure can be cleanly and completely reloaded.
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      81711cee
    • C
      arch/tile: handle CLONE_SETTLS in copy_thread(), not user space · bc4cf2bb
      由 Chris Metcalf 提交于 
      Previously we were just setting up the "tp" register in the
new task as started by clone() in libc.  However, this is not
quite right, since in principle a signal might be delivered to
the new task before it had its TLS set up.  (Of course, this race
window still exists for resetting the libc getpid() cached value
in the new task, in principle.  But in any case, we are now doing
this exactly the way all other architectures do it.)

This change is important for 2.6.37 since the tile glibc we will
be submitting upstream will not set TLS in user space any more,
so it will only work on a kernel that has this fix.  It should
also be taken for 2.6.36.x in the stable tree if possible.
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
Cc: stable <stable@kernel.org>
      bc4cf2bb
    • K
      MIPS: Fix build errors in sc-mips.c · 081d835f
      由 Kevin Cernekee 提交于 
      Seen with malta_defconfig on Linus' tree:

  CC      arch/mips/mm/sc-mips.o
arch/mips/mm/sc-mips.c: In function 'mips_sc_is_activated':
arch/mips/mm/sc-mips.c:77: error: 'config2' undeclared (first use in this function)
arch/mips/mm/sc-mips.c:77: error: (Each undeclared identifier is reported only once
arch/mips/mm/sc-mips.c:77: error: for each function it appears in.)
arch/mips/mm/sc-mips.c:81: error: 'tmp' undeclared (first use in this function)
make[2]: *** [arch/mips/mm/sc-mips.o] Error 1
make[1]: *** [arch/mips/mm] Error 2
make: *** [arch/mips] Error 2

[Ralf: Cosmetic changes to minimize the number of arguments passed to
mips_sc_is_activated]
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Patchwork: https://patchwork.linux-mips.org/patch/1752/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      081d835f
    • B
      x86: avoid high BIOS area when allocating address space · a2c606d5
      由 Bjorn Helgaas 提交于 
      This prevents allocation of the last 2MB before 4GB.

The experiment described here shows Windows 7 ignoring the last 1MB:
https://bugzilla.kernel.org/show_bug.cgi?id=23542#c27

This patch ignores the top 2MB instead of just 1MB because H. Peter Anvin
says "There will be ROM at the top of the 32-bit address space; it's a fact
of the architecture, and on at least older systems it was common to have a
shadow 1 MiB below."
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a2c606d5
    • B
      x86: avoid E820 regions when allocating address space · 4dc2287c
      由 Bjorn Helgaas 提交于 
      When we allocate address space, e.g., to assign it to a PCI device, don't
allocate anything mentioned in the BIOS E820 memory map.

On recent machines (2008 and newer), we assign PCI resources from the
windows described by the ACPI PCI host bridge _CRS.  On many Dell
machines, these windows overlap some E820 reserved areas, e.g.,

    BIOS-e820: 00000000bfe4dc00 - 00000000c0000000 (reserved)
    pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff]

If we put devices at 0xbff00000, they don't work, probably because
that's really RAM, not I/O memory.  This patch prevents that by removing
the 0xbfe4dc00-0xbfffffff area from the "available" resource.

I'm not very happy with this solution because Windows solves the problem
differently (it seems to ignore E820 reserved areas and it allocates
top-down instead of bottom-up; details at comment 45 of the bugzilla
below).  That means we're vulnerable to BIOS defects that Windows would not
trip over.  For example, if BIOS described a device in ACPI but didn't
mention it in E820, Windows would work fine but Linux would fail.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=16228Acked-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      4dc2287c