1. 25 10月, 2011 4 次提交
    • J
      x86: Fix compilation bug in kprobes' twobyte_is_boostable · 315eb8a2
      Josh Stone 提交于
      When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I
      noticed a warning about the asm operand for test_bit in kprobes'
      can_boost.  I discovered that this caused only the first long of
      twobyte_is_boostable[] to be output.
      
      Jakub filed and fixed gcc PR50571 to correct the warning and this output
      issue.  But to solve it for less current gcc, we can make kprobes'
      twobyte_is_boostable[] non-const, and it won't be optimized out.
      
      Before:
      
          CC      arch/x86/kernel/kprobes.o
        In file included from include/linux/bitops.h:22:0,
                         from include/linux/kernel.h:17,
                         from [...]/arch/x86/include/asm/percpu.h:44,
                         from [...]/arch/x86/include/asm/current.h:5,
                         from [...]/arch/x86/include/asm/processor.h:15,
                         from [...]/arch/x86/include/asm/atomic.h:6,
                         from include/linux/atomic.h:4,
                         from include/linux/mutex.h:18,
                         from include/linux/notifier.h:13,
                         from include/linux/kprobes.h:34,
                         from arch/x86/kernel/kprobes.c:43:
        [...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’:
        [...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input
              without lvalue in asm operand 1 is deprecated [enabled by default]
      
        $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
             551:	0f a3 05 00 00 00 00 	bt     %eax,0x0
                                554: R_386_32	.rodata.cst4
      
        $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o
      
        arch/x86/kernel/kprobes.o:     file format elf32-i386
      
        Contents of section .data:
         0000 48000000 00000000 00000000 00000000  H...............
        Contents of section .rodata.cst4:
         0000 4c030000                             L...
      
      Only a single long of twobyte_is_boostable[] is in the object file.
      
      After, without the const on twobyte_is_boostable:
      
        $ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
             551:	0f a3 05 20 00 00 00 	bt     %eax,0x20
                                554: R_386_32	.data
      
        $ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o
      
        arch/x86/kernel/kprobes.o:     file format elf32-i386
      
        Contents of section .data:
         0000 48000000 00000000 00000000 00000000  H...............
         0010 00000000 00000000 00000000 00000000  ................
         0020 4c030000 0f000200 ffff0000 ffcff0c0  L...............
         0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77  ....;.......&..w
      
      Now all 32 bytes are output into .data instead.
      Signed-off-by: NJosh Stone <jistone@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      315eb8a2
    • K
      m68k: Finally remove leftover markers sections · bc74ee97
      Kirill Tkhai 提交于
      Markers have removed already twice:
      
      1: fc537766
      2: eb878b3b
      
      But a little bit is still here.
      Signed-off-by: NTkhai Kirill <tkhai@yandex.ru>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      bc74ee97
    • F
      m68k/mac: Fix mac_irq_pending() for PSC MACE and SCC · 8b223432
      Finn Thain 提交于
      Add missing return statement. The docs say that the level 4 PSC IRQs
      relate to MACE DMA and SCC. Since those drivers don't call
      mac_irq_pending() this patch has no affect. But it should be fixed all the
      same, since it can be useful for MACE debugging.
      Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      8b223432
    • F
      m68k/mac: Fix compiler warning in via_read_time() · 75a23850
      Finn Thain 提交于
      The algorithm described in the comment compares two reads from the RTC but
      the code actually reads once and compares the result to an uninitialized
      value. This causes the compiler to warn, "last_result maybe used
      uninitialized". Make the code match the comment, fix the warning and
      perhaps improve reliability. Tested on a Quadra 700.
      Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      75a23850
  2. 24 10月, 2011 2 次提交
    • T
      x86: Fix S4 regression · 8548c84d
      Takashi Iwai 提交于
      Commit 4b239f45 ("x86-64, mm: Put early page table high") causes a S4
      regression since 2.6.39, namely the machine reboots occasionally at S4
      resume.  It doesn't happen always, overall rate is about 1/20.  But,
      like other bugs, once when this happens, it continues to happen.
      
      This patch fixes the problem by essentially reverting the memory
      assignment in the older way.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Cc: <stable@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Yinghai Lu <yinghai.lu@oracle.com>
      [ We'll hopefully find the real fix, but that's too late for 3.1 now ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8548c84d
    • T
      ARM: 7133/1: SMP: fix per cpu timer setup before the cpu is marked online · eb047454
      Thomas Gleinxer 提交于
      The problem is related to the early enabling of interrupts and the
      per cpu timer setup before the cpu is marked online. This doesn't
      need to be done in order to call calibrate_delay().
      
      calibrate_delay() monitors jiffies, which are updated from the CPU
      which is waiting for the new CPU to set the online bit.
      
      So simply calibrate_delay() can be called on the new CPU just from
      the interrupt disabled region and move the local timer setup after
      stored the cpu data and before enabling interrupts.
      
      This solves both the cpu_online vs. cpu_active problem and the
      affinity setting of the per cpu timers.
      Signed-off-by: NThomas Gleinxer <tglx@linutronix.de>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      eb047454
  3. 23 10月, 2011 2 次提交
  4. 22 10月, 2011 3 次提交
    • M
      ARM: mach-shmobile: sh7372 A4R support (v4) · 382414b9
      Magnus Damm 提交于
      This change adds support for the sh7372 A4R power domain.
      
      The sh7372 A4R hardware power domain contains the
      SH CPU Core and a set of I/O devices including
      multimedia accelerators and I2C controllers.
      
      One special case about A4R is the INTCS interrupt
      controller that needs to be saved and restored to
      keep working as expected. Also the LCDC hardware
      blocks are in a different hardware power domain
      but have their IRQs routed only through INTCS. So
      as long as LCDCs are active we cannot power down
      INTCS because that would risk losing interrupts.
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      382414b9
    • M
      ARM: mach-shmobile: sh7372 A3SP support (v4) · d93f5cde
      Magnus Damm 提交于
      This change adds support for the sh7372 A3SP power domain.
      
      The sh7372 A3SP hardware power domain contains a
      wide range of I/O devices. The list of I/O devices
      include SCIF serial ports, DMA Engine hardware,
      SD and MMC controller hardware, USB controllers
      and I2C master controllers.
      
      This patch adds the A3SP low level code which
      powers the hardware power domain on and off. It
      also ties in platform devices to the pm domain
      support code.
      
      It is worth noting that the serial console is
      hooked up to SCIFA0 on most sh7372 boards, and
      the SCIFA0 port is included in the A3SP hardware
      power domain. For this reason we cannot output
      debug messages from the low level power control
      code in the case of A3SP.
      
      QoS support is needed in drivers before we can
      enable the A3SP power control on the fly.
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d93f5cde
    • D
      ARM: S3C24XX: Fix s3c24xx build errors if !CONFIG_PM · fb630b9f
      Domenico Andreoli 提交于
      v2:
      - register_syscore_ops(&s3c24xx_irq_syscore_ops) does not need to be
        conditionally compiled out, it is already optimized out on !CONFIG_PM
      - fix also s3c2412 and s3c2416 affected by the same build issue
      
      v1:
      s3c2440.c fails to build if !CONFIG_PM because in such case
      s3c2410_pm_syscore_ops is not defined. Same error should happen also
      in s3c2410.c and s3c2442.c
      Signed-off-by: NDomenico Andreoli <cavokz@gmail.com>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      fb630b9f
  5. 21 10月, 2011 3 次提交
  6. 20 10月, 2011 5 次提交
  7. 17 10月, 2011 21 次提交