Skip to content

L
linux

xiphi1978 / linux

通知 2
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 24 7月, 2010 1 次提交
    • G
      of: Merge of_platform_bus_type with platform_bus_type · eca39301
      由 Grant Likely 提交于 
      of_platform_bus was being used in the same manner as the platform_bus.
The only difference being that of_platform_bus devices are generated
from data in the device tree, and platform_bus devices are usually
statically allocated in platform code.  Having them separate causes
the problem of device drivers having to be registered twice if it
was possible for the same device to appear on either bus.

This patch removes of_platform_bus_type and registers all of_platform
bus devices and drivers on the platform bus instead.  A previous patch
made the of_device structure an alias for the platform_device structure,
and a shim is used to adapt of_platform_drivers to the platform bus.

After all of of_platform_bus drivers are converted to be normal platform
drivers, the shim code can be removed.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NDavid S. Miller <davem@davemloft.net>
      eca39301
  3. 22 7月, 2010 2 次提交
  5. 21 7月, 2010 2 次提交
    • D
      Input: twl40300-keypad - fix handling of "all ground" rows · 3fea6026
      由 Dmitry Torokhov 提交于 
      The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c)
defines a key map for the matrix keypad keyboard. The hardware seems to
use all of the 8 rows and 8 columns of the keypad, although not all
possible locations are used.

The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys
are defined with a row and column number between 0 and 7, except

        KEY(0xff, 2, KEY_F9),
        KEY(0xff, 4, KEY_F10),
        KEY(0xff, 5, KEY_F11),

which represent keycodes that should be emitted when entire row is
connected to the ground.  since the driver handles this case as if we
had an extra column in the key matrix. Unfortunately we do not allocate
enough space and end up owerwriting some random memory.
Reported-and-tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@kernel.org
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      3fea6026
    • Y
      x86, numa: fix boot without RAM on node0 again · 9aebbdb6
      由 Yinghai Lu 提交于 
      Commit e534c7c5 ("numa: x86_64: use generic percpu var
numa_node_id() implementation") broke numa systems that don't have ram
on node0 when MEMORY_HOTPLUG is enabled, because cpu_up() will call
cpu_to_node() before per_cpu(numa_node) is setup for APs.

When Node0 doesn't have RAM, on x86, cpus already round it to nearest
node with RAM in x86_cpu_to_node_map.  and per_cpu(numa_node) is not set
up until in c_init for APs.

When later cpu_up() calling cpu_to_node() will get 0 again, and make it
online even there is no RAM on node0.  so later all APs can not booted up,
and later will have panic.

[    1.611101] On node 0 totalpages: 0
.........
[    2.608558] On node 0 totalpages: 0
[    2.612065] Brought up 1 CPUs
[    2.615199] Total of 1 processors activated (3990.31 BogoMIPS).
...
   93.225341] calling  loop_init+0x0/0x1a4 @ 1
[   93.229314] PERCPU: allocation failed, size=80 align=8, failed to populate
[   93.246539] Pid: 1, comm: swapper Tainted: G        W   2.6.35-rc4-tip-yh-04371-gd64e6c4-dirty #354
[   93.264621] Call Trace:
[   93.266533]  [<ffffffff81125e43>] pcpu_alloc+0x83a/0x8e7
[   93.270710]  [<ffffffff81125f15>] __alloc_percpu+0x10/0x12
[   93.285849]  [<ffffffff8140786c>] alloc_disk_node+0x94/0x16d
[   93.291811]  [<ffffffff81407956>] alloc_disk+0x11/0x13
[   93.306157]  [<ffffffff81503e51>] loop_alloc+0xa7/0x180
[   93.310538]  [<ffffffff8277ef48>] loop_init+0x9b/0x1a4
[   93.324909]  [<ffffffff8277eead>] ? loop_init+0x0/0x1a4
[   93.329650]  [<ffffffff810001f2>] do_one_initcall+0x57/0x136
[   93.345197]  [<ffffffff827486d0>] kernel_init+0x184/0x20e
[   93.348146]  [<ffffffff81034954>] kernel_thread_helper+0x4/0x10
[   93.365194]  [<ffffffff81c7cc3c>] ? restore_args+0x0/0x30
[   93.369305]  [<ffffffff8274854c>] ? kernel_init+0x0/0x20e
[   93.386011]  [<ffffffff81034950>] ? kernel_thread_helper+0x0/0x10
[   93.392047] loop: out of memory
...

Try to assign per_cpu(numa_node) early

[akpm@linux-foundation.org: tidy up code comment]
Signed-off-by: NYinghai <yinghai@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Acked-by: NLee Schermerhorn <lee.schermerhorn@hp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9aebbdb6
  7. 19 7月, 2010 3 次提交
  9. 17 7月, 2010 3 次提交
    • J
      x86, pci, mrst: Add extra sanity check in walking the PCI extended cap chain · f82c3d71
      由 Jacob Pan 提交于 
      The fixed bar capability structure is searched in PCI extended
configuration space.  We need to make sure there is a valid capability
ID to begin with otherwise, the search code may stuck in a infinite
loop which results in boot hang.  This patch adds additional check for
cap ID 0, which is also invalid, and indicates end of chain.

End of chain is supposed to have all fields zero, but that doesn't
seem to always be the case in the field.
Suggested-by: N"H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
LKML-Reference: <1279306706-27087-1-git-send-email-jacob.jun.pan@linux.intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      f82c3d71
    • Y
      x86: Fix x2apic preenabled system with kexec · fd19dce7
      由 Yinghai Lu 提交于 
      Found one x2apic system kexec loop test failed
when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip)

first kernel can kexec second kernel, but second kernel can not kexec third one.

it can be duplicated on another system with BIOS preenabled x2apic.
First kernel can not kexec second kernel.

It turns out, when kernel boot with pre-enabled x2apic, it will not execute
disable_local_APIC on shutdown path.

when init_apic_mappings() is called in setup_arch, it will skip setting of
apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic())
Then later, disable_local_APIC() will bail out early because !apic_phys.

So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys.

another solution could be updating init_apic_mappings() to set apic_phys even
for preenabled x2apic system. Actually even for x2apic system, that lapic
address is mapped already in early stage.

BTW: is there any x2apic preenabled system with apicid of boot cpu > 255?
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
LKML-Reference: <4C3EB22B.3000701@kernel.org>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: stable@kernel.org
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      fd19dce7
    • B
      PCI: fall back to original BIOS BAR addresses · 58c84eda
      由 Bjorn Helgaas 提交于 
      If we fail to assign resources to a PCI BAR, this patch makes us try the
original address from BIOS rather than leaving it disabled.

Linux tries to make sure all PCI device BARs are inside the upstream
PCI host bridge or P2P bridge apertures, reassigning BARs if necessary.
Windows does similar reassignment.

Before this patch, if we could not move a BAR into an aperture, we left
the resource unassigned, i.e., at address zero.  Windows leaves such BARs
at the original BIOS addresses, and this patch makes Linux do the same.

This is a bit ugly because we disable the resource long before we try to
reassign it, so we have to keep track of the BIOS BAR address somewhere.
For lack of a better place, I put it in the struct pci_dev.

I think it would be cleaner to attempt the assignment immediately when the
claim fails, so we could easily remember the original address.  But we
currently claim motherboard resources in the middle, after attempting to
claim PCI resources and before assigning new PCI resources, and changing
that is a fairly big job.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16263Reported-by: NAndrew <nitr0@seti.kr.ua>
Tested-by: NAndrew <nitr0@seti.kr.ua>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      58c84eda
  11. 15 7月, 2010 4 次提交
  13. 14 7月, 2010 1 次提交
  15. 13 7月, 2010 2 次提交
  17. 12 7月, 2010 4 次提交
    • M
      powerpc/fsl-booke: Fix address issue when using relocatable kernels · 77154a20
      由 Matthew McClintock 提交于 
      When booting a relocatable kernel it needs to jump to the correct
start address, which for BookE parts is usually unchanged
regardless of the physical memory offset.

Recent changes cause problems with how we calculate the start
address, it was always adding the RMO into the start address
which is incorrect. This patch only adds in the RMO offset
if we are in the kexec code path, as it needs the RMO to work
correctly.

Instead of adding the RMO offset in in the common code path, we
can just set r6 to the RMO offset in the kexec code path instead
of to zero, and finally perform the masking in the common code
path
Signed-off-by: NMatthew McClintock <msm@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      77154a20
    • A
      powerpc/cpm1: Mark micropatch code/data static and __init · af71bcfe
      由 Anton Vorontsov 提交于 
      This saves runtime memory and fixes lots of sparse warnings like this:

    CHECK   arch/powerpc/sysdev/micropatch.c
  arch/powerpc/sysdev/micropatch.c:27:6: warning: symbol 'patch_2000'
  was not declared. Should it be static?
  arch/powerpc/sysdev/micropatch.c:146:6: warning: symbol 'patch_2f00'
  was not declared. Should it be static?
  ...
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      af71bcfe
    • A
      powerpc/cpm1: Fix build with various CONFIG_*_UCODE_PATCH combinations · 2069a6ae
      由 Anton Vorontsov 提交于 
      Warnings are treated as errors for arch/powerpc code, so build fails
with CONFIG_I2C_SPI_UCODE_PATCH=y:

    CC      arch/powerpc/sysdev/micropatch.o
  cc1: warnings being treated as errors
  arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
  arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
  make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1

And with CONFIG_USB_SOF_UCODE_PATCH=y:

  CC      arch/powerpc/sysdev/micropatch.o
  cc1: warnings being treated as errors
  arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
  arch/powerpc/sysdev/micropatch.c:629: warning: unused variable 'spp'
  arch/powerpc/sysdev/micropatch.c:628: warning: unused variable 'iip'
  make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1

This patch fixes these issues by introducing proper #ifdefs.

Cc: <stable@kernel.org> [ .33, .34 ]
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      2069a6ae
    • A
      powerpc/cpm: Reintroduce global spi_pram struct (fixes build issue) · 56825c88
      由 Anton Vorontsov 提交于 
      spi_t was removed in commit 644b2a68
("powerpc/cpm: Remove SPI defines and spi structs"), the commit assumed
that spi_t isn't used anywhere outside of the spi_mpc8xxx driver. But
it appears that the struct is needed for micropatch code. So, let's
reintroduce the struct.

Fixes the following build issue:

    CC      arch/powerpc/sysdev/micropatch.o
  micropatch.c: In function 'cpm_load_patch':
  micropatch.c:629: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
  micropatch.c:629: error: 'spp' undeclared (first use in this function)
  micropatch.c:629: error: (Each undeclared identifier is reported only once
  micropatch.c:629: error: for each function it appears in.)
Reported-by: NLEROY Christophe <christophe.leroy@c-s.fr>
Reported-by: NTony Breeds <tony@bakeyournoodle.com>
Cc: <stable@kernel.org> [ .33, .34 ]
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      56825c88
  19. 10 7月, 2010 1 次提交
    • R
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      由 Russell King 提交于 
      CPU: Testing write buffer coherency: ok
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
Modules linked in:
[<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
[<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
[<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
[<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
[<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
[<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
[<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
[<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
[<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1c ]---
possible reason: unannotated irqs-on.
irq event stamp: 3
hardirqs last  enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
softirqs last  enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
softirqs last disabled at (0): [<(null)>] (null)

Fix this by ensuring that the lockdep interrupt state is manipulated in
the appropriate places.  We essentially treat userspace as an entirely
separate environment which isn't relevant to lockdep (lockdep doesn't
monitor userspace.)  We don't tell lockdep that IRQs will be enabled
in that environment.

Instead, when creating kernel threads (which is a rare event compared
to entering/leaving userspace) we have to update the lockdep state.  Do
this by starting threads with IRQs disabled, and in the kthread helper,
tell lockdep that IRQs are enabled, and enable them.

This provides lockdep with a consistent view of the current IRQ state
in kernel space.

This also revert portions of 0d928b0b
which didn't fix the problem.
Tested-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ac78884e
  21. 09 7月, 2010 4 次提交
    • L
      ARM: 6184/2: ux500: use neutral PRCMU base · d9e38040
      由 Linus Walleij 提交于 
      The MTU wallclock timing fix-up patch was hardwired to the DB8500
causing a regression. This makes it work on the DB5500 as well.
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d9e38040
    • W
      ARM: 6212/1: atomic ops: add memory constraints to inline asm · 398aa668
      由 Will Deacon 提交于 
      Currently, the 32-bit and 64-bit atomic operations on ARM do not
include memory constraints in the inline assembly blocks. In the
case of barrier-less operations [for example, atomic_add], this
means that the compiler may constant fold values which have actually
been modified by a call to an atomic operation.

This issue can be observed in the atomic64_test routine in
<kernel root>/lib/atomic64_test.c:

00000000 <test_atomic64>:
   0:	e1a0c00d 	mov	ip, sp
   4:	e92dd830 	push	{r4, r5, fp, ip, lr, pc}
   8:	e24cb004 	sub	fp, ip, #4
   c:	e24dd008 	sub	sp, sp, #8
  10:	e24b3014 	sub	r3, fp, #20
  14:	e30d000d 	movw	r0, #53261	; 0xd00d
  18:	e3011337 	movw	r1, #4919	; 0x1337
  1c:	e34c0001 	movt	r0, #49153	; 0xc001
  20:	e34a1aa3 	movt	r1, #43683	; 0xaaa3
  24:	e16300f8 	strd	r0, [r3, #-8]!
  28:	e30c0afe 	movw	r0, #51966	; 0xcafe
  2c:	e30b1eef 	movw	r1, #48879	; 0xbeef
  30:	e34d0eaf 	movt	r0, #57007	; 0xdeaf
  34:	e34d1ead 	movt	r1, #57005	; 0xdead
  38:	e1b34f9f 	ldrexd	r4, [r3]
  3c:	e1a34f90 	strexd	r4, r0, [r3]
  40:	e3340000 	teq	r4, #0
  44:	1afffffb 	bne	38 <test_atomic64+0x38>
  48:	e59f0004 	ldr	r0, [pc, #4]	; 54 <test_atomic64+0x54>
  4c:	e3a0101e 	mov	r1, #30
  50:	ebfffffe 	bl	0 <__bug>
  54:	00000000 	.word	0x00000000

The atomic64_set (0x38-0x44) writes to the atomic64_t, but the
compiler doesn't see this, assumes the test condition is always
false and generates an unconditional branch to __bug. The rest of the
test is optimised away.

This patch adds suitable memory constraints to the atomic operations on ARM
to ensure that the compiler is informed of the correct data hazards. We have
to use the "Qo" constraints to avoid hitting the GCC anomaly described at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492 , where the compiler
makes assumptions about the writeback in the addressing mode used by the
inline assembly. These constraints forbid the use of auto{inc,dec} addressing
modes, so it doesn't matter if we don't use the operand exactly once.

Cc: stable@kernel.org
Reviewed-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      398aa668
    • W
      ARM: 6211/1: atomic ops: fix register constraints for atomic64_add_unless · 068de8d1
      由 Will Deacon 提交于 
      The atomic64_add_unless function compares an atomic variable with
a given value and, if they are not equal, adds another given value
to the atomic variable. The function returns zero if the addition
did not occur and non-zero otherwise.

On ARM, the return value is initialised to 1 in C code. Inline assembly
code then performs the atomic64_add_unless operation, setting the
return value to 0 iff the addition does not occur. This means that
when the addition *does* occur, the value of ret must be preserved
across the inline assembly and therefore requires a "+r" constraint
rather than the current one of "=&r".

Thanks to Nicolas Pitre for helping to spot this.

Cc: stable@kernel.org
Reviewed-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      068de8d1
    • S
      ARM: 6210/1: Do not rely on reset defaults of L2X0_AUX_CTRL · 4082cfa7
      由 Sascha Hauer 提交于 
      On i.MX35 the L2X0_AUX_CTRL register does not have sensible reset
default values. Allow them to be overwritten with the aux_val/aux_mask
arguments passed to l2x0_init().
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4082cfa7
  23. 08 7月, 2010 13 次提交