1. 07 8月, 2013 6 次提交
  2. 26 7月, 2013 14 次提交
  3. 17 7月, 2013 1 次提交
  4. 15 7月, 2013 1 次提交
    • P
      arm: delete __cpuinit/__CPUINIT usage from all ARM users · 8bd26e3a
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the ARM uses of the __cpuinit macros from C code,
      and all __CPUINIT from assembly code.  It also had two ".previous"
      section statements that were paired off against __CPUINIT
      (aka .section ".cpuinit.text") that also get removed here.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8bd26e3a
  5. 13 7月, 2013 2 次提交
  6. 12 7月, 2013 2 次提交
  7. 11 7月, 2013 1 次提交
  8. 10 7月, 2013 8 次提交
  9. 09 7月, 2013 4 次提交
    • R
      ARM: mm: fix boot on SA1110 Assabet · 319e0b4f
      Russell King 提交于
      Commit 83db0384 (mm/ARM: use common help functions to free reserved
      pages) broke booting on the Assabet by trying to convert a PFN to
      a virtual address using the __va() macro.  This macro takes the
      physical address, not a PFN.  Fix this.
      
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      319e0b4f
    • S
      ARM: 7781/1: mmu: Add debug_ll_io_init() mappings to early mappings · ee4de5d9
      Stephen Boyd 提交于
      Failure to add the mapping created in debug_ll_io_init() can lead
      to the BUG_ON() triggering in lib/ioremap.c:27 if the static
      virtual address decided for the debug_ll mapping overlaps with
      another mapping that is created later. This happens because the
      generic ioremap code has no idea there is a mapping there and it
      tries to place a mapping in the same location and blows up when
      it sees that there is a pte already present.
      
      kernel BUG at lib/ioremap.c:27!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc2-00042-g2af0c67-dirty #316
      task: ef088000 ti: ef082000 task.ti: ef082000
      PC is at ioremap_page_range+0x16c/0x198
      LR is at ioremap_page_range+0xf0/0x198
      pc : [<c04cb874>]    lr : [<c04cb7f8>]    psr: 20000113
      sp : ef083e78  ip : af140000  fp : ef083ebc
      r10: ef7fc100  r9 : ef7fc104  r8 : 000af174
      r7 : 00000647  r6 : beffffff  r5 : f004c000  r4 : f0040000
      r3 : af173417  r2 : 16440653  r1 : af173e07  r0 : ef7fc8fc
      Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5787d  Table: 8020406a  DAC: 00000015
      Process swapper/0 (pid: 1, stack limit = 0xef082238)
      Stack: (0xef083e78 to 0xef084000)
      3e60:                                                       00040000 ef083eec
      3e80: bf134000 f004bfff c0207c00 f004c000 c02fc120 f000c000 c15e7800 00040000
      3ea0: ef083eec 00000647 c098ba9c c0953544 ef083edc ef083ec0 c021b82c c04cb714
      3ec0: c09cdc50 00000040 ef0f1e00 ef1003c0 ef083f14 ef083ee0 c09535bc c021b7bc
      3ee0: c0953544 c04d0c6c c094e2cc c1600be4 c07440c4 c09a6888 00000002 c0a15f00
      3f00: ef082000 00000000 ef083f54 ef083f18 c0208728 c0953550 00000002 c1600bfc
      3f20: c08e3fac c0839918 ef083f54 c1600b80 c09a6888 c0a15f00 0000008b c094e2cc
      3f40: c098ba9c c098bab8 ef083f94 ef083f58 c094ea0c c020865c 00000002 00000002
      3f60: c094e2cc 00000000 c025b674 00000000 c06ff860 00000000 00000000 00000000
      3f80: 00000000 00000000 ef083fac ef083f98 c06ff878 c094e910 00000000 00000000
      3fa0: 00000000 ef083fb0 c020efe8 c06ff86c 00000000 00000000 00000000 00000000
      3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 c0595108
      [<c04cb874>] (ioremap_page_range+0x16c/0x198) from [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4)
      [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4) from [<c09535bc>] (atomic_pool_init+0x78/0x128)
      [<c09535bc>] (atomic_pool_init+0x78/0x128) from [<c0208728>] (do_one_initcall+0xd8/0x198)
      [<c0208728>] (do_one_initcall+0xd8/0x198) from [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0)
      [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0) from [<c06ff878>] (kernel_init+0x18/0xf4)
      [<c06ff878>] (kernel_init+0x18/0xf4) from [<c020efe8>] (ret_from_fork+0x14/0x20)
      Code: e50b0040 ebf54b2f e51b0040 eaffffee (e7f001f2)
      
      Fix it by telling generic layers about the static mapping via
      iotable_init().  This also has the nice side effect of letting
      you see the mapping in procfs' vmallocinfo file.
      
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ee4de5d9
    • S
      ARM: 7780/1: add missing linker section markup to head-common.S · 8c69d7af
      Stephen Warren 提交于
      Macro __INIT is used to place various code in head-common.S into the init
      section. This should be matched by a closing __FINIT. Also, add an
      explicit ".text" to ensure subsequent code is placed into the correct
      section; __FINIT is simply a closing marker to match __INIT and doesn't
      guarantee to revert to .text.
      
      This historically caused no problem, because macro __CPUINIT was used at
      the exact location where __FINIT was missing, which then placed following
      code into the cpuinit section. However, with commit 22f0a273 "init.h:
      remove __cpuinit sections from the kernel" applied, __CPUINIT becomes a
      no-op, thus leaving all this code in the init section, rather than the
      regular text section. This caused issues such as secondary CPU boot
      failures or crashes.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8c69d7af
    • O
      ARM: omap2: add select of TI_PRIV_EDMA · 9d8812df
      Olof Johansson 提交于
      "ARM: OMAP: build mach-omap code only if needed" moved around the
      ARCH_OMAP2PLUS stanza, but accidentally dropped the seleciton of
      TI_PRIV_EDMA in the process. Add it back.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      9d8812df
  10. 06 7月, 2013 1 次提交