1. 08 10月, 2007 3 次提交
    • T
      [POWERPC] 86xx: update immap_86xx.h for the 8610 · 090fe850
      Timur Tabi 提交于
      Update the definition of the global utilities structure (ccsr_guts) in
      immap_86xx.h and add some related macros for the Freescale 8610 SOC.
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      090fe850
    • J
      61c5d3cd
    • T
      [POWERPC] qe: miscellaneous code improvements and fixes to the QE library · 6b0b594b
      Timur Tabi 提交于
      This patch makes numerous miscellaneous code improvements to the QE library.
      
      1. Remove struct ucc_common and merge ucc_init_guemr() into ucc_set_type()
         (every caller of ucc_init_guemr() also calls ucc_set_type()).  Modify all
         callers of ucc_set_type() accordingly.
      
      2. Remove the unused enum ucc_pram_initial_offset.
      
      3. Refactor qe_setbrg(), also implement work-around for errata QE_General4.
      
      4. Several printk() calls were missing the terminating \n.
      
      5. Add __iomem where needed, and change u16 to __be16 and u32 to __be32 where
         appropriate.
      
      6. In ucc_slow_init() the RBASE and TBASE registers in the PRAM were programmed
         with the wrong value.
      
      7. Add the protocol type to struct us_info and updated ucc_slow_init() to
         use it, instead of always programming QE_CR_PROTOCOL_UNSPECIFIED.
      
      8. Rename ucc_slow_restart_x() to ucc_slow_restart_tx()
      
      9. Add several macros in qe.h (mostly for slow UCC support, but also to
         standardize some naming convention) and remove several unused macros.
      
      10. Update ucc_geth.c to use the new macros.
      
      11. Add ucc_slow_info.protocol to specify which QE_CR_PROTOCOL_xxx protcol
          to use when initializing the UCC in ucc_slow_init().
      
      12. Rename ucc_slow_pram.rfcr to rbmr and ucc_slow_pram.tfcr to tbmr, since
          these are the real names of the registers.
      
      13. Use the setbits, clrbits, and clrsetbits where appropriate.
      
      14. Refactor ucc_set_qe_mux_rxtx().
      
      15. Remove all instances of 'volatile'.
      
      16. Simplify get_cmxucr_reg();
      
      17. Replace qe_mux.cmxucrX with qe_mux.cmxucr[].
      
      18. Updated struct ucc_geth because struct ucc_fast is not padded any more.
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      6b0b594b
  2. 05 10月, 2007 6 次提交
  3. 04 10月, 2007 3 次提交
  4. 03 10月, 2007 11 次提交
  5. 01 10月, 2007 1 次提交
  6. 30 9月, 2007 1 次提交
    • N
      i386: remove bogus comment about memory barrier · 4827bbb0
      Nick Piggin 提交于
      The comment being removed by this patch is incorrect and misleading.
      
      In the following situation:
      
      	1. load  ...
      	2. store 1 -> X
      	3. wmb
      	4. rmb
      	5. load  a <- Y
      	6. store ...
      
      4 will only ensure ordering of 1 with 5.
      3 will only ensure ordering of 2 with 6.
      
      Further, a CPU with strictly in-order stores will still only provide that
      2 and 6 are ordered (effectively, it is the same as a weakly ordered CPU
      with wmb after every store).
      
      In all cases, 5 may still be executed before 2 is visible to other CPUs!
      
      The additional piece of the puzzle that mb() provides is the store/load
      ordering, which fundamentally cannot be achieved with any combination of
      rmb()s and wmb()s.
      
      This can be an unexpected result if one expected any sort of global ordering
      guarantee to barriers (eg. that the barriers themselves are sequentially
      consistent with other types of barriers).  However sfence or lfence barriers
      need only provide an ordering partial ordering of memory operations -- Consider
      that wmb may be implemented as nothing more than inserting a special barrier
      entry in the store queue, or, in the case of x86, it can be a noop as the store
      queue is in order. And an rmb may be implemented as a directive to prevent
      subsequent loads only so long as their are no previous outstanding loads (while
      there could be stores still in store queues).
      
      I can actually see the occasional load/store being reordered around lfence on
      my core2. That doesn't prove my above assertions, but it does show the comment
      is wrong (unless my program is -- can send it out by request).
      
      So:
         mb() and smp_mb() always have and always will require a full mfence
         or lock prefixed instruction on x86.  And we should remove this comment.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Paul McKenney <paulmck@us.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4827bbb0
  7. 29 9月, 2007 2 次提交
    • D
      [TCP]: Fix MD5 signature handling on big-endian. · f8ab18d2
      David S. Miller 提交于
      Based upon a report and initial patch by Peter Lieven.
      
      tcp4_md5sig_key and tcp6_md5sig_key need to start with
      the exact same members as tcp_md5sig_key.  Because they
      are both cast to that type by tcp_v{4,6}_md5_do_lookup().
      
      Unfortunately tcp{4,6}_md5sig_key use a u16 for the key
      length instead of a u8, which is what tcp_md5sig_key
      uses.  This just so happens to work by accident on
      little-endian, but on big-endian it doesn't.
      
      Instead of casting, just place tcp_md5sig_key as the first member of
      the address-family specific structures, adjust the access sites, and
      kill off the ugly casts.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8ab18d2
    • R
      [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0. · 9ae6399f
      Ralf Baechle 提交于
      The __pa() for those did assume that all symbols have XKPHYS values and
      the math fails for any other address range.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9ae6399f
  8. 28 9月, 2007 1 次提交
  9. 27 9月, 2007 4 次提交
    • L
      Revert "[PATCH] x86-64: fix x86_64-mm-sched-clock-share" · ff0ce684
      Linus Torvalds 提交于
      This reverts commit 184c44d2.
      
      As noted by Dave Jones:
         "Linus, please revert the above cset.  It doesn't seem to be
          necessary (it was added to fix a miscompile in 'make allnoconfig'
          which doesn't seem to be repeatable with it reverted) and actively
         breaks the ARM SA1100 framebuffer driver."
      Requested-by: NDave Jones <davej@redhat.com>
      Cc: Russell King <rmk+lkml@arm.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ff0ce684
    • L
      Revert "x86-64: Disable local APIC timer use on AMD systems with C1E" · f7f847b0
      Linus Torvalds 提交于
      This reverts commit e66485d7, since
      Rafael Wysocki noticed that the change only works for his in -mm, not in
      mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken
      on his hardware, but that's apparently not a regression, just a symptom
      of the same issue that causes the automatic apic timer disable to not
      work).
      
      It turns out that it really doesn't work correctly on x86-64, since
      x86-64 doesn't use the generic clock events for timers yet.
      
      Thanks to Rafal for testing, and here's the ugly details on x86-64 as
      per Thomas:
      
        "I just looked into the code and the logic vs.  noapictimer on SMP is
         completely broken.
      
         On i386 the noapictimer option not only disables the local APIC
         timer, it also registers the CPUs for broadcasting via IPI on SMP
         systems.
      
         The x86-64 code uses the broadcast only when the local apic timer is
         active, i.e.  "noapictimer" is not on the command line.  This defeats
         the whole purpose of "noapictimer".  It should be there to make boxen
         work, where the local APIC timer actually has a hardware problem,
         e.g.  the nx6325.
      
         The current implementation of x86_64 only fixes the ACPI c-states
         related problem where the APIC timer stops in C3(2), nothing else.
      
         On nx6325 and other AMD X2 equipped systems which have the C1E
         enabled we run into the following:
      
         PIT keeps jiffies (and the system) running, but the local APIC timer
         interrupts can get out of sync due to this C1E effect.
      
         I don't think this is a critical problem, but it is wrong
         nevertheless.
      
         I think it's safe to revert the C1E patch and postpone the fix to the
         clock events conversion."
      
      On further reflection, Thomas noted:
      
         "It's even worse than I thought on the first check:
      
          "noapictimer" on the command line of an SMP box prevents _ONLY_ the
          boot CPU apic timer from being used.  But the secondary CPU is still
          unconditionally setting up the APIC timer and uses the non
          calibrated variable calibration_result, which is of course 0, to
          setup the APIC timer.  Wreckage guaranteed."
      
      so we'll just have to wait for the x86 merge to hopefully fix this up
      for x86-64.
      Tested-and-requested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f7f847b0
    • T
      x86-64: Disable local APIC timer use on AMD systems with C1E · e66485d7
      Thomas Gleixner 提交于
      commit 3556ddfa titled
      
       [PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
      
      solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64
      X2) with C1E enabled:
      
      When both cores go into idle at the same time, then the system switches
      into C1E state, which is basically the same as C3. This stops the local
      apic timer.
      
      This was debugged right after the dyntick merge on i386 and despite the
      patch title it fixes only the 32 bit path.
      
      x86_64 is still missing this fix. It seems that mainline is not really
      affected by this issue, as the PIT is running and keeps jiffies
      incrementing, but that's just waiting for trouble.
      
      -mm suffers from this problem due to the x86_64 high resolution timer
      patches.
      
      This is a quick and dirty port of the i386 code to x86_64.
      
      I spent quite a time with Rafael to debug the -mm / hrt wreckage until
      someone pointed us to this. I really had forgotten that we debugged this
      half a year ago already.
      
      Sigh, is it just me or is there something yelling arch/x86 into my ear?
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e66485d7
    • A
      fix sctp_del_bind_addr() last argument type · 78bd8fbb
      Al Viro 提交于
      It gets pointer to fastcall function, expects a pointer to normal
      one and calls the sucker.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      78bd8fbb
  10. 26 9月, 2007 3 次提交
  11. 25 9月, 2007 1 次提交
  12. 23 9月, 2007 1 次提交
    • T
      ACPI: disable lower idle C-states across suspend/resume · b04e7bdb
      Thomas Gleixner 提交于
      device_suspend() calls ACPI suspend functions, which seems to have undesired
      side effects on lower idle C-states. It took me some time to realize that
      especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
      show this effect. I'm quite sure that other bug reports against suspend/resume
      about turning the system into a brick have the same root cause.
      
      After fishing in the dark for quite some time, I realized that removing the ACPI
      processor module before suspend (this removes the lower C-state functionality)
      made the problem disappear. Interestingly enough the propability of having a
      bricked box is influenced by various factors (interrupts, size of the ram image,
      ...). Even adding a bunch of printks in the wrong places made the problem go
      away. The previous periodic tick implementation simply pampered over the
      problem, which explains why the dyntick / clockevents changes made this more
      prominent.
      
      We avoid complex functionality during the boot process and we have to do the
      same during suspend/resume. It is a similar scenario and equaly fragile.
      
      Add suspend / resume functions to the ACPI processor code and disable the lower
      idle C-states across suspend/resume. Fall back to the default idle
      implementation (halt) instead.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b04e7bdb
  13. 22 9月, 2007 3 次提交