1. 14 12月, 2006 2 次提交
    • R
      [ARM] Provide a method to alter the control register · 47fd7052
      Russell King 提交于
      i.MX needs to tweak the control register to support CPU frequency
      scaling.  Rather than have folk blindly try and change the control
      register by writing to it and then wondering why it doesn't work,
      provide a method (which is safe for UP only, and therefore only
      available for UP) to achieve this.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      47fd7052
    • N
      [ARM] 4016/1: prefetch macro is wrong wrt gcc's "delete-null-pointer-checks" · 02828845
      Nicolas Pitre 提交于
       optimization
      
      The gcc manual says:
      
      |`-fdelete-null-pointer-checks'
      |     Use global dataflow analysis to identify and eliminate useless
      |     checks for null pointers.  The compiler assumes that dereferencing
      |     a null pointer would have halted the program.  If a pointer is
      |     checked after it has already been dereferenced, it cannot be null.
      |     Enabled at levels `-O2', `-O3', `-Os'.
      
      Now the problem can be seen with this test case:
      
      #include <linux/prefetch.h>
      extern void bar(char *x);
      void foo(char *x)
      {
      	prefetch(x);
      	if (x)
      		bar(x);
      }
      
      Because the constraint to the inline asm used in the prefetch() macro is
      a memory operand, gcc assumes that the asm code does dereference the
      pointer and the delete-null-pointer-checks optimization kicks in.
      Inspection of generated assembly for the above example shows that bar()
      is indeed called unconditionally without any test on the value of x.
      
      Of course in the prefetch case there is no real dereference and it
      cannot be assumed that a null pointer would have been caught at that
      point. This causes kernel oopses with constructs like
      hlist_for_each_entry() where the list's 'next' content is prefetched
      before the pointer is tested against NULL, and only when gcc feels like
      applying this optimization which doesn't happen all the time with more
      complex code.
      
      It appears that the way to prevent delete-null-pointer-checks
      optimization to occur in this case is to make prefetch() into a static
      inline function instead of a macro. At least this is what is done on
      x86_64 where a similar inline asm memory operand is used (I presume they
      would have seen the same problem if it didn't work) and resulting code
      for the above example confirms that.
      
      An alternative would consist of replacing the memory operand by a
      register operand containing the pointer, and use the addressing mode
      explicitly in the asm template. But that would be less optimal than an
      offsettable memory reference.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      02828845
  2. 13 12月, 2006 6 次提交
  3. 12 12月, 2006 1 次提交
  4. 10 12月, 2006 1 次提交
  5. 09 12月, 2006 3 次提交
  6. 08 12月, 2006 27 次提交