An error occurred fetching the project authors.
  1. 11 Oct, 2013 1 commit
  2. 10 Jan, 2013 1 commit
    • Anton Blanchard's avatar
      powerpc: Build kernel with -mcmodel=medium · 1fbe9cf2
      Anton Blanchard authored
      Finally remove the two level TOC and build with -mcmodel=medium.
      
      Unfortunately we can't build modules with -mcmodel=medium due to
      the tricks the kernel module loader plays with percpu data:
      
      # -mcmodel=medium breaks modules because it uses 32bit offsets from
      # the TOC pointer to create pointers where possible. Pointers into the
      # percpu data area are created by this method.
      #
      # The kernel module loader relocates the percpu data section from the
      # original location (starting with 0xd...) to somewhere in the base
      # kernel percpu data space (starting with 0xc...). We need a full
      # 64bit relocation for this to work, hence -mcmodel=large.
      
      On older kernels we fall back to the two level TOC (-mminimal-toc)
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1fbe9cf2
  3. 24 Jul, 2011 1 commit
  4. 22 Feb, 2009 1 commit
    • Kumar Gala's avatar
      powerpc: Unify opcode definitions and support · 16c57b36
      Kumar Gala authored
      Create a new header that becomes a single location for defining PowerPC
      opcodes used by code that is either generationg instructions
      at runtime (fixups, debug, etc.), emulating instructions, or just
      compiling instructions old assemblers don't know about.
      
      We currently don't handle the floating point emulation or alignment decode
      as both are better handled by the specific decode support they already
      have.
      
      Added support for the new dcbzl, dcbal, msgsnd, tlbilx, & wait instructions
      since older assemblers don't know about them.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      16c57b36
  5. 20 Nov, 2008 1 commit
    • Steven Rostedt's avatar
      powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace · f48cb8b4
      Steven Rostedt authored
      Impact: Allow 64 bit PowerPC to trace modules with dynamic ftrace
      
      This adds code to handle the PPC64 module trampolines, and allows for
      PPC64 to use dynamic ftrace.
      
      Thanks to Paul Mackerras for these updates:
      
        - fix the mod and rec->arch.mod NULL checks.
        - fix to is_bl_op compare.
      
      Thanks to Milton Miller for:
      
        - finding the nasty race with using two nops, and recommending
          instead that I use a branch 8 forward.
      Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
      f48cb8b4
  6. 17 Sep, 2008 1 commit
  7. 09 Sep, 2008 1 commit
  8. 01 Jul, 2008 2 commits
  9. 21 Dec, 2007 1 commit
    • Emil Medve's avatar
      [POWERPC] Optimize counting distinct entries in the relocation sections · eda09fbd
      Emil Medve authored
      When a module has relocation sections with tens of thousands of
      entries, counting the distinct/unique entries only (i.e. no
      duplicates) at load time can take tens of seconds and up to minutes.
      The sore point is the count_relocs() function which is called as part
      of the architecture specific module loading processing path:
      
      	-> load_module()			generic
      	   -> module_frob_arch_sections()	arch specific
      	      -> get_plt_size()		32-bit
      	      -> get_stubs_size()	64-bit
      		 -> count_relocs()
      
      Here count_relocs is being called to find out how many distinct
      targets of R_PPC_REL24 relocations there are, since each distinct
      target needs a PLT entry or a stub created for it.
      
      The previous counting algorithm has O(n^2) complexity.  Basically two
      solutions were proposed on the e-mail list: a hash based approach and
      a sort based approach.
      
      The hash based approach is the fastest (O(n)) but the has it needs
      additional memory and for certain corner cases it could take lots of
      memory due to the degeneration of the hash.  One such proposal was
      submitted here:
      
      http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
      
      The sort based approach is slower (O(n * log n + n)) but if the
      sorting is done "in place" it doesn't need additional memory.
      This has O(n + n * log n) complexity with no additional memory
      requirements.
      
      This commit implements the in-place sort option.
      Signed-off-by: default avatarEmil Medve <Emilian.Medve@Freescale.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      eda09fbd
  10. 11 Dec, 2006 1 commit
    • Jeremy Fitzhardinge's avatar
      [POWERPC] Generic BUG for powerpc · 73c9ceab
      Jeremy Fitzhardinge authored
      This makes powerpc use the generic BUG machinery.  The biggest reports the
      function name, since it is redundant with kallsyms, and not needed in general.
      
      There is an overall reduction of code, since module_32/64 duplicated several
      functions.
      
      Unfortunately there's no way to tell gcc that BUG won't return, so the BUG
      macro includes a goto loop.  This will generate a real jmp instruction, which
      is never used.
      
      [akpm@osdl.org: build fix]
      [paulus@samba.org: remove infinite loop in BUG_ON]
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      73c9ceab
  11. 25 Oct, 2006 1 commit
  12. 28 Apr, 2006 1 commit
    • Alan Modra's avatar
      [PATCH] powerpc64: Fix loading of modules without a .toc section · f749edae
      Alan Modra authored
      Normally, ppc64 module .ko files contain a table-of-contents (.toc)
      section, but if the module doesn't reference any static or external
      data or external procedures, it is possible for gcc/binutils to
      generate a .ko that doesn't have a .toc.  Currently the module
      loader refuses to load such a module, since it needs the address
      of the .toc section to use in relocations.
      
      This patch fixes the problem by using the address of the .stubs
      section instead, which is an acceptable substitute in this situation.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      f749edae
  13. 14 Nov, 2005 1 commit
  14. 11 Oct, 2005 1 commit
  15. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4