1. 07 1月, 2009 5 次提交
    • S
      sparc64: Use unsigned long long for u64. · 90181136
      Sam Ravnborg 提交于
      Andrew Morton wrote:
      
          People keep on doing
      
                  printk("%llu", some_u64);
      
          testing it only on x86_64 and this generates a warning storm on
          powerpc, sparc64, etc.  Because they use `long', not `long long'.
      
          Quite a few 64-bit architectures are using `long' for their
          s64/u64 types.  We should convert them all to `long long'.
      
      Update types.h so we use unsigned long long for u64 and
      fix all warnings in sparc64 code.
      Tested with an allnoconfig, defconfig and allmodconfig builds.
      
      This patch introduces additional warnings in several drivers.
      These will be dealt with in separate patches.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90181136
    • S
      sparc: refactor code in fault_32.c · 0157141a
      Sam Ravnborg 提交于
      The sparc allmodconfig build broke due to enabling of the
      branch_tracer that does some very clever things with
      all if conditions. This caused my gcc 3.4.5 to be so confused that
      it emitted a warning:
      
      arch/sparc/mm/fault_32.c: In function `do_sparc_fault':
      arch/sparc/mm/fault_32.c:176: warning: 'fixup' might be used uninitialized in this function
      
      And with -Werror this broke the build.
      
      Refactor code so it:
      1) becomes more readable
      2) no longer emit a warning with the branch_tracer enabled
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0157141a
    • S
      sparc64: refactor code in init_64.c · ff9aefbf
      Sam Ravnborg 提交于
      The sparc64 allmodconfig build broke due to enabling of the
      branch_tracer that does some very clever things with
      all if conditions. This caused my gcc 3.4.5 to be so confused that
      it emitted two warnings:
      
      arch/sparc/mm/init_64.c: In function `update_mmu_cache':
      arch/sparc/mm/init_64.c:271: warning: 'pg_flags' might be used uninitialized in this function
      arch/sparc/mm/init_64.c:272: warning: 'page' might be used uninitialized in this function
      
      And with -Werror this broke the build.
      
      Refactor code so it:
      1) becomes more readable
      2) no longer emit a warning with the branch_tracer enabled
      
      The refactoring uses a small helper function (flush_dcache()).
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff9aefbf
    • S
      sparc64: refactor code in viohs.c · 2eac5a0d
      Sam Ravnborg 提交于
      The sparc64 allmodconfig build broke due to enabling of the
      branch_tracer that does some very clever things with
      all if conditions. This caused my gcc 3.4.5 to be so confused that
      it emitted a warning:
      
      arch/sparc/kernel/viohs.c: In function `vio_control_pkt_engine':
      arch/sparc/kernel/viohs.c:335: warning: 'nver' might be used uninitialized in this function
      
      And with -Werror this broke the build.
      
      Refactor code so it:
      1) becomes more readable
      2) no longer emit a warning with the branch_tracer enabled
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2eac5a0d
    • S
      sparc: make proces_ver_nack a bit more readable · b2c0805f
      Steven Rostedt 提交于
      Impact: clean up
      
      The code in process_ver_nack is a little obfuscated. This change
      makes it a bit more readable by humans. It removes the complex
      if statement and replaces it with a cleaner flow of control.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2c0805f
  2. 06 1月, 2009 5 次提交
  3. 05 1月, 2009 6 次提交
  4. 04 1月, 2009 8 次提交
  5. 03 1月, 2009 16 次提交