1. 05 11月, 2015 1 次提交
    • R
      sparc64: Don't restrict fp regs for no-fault loads · cae9af6a
      Rob Gardner 提交于
      The function handle_ldf_stq() deals with no-fault ASI
      loads and stores, but restricts fp registers to quad
      word regs (ie, %f0, %f4 etc). This is valid for the
      STQ case, but unnecessarily restricts loads, which
      may be single precision, double, or quad. This results
      in SIGFPE being raised for this instruction when the
      source address is invalid:
      	ldda [%g1] ASI_PNF, %f2
      but not for this one:
      	ldda [%g1] ASI_PNF, %f4
      The validation check for quad register is moved to
      within the STQ block so that loads are not affected
      by the check.
      
      An additional problem is that the calculation for freg
      is incorrect when a single precision load is being
      handled. This causes %f1 to be seen as %f32 etc,
      and the incorrect register ends up being overwritten.
      This code sequence demonstrates the problem:
      	ldd [%g1], %f32		! g1 = valid address
      	lda [%i3] ASI_PNF, %f1  ! i3 = invalid address
      	std %f32, [%g1]
      This is corrected by basing the freg calculation on
      the load size.
      Signed-off-by: NRob Gardner <rob.gardner@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cae9af6a
  2. 19 5月, 2014 1 次提交
    • S
      sparc64: fix sparse warnings in sys_sparc_64.c + unaligned_64.c · 8df52620
      Sam Ravnborg 提交于
      Fix following warnings:
      kernel/sys_sparc_64.c:643:17: warning: symbol 'sys_kern_features' was not declared. Should it be static?
      kernel/unaligned_64.c:297:17: warning: symbol 'kernel_unaligned_trap' was not declared. Should it be static?
      kernel/unaligned_64.c:387:5: warning: symbol 'handle_popc' was not declared. Should it be static?
      kernel/unaligned_64.c:428:5: warning: symbol 'handle_ldf_stq' was not declared. Should it be static?
      kernel/unaligned_64.c:553:6: warning: symbol 'handle_ld_nf' was not declared. Should it be static?
      kernel/unaligned_64.c:579:6: warning: symbol 'handle_lddfmna' was not declared. Should it be static?
      kernel/unaligned_64.c:643:6: warning: symbol 'handle_stdfmna' was not declared. Should it be static?
      
      Functions that are only used in kernel/ - add prototypes in kernel.h
      Functions used outside kernel/ - add prototype in asm/setup.h
      Removed local prototypes
      
      One of the local prototypes had wrong signature (return void - not int).
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8df52620
  3. 04 5月, 2014 1 次提交
  4. 15 11月, 2013 1 次提交
  5. 27 10月, 2012 1 次提交
    • D
      sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads. · 517ffce4
      David S. Miller 提交于
      The Montgomery Multiply, Montgomery Square, and Multiple-Precision
      Multiply instructions work by loading a combination of the floating
      point and multiple register windows worth of integer registers
      with the inputs.
      
      These values are 64-bit.  But for 32-bit userland processes we only
      save the low 32-bits of each integer register during a register spill.
      This is because the register window save area is in the user stack and
      has a fixed layout.
      
      Therefore, the only way to use these instruction in 32-bit mode is to
      perform the following sequence:
      
      1) Load the top-32bits of a choosen integer register with a sentinel,
         say "-1".  This will be in the outer-most register window.
      
         The idea is that we're trying to see if the outer-most register
         window gets spilled, and thus the 64-bit values were truncated.
      
      2) Load all the inputs for the montmul/montsqr/mpmul instruction,
         down to the inner-most register window.
      
      3) Execute the opcode.
      
      4) Traverse back up to the outer-most register window.
      
      5) Check the sentinel, if it's still "-1" store the results.
         Otherwise retry the entire sequence.
      
      This retry is extremely troublesome.  If you're just unlucky and an
      interrupt or other trap happens, it'll push that outer-most window to
      the stack and clear the sentinel when we restore it.
      
      We could retry forever and never make forward progress if interrupts
      arrive at a fast enough rate (consider perf events as one example).
      So we have do limited retries and fallback to software which is
      extremely non-deterministic.
      
      Luckily it's very straightforward to provide a mechanism to let
      32-bit applications use a 64-bit stack.  Stacks in 64-bit mode are
      biased by 2047 bytes, which means that the lowest bit is set in the
      actual %sp register value.
      
      So if we see bit zero set in a 32-bit application's stack we treat
      it like a 64-bit stack.
      
      Runtime detection of such a facility is tricky, and cumbersome at
      best.  For example, just trying to use a biased stack and seeing if it
      works is hard to recover from (the signal handler will need to use an
      alt stack, plus something along the lines of longjmp).  Therefore, we
      add a system call to report a bitmask of arch specific features like
      this in a cheap and less hairy way.
      
      With help from Andy Polyakov.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      517ffce4
  6. 29 3月, 2012 1 次提交
  7. 16 2月, 2012 1 次提交
  8. 03 8月, 2011 1 次提交
  9. 01 7月, 2011 1 次提交
    • P
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      Peter Zijlstra 提交于
      The nmi parameter indicated if we could do wakeups from the current
      context, if not, we would set some state and self-IPI and let the
      resulting interrupt do the wakeup.
      
      For the various event classes:
      
        - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
          the PMI-tail (ARM etc.)
        - tracepoint: nmi=0; since tracepoint could be from NMI context.
        - software: nmi=[0,1]; some, like the schedule thing cannot
          perform wakeups, and hence need 0.
      
      As one can see, there is very little nmi=1 usage, and the down-side of
      not using it is that on some platforms some software events can have a
      jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).
      
      The up-side however is that we can remove the nmi parameter and save a
      bunch of conditionals in fast paths.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Michael Cree <mcree@orcon.net.nz>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      a8b0ca17
  10. 08 6月, 2011 1 次提交
  11. 20 4月, 2010 1 次提交
  12. 28 2月, 2010 1 次提交
  13. 11 2月, 2010 1 次提交
  14. 11 12月, 2009 1 次提交
  15. 09 1月, 2009 1 次提交
  16. 08 1月, 2009 1 次提交
  17. 05 12月, 2008 1 次提交
    • S
      sparc,sparc64: unify kernel/ · a88b5ba8
      Sam Ravnborg 提交于
      o Move all files from sparc64/kernel/ to sparc/kernel
        - rename as appropriate
      o Update sparc/Makefile to the changes
      o Update sparc/kernel/Makefile to include the sparc64 files
      
      NOTE: This commit changes link order on sparc64!
      
      Link order had to change for either of sparc32 and sparc64.
      And assuming sparc64 see more testing than sparc32 change link
      order on sparc64 where issues will be caught faster.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a88b5ba8
  18. 18 7月, 2008 1 次提交
  19. 20 5月, 2008 1 次提交
  20. 18 2月, 2008 1 次提交
  21. 29 1月, 2008 1 次提交
  22. 09 5月, 2007 1 次提交
  23. 10 12月, 2006 1 次提交
  24. 30 6月, 2006 1 次提交
  25. 24 6月, 2006 1 次提交
  26. 20 3月, 2006 1 次提交
  27. 29 9月, 2005 3 次提交
  28. 20 9月, 2005 1 次提交
    • D
      [SPARC64]: Handle little-endian unaligned loads/stores correctly. · ff171d8f
      David S. Miller 提交于
      Because we use byte loads/stores to cons up the value
      in and out of registers, we can't expect the ASI endianness
      setting to take care of this for us.  So do it by hand.
      
      This case is triggered by drivers/block/aoe/aoecmd.c in the
      ataid_complete() function where it goes:
      
      		/* word 100: number lba48 sectors */
      		ssize = le64_to_cpup((__le64 *) &id[100<<1]);
      
      This &id[100<<1] address is 4 byte, rather than 8 byte aligned,
      thus triggering the unaligned exception.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff171d8f
  29. 30 8月, 2005 1 次提交
    • D
      [SPARC64]: Revamp Spitfire error trap handling. · 6c52a96e
      David S. Miller 提交于
      Current uncorrectable error handling was poor enough
      that the processor could just loop taking the same
      trap over and over again.  Fix things up so that we
      at least get a log message and perhaps even some register
      state.
      
      In the process, much consolidation became possible,
      particularly with the correctable error handler.
      
      Prefix assembler and C function names with "spitfire"
      to indicate that these are for Ultra-I/II/IIi/IIe only.
      
      More work is needed to make these routines robust and
      featureful to the level of the Ultra-III error handlers.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c52a96e
  30. 20 8月, 2005 1 次提交
  31. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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