1. 14 2月, 2012 2 次提交
  2. 13 2月, 2012 1 次提交
  3. 05 2月, 2012 2 次提交
  4. 04 2月, 2012 2 次提交
  5. 03 2月, 2012 7 次提交
    • W
      ARM: 7314/1: kuser: consistently use usr_ret for returning from helpers · 5a97d0ae
      Will Deacon 提交于
      __kuser_cmpxchg64 has a return path using bx lr to get back to the caller.
      This is actually ok since the code in question is predicated on
      CONFIG_CPU_32v6K, but for the sake of consistency using the usr_ret
      macro is probably better.
      Acked-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5a97d0ae
    • C
      ARM: 7302/1: Add TLB flushing for both entries in a PMD · 6d3ec1ae
      Catalin Marinas 提交于
      Linux uses two PMD entries for a PTE with the classic page table format,
      covering 2MB range. However, the __pte_free_tlb() function only adds a
      single TLB flush corresponding to 1MB range covering 'addr'. On
      Cortex-A15, level 1 entries can be cached by the TLB independently of
      the level 2 entries and without additional flushing a PMD entry would be
      left pointing at the wrong PTE. The patch limits the TLB flushing range
      to two 4KB pages around the 1MB boundary within PMD.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6d3ec1ae
    • W
      ARM: 7303/1: perf: add empty NODE event definitions for Cortex-A5 and Cortex-A15 · 91756acb
      Will Deacon 提交于
      Commit 89d6c0b5 ("perf, arch: Add generic NODE cache events") added
      empty NODE event definitions for the ARM PMU implementations. This was
      merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed
      out on the original patch.
      
      This patch adds the empty definitions to Cortex-A5 and Cortex-A15.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      91756acb
    • W
      ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers · 8130b9d7
      Will Deacon 提交于
      If we are context switched whilst copying into a thread's
      vfp_hard_struct then the partial copy may be corrupted by the VFP
      context switching code (see "ARM: vfp: flush thread hwstate before
      restoring context from sigframe").
      
      This patch updates the ptrace VFP set code so that the thread state is
      flushed before the copy, therefore disabling VFP and preventing
      corruption from occurring.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8130b9d7
    • D
      ARM: 7307/1: vfp: fix ptrace regset modification race · 247f4993
      Dave Martin 提交于
      In a preemptible kernel, vfp_set() can be preempted, causing the
      hardware VFP context to be switched while the thread vfp state is
      being read and modified.  This leads to a race condition which can
      cause the thread vfp state to become corrupted if lazy VFP context
      save occurs due to preemption in between the time thread->vfpstate
      is read and the time the modified state is written back.
      
      This may occur if preemption occurs during the execution of a
      ptrace() call which modifies the VFP register state of a thread.
      Such instances should be very rare in most realistic scenarios --
      none has been reported, so far as I am aware.  Only uniprocessor
      systems should be affected, since VFP context save is not currently
      lazy in SMP kernels.
      
      The problem was introduced by my earlier patch migrating to use
      regsets to implement ptrace.
      
      This patch does a vfp_sync_hwstate() before reading
      thread->vfpstate, to make sure that the thread's VFP state is not
      live in the hardware registers while the registers are modified.
      
      Thanks to Will Deacon for spotting this.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      247f4993
    • W
      ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe · 2af276df
      Will Deacon 提交于
      Following execution of a signal handler, we currently restore the VFP
      context from the ucontext in the signal frame. This involves copying
      from the user stack into the current thread's vfp_hard_struct and then
      flushing the new data out to the hardware registers.
      
      This is problematic when using a preemptible kernel because we could be
      context switched whilst updating the vfp_hard_struct. If the current
      thread has made use of VFP since the last context switch, the VFP
      notifier will copy from the hardware registers into the vfp_hard_struct,
      overwriting any data that had been partially copied by the signal code.
      
      Disabling preemption across copy_from_user calls is a terrible idea, so
      instead we move the VFP thread flush *before* we update the
      vfp_hard_struct. Since the flushing is performed lazily, this has the
      effect of disabling VFP and clearing the CPU's VFP state pointer,
      therefore preventing the thread from being updated with stale data on
      the next context switch.
      
      Cc: stable <stable@vger.kernel.org>
      Tested-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2af276df
    • R
      Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" · 97f10409
      Russell King 提交于
      This reverts commit 3c424f35.
      
      Joachim Eastwood reports:
      | "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
      | Commit: 3c424f35 in Linus master
      |
      | Breaks booting on my custom AT91RM9200 board.
      | There isn't any error messages or anything that indicates what goes
      | wrong it just stops after; Uncompressing Linux... done, booting the
      | kernel.
      |
      | Reverting it makes my board boot again.
      
      and further debugging reveals:
      
      ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
      ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
      ioremap: found: addr fef74000 => fed73000 => fed73400
      
      Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
      0xfffff.  This happens because the changed if statement becomes:
      
                      if (0x00200 > 0xfffff ||
                          0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
      and therefore:
                      if (0x00200 > 0xfffff ||
                          0x000003ff > 0x00203fff)
      
      The if condition fails, and so we _believe_ that the SRAM mapping fits
      our request.  Clearly that's totally bogus.
      
      Moreover, the original premise of the 'fix' patch was wrong:
      |    The condition checking boundaries of the requested and existing
      |    mappings didn't take in-page offset into consideration though,
      |    which lead to obscure and hard to debug problems when requested
      |    mapping crossed end of the static one.
      
      as the code immediately above this loop does:
      
              size = PAGE_ALIGN(offset + size);
      
      so 'size' already contains the requested offset into the page.
      
      So, revert the broken 'fix'.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      97f10409
  6. 02 2月, 2012 2 次提交
  7. 01 2月, 2012 5 次提交
  8. 31 1月, 2012 1 次提交
    • M
      Revert "microblaze: Add topology init" · 9afc4165
      Michal Simek 提交于
      This reverts commit d761f0c5.
      
      Patch: "cpu: Register a generic CPU device on architectures that currently do not"
      (sha1: 9f13a1fd)
      
      selects GENERIC_CPU_DEVICES for Microblaze which register cpu.
      My patch was done in the same time that's why cpu was registered twice which
      caused this warning log:
      
      ------------[ cut here ]------------
      WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xb0/0xdc()
      sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0'
      Modules linked in:
      ...
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      9afc4165
  9. 30 1月, 2012 2 次提交
    • M
      x86/reboot: Remove VersaLogic Menlow reboot quirk · e6d36a65
      Michael D Labriola 提交于
      This commit removes the reboot quirk originally added by commit
      e19e074b ("x86: Fix reboot problem on VersaLogic Menlow boards").
      
      Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS
      6.5.102) revealed the following regarding the reboot hang
      problem:
      
      - v2.6.37 reboot=bios was needed.
      
      - v2.6.38-rc1: behavior changed, reboot=acpi is needed,
        reboot=kbd and reboot=bios results in system hang.
      
      - v2.6.38: VersaLogic patch (e19e074b "x86: Fix reboot problem on
        VersaLogic Menlow boards") was applied prior to v2.6.38-rc7.  This
        patch sets a quirk for VersaLogic Menlow boards that forces the use
        of reboot=bios, which doesn't work anymore.
      
      - v3.2: It seems that commit 660e34ce ("x86: Reorder reboot method
        preferences") changed the default reboot method to acpi prior to
        v3.0-rc1, which means the default behavior is appropriate for the
        Ocelot.  No VersaLogic quirk is required.
      
      The Ocelot board used for testing can successfully reboot w/out
      having to pass any reboot= arguments for all 3 current versions
      of the BIOS.
      Signed-off-by: NMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Kushal Koolwal <kushalkoolwal@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      e6d36a65
    • M
      x86/reboot: Skip DMI checks if reboot set by user · 5955633e
      Michael D Labriola 提交于
      Skip DMI checks for vendor specific reboot quirks if the user
      passed in a reboot= arg on the command line - we should never
      override user choices.
      Signed-off-by: NMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      5955633e
  10. 28 1月, 2012 3 次提交
  11. 27 1月, 2012 9 次提交
    • J
      ARM: OMAP2+: arch/arm/mach-omap2/smartreflex.c: add missing iounmap · 14ea9601
      Julia Lawall 提交于
      Add missing iounmap in error handling code, in a case where the function
      already preforms iounmap on some other execution path.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      expression e;
      statement S,S1;
      int ret;
      @@
      e = \(ioremap\|ioremap_nocache\)(...)
      ... when != iounmap(e)
      if (<+...e...+>) S
      ... when any
          when != iounmap(e)
      *if (...)
         { ... when != iounmap(e)
           return ...; }
      ... when any
      iounmap(e);
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      14ea9601
    • J
      ARM: OMAP2+: arch/arm/mach-omap2/devices.c: introduce missing kfree · e0feca89
      Julia Lawall 提交于
      pdata needs to be freed before leaving the function in an error case.
      
      A simplified version of the semantic match that finds the problem is as
      follows: (http://coccinelle.lip6.fr)
      
      // <smpl>
      @r exists@
      local idexpression x;
      statement S;
      identifier f1;
      position p1,p2;
      expression *ptr != NULL;
      @@
      
      x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
      ...
      if (x == NULL) S
      <... when != x
           when != if (...) { <+...x...+> }
      x->f1
      ...>
      (
       return \(0\|<+...x...+>\|ptr\);
      |
       return@p2 ...;
      )
      
      @script:python@
      p1 << r.p1;
      p2 << r.p2;
      @@
      
      print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e0feca89
    • G
      ARM: OMAP: fix MMC2 loopback clock handling · d82e5190
      Grazvydas Ignotas 提交于
      Currently MMC2 setup code can only enable loopback clock and
      relies on reset value for boards that need to have it disabled.
      This causes a problem with certain bootloaders that always enable
      that clock, resulting with unwanted bootloader dependencies.
      
      Fix this by making it disable the clock if board data says so.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d82e5190
    • G
      ARM: OMAP: fix erroneous mmc2 clock change on mmc3 setup · ffa1e4ed
      Grazvydas Ignotas 提交于
      hsmmc23_before_set_reg() can set MMCSDIO2ADPCLKISEL bit, which
      enables internal clock for MMC2. Currently this function is also called
      by code handling MMC3, and if .internal_clock is set in platform data
      (by default it currently is), it will set MMCSDIO2ADPCLKISEL for MMC2
      instead of MMC3 (MMC3 doesn't have such bit so nothing actually needs to
      be done). This breaks 2nd SD slot on pandora.
      
      Fix this by changing hsmmc23_before_set_reg() to only handle MMC2.
      Note that this removes .remux() call for MMC3, but no board currently
      needs it and it's also not called for MMC4 and MMC5.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ffa1e4ed
    • Y
      ARM: OMAP2+: GPMC: fix device size setup · 8ef5d844
      Yegor Yefremov 提交于
      following statement can only change device size from 8-bit(0) to 16-bit(1),
      but not vice versa:
      
      regval |= GPMC_CONFIG1_DEVICESIZE(wval);
      
      so as this field has 1 reserved bit, that could be used in future,
      just clear both bits and then OR with the desired value
      Signed-off-by: NYegor Yefremov <yegorslists@googlemail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      8ef5d844
    • V
      ARM: OMAP2+: timer: Fix crash due to wrong arg to __omap_dm_timer_read_counter · dbc3982a
      Vaibhav Hiremath 提交于
      Commit 2f0778af (ARM: 7205/2: sched_clock: allow sched_clock to be
      selected at runtime) had a typo for the case when CONFIG_OMAP_32K_TIMER
      is not set.
      
      In dmtimer_read_sched_clock(), wrong argument was getting passed to
      __omap_dm_timer_read_counter() function call; instead of "&clksrc",
      we were passing "clksrc.io_base", which results into kernel crash.
      
      To reproduce kernel crash, just disable the CONFIG_OMAP_32K_TIMER config
      option (and DEBUG_LL) and build/boot the kernel.
      This will use dmtimer as a kernel clocksource and lead to kernel
      crash during boot  -
      
      [    0.000000] OMAP clocksource: GPTIMER2 at 26000000 Hz
      [    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every
      165191ms
      [    0.000000] Unable to handle kernel paging request at virtual address
      00030ef1
      [    0.000000] pgd = c0004000
      [    0.000000] [00030ef1] *pgd=00000000
      [    0.000000] Internal error: Oops: 5 [#1] SMP
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Not tainted  (3.3.0-rc1-11574-g0c76665-dirty #3)
      [    0.000000] PC is at dmtimer_read_sched_clock+0x18/0x4c
      [    0.000000] LR is at update_sched_clock+0x10/0x84
      [    0.000000] pc : [<c00243b8>]    lr : [<c0018684>]    psr: 200001d3
      [    0.000000] sp : c0641f38  ip : c0641e18  fp : 0000000a
      [    0.000000] r10: 151c3303  r9 : 00000026  r8 : 76276259
      [    0.000000] r7 : 00028547  r6 : c065ac80  r5 : 431bde82  r4 : c0655968
      [    0.000000] r3 : 00030ef1  r2 : fb032000  r1 : 00000028  r0 : 00000001
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc3982a
    • P
      bugs, x86: Fix printk levels for panic, softlockups and stack dumps · b0f4c4b3
      Prarit Bhargava 提交于
      rsyslog will display KERN_EMERG messages on a connected
      terminal.  However, these messages are useless/undecipherable
      for a general user.
      
      For example, after a softlockup we get:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Stack:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Call Trace:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
       d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89
      
      This happens because the printk levels for these messages are
      incorrect. Only an informational message should be displayed on
      a terminal.
      
      I modified the printk levels for various messages in the kernel
      and tested the output by using the drivers/misc/lkdtm.c kernel
      modules (ie, softlockups, panics, hard lockups, etc.) and
      confirmed that the console output was still the same and that
      the output to the terminals was correct.
      
      For example, in the case of a softlockup we now see the much
      more informative:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
       BUG: soft lockup - CPU4 stuck for 60s!
      
      instead of the above confusing messages.
      
      AFAICT, the messages no longer have to be KERN_EMERG.  In the
      most important case of a panic we set console_verbose().  As for
      the other less severe cases the correct data is output to the
      console and /var/log/messages.
      
      Successfully tested by me using the drivers/misc/lkdtm.c module.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: dzickus@redhat.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      b0f4c4b3
    • J
      x86: Properly parenthesize cmpxchg() macro arguments · fc395b92
      Jan Beulich 提交于
      Quite oddly, all of the arguments passed through from the top
      level macros to the second level which didn't need parentheses
      had them, while the only expression (involving a parameter)
      needing them didn't.
      
      Very recently I got bitten by the lack thereof when using
      something like "array + index" for the first operand, with
      "array" being an array more narrow than int.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/4F2183A9020000780006F3E6@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      fc395b92
    • G
      Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip" · af681cad
      Greg Kroah-Hartman 提交于
      This reverts commit 43cf7c0b as Paul
      wants to redo it.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Govindraj Raja <govindraj.r@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      af681cad
  12. 26 1月, 2012 4 次提交
    • J
      arch/arm/mach-imx/mach-mx53_ard.c: add missing iounmap · 945f82f2
      Julia Lawall 提交于
      Add missing iounmap in error handling code, in a case where the function
      already preforms iounmap on some other execution path.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      expression e;
      statement S,S1;
      int ret;
      @@
      e = \(ioremap\|ioremap_nocache\)(...)
      ... when != iounmap(e)
      if (<+...e...+>) S
      ... when any
          when != iounmap(e)
      *if (...)
         { ... when != iounmap(e)
           return ...; }
      ... when any
      iounmap(e);
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      945f82f2
    • F
      ARM: imx: iomux-v1.h: Fix build error due to __init annotation · 7c0c3454
      Fabio Estevam 提交于
      Fix the following build error found when building imx_v4_v5_defconfig:
      
        CC      arch/arm/mach-imx/mach-imx27ipcam.o
      In file included from arch/arm/plat-mxc/include/mach/iomux-mx27.h:23,
                       from arch/arm/mach-imx/mach-imx27ipcam.c:22:
      arch/arm/plat-mxc/include/mach/iomux-v1.h:99: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imx_iomuxv1_init'
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      7c0c3454
    • T
      OMAPDSS: HDMI: PHY burnout fix · c49d005b
      Tomi Valkeinen 提交于
      A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
      if the HDMI PHY is kept powered on when the cable is not connected.
      
      This patch solves the problem by adding hot-plug-detection into the HDMI
      IP driver. This is not a real HPD support in the sense that nobody else
      than the IP driver gets to know about the HPD events, but is only meant
      to fix the HW bug.
      
      The strategy is simple: If the display device is turned off by the user,
      the PHY power is set to OFF. When the display device is turned on by the
      user, the PHY power is set either to LDOON or TXON, depending on whether
      the HDMI cable is connected.
      
      The reason to avoid PHY OFF when the display device is on, but the cable
      is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
      "ticking" and thus the DISPC does not receive pixel clock from the HDMI
      IP. This would, for example, prevent any VSYNCs from happening, and
      would thus affect the users of omapdss. By using LDOON when the cable is
      disconnected we'll avoid the HW bug, but keep the HDMI working as usual
      from the user's point of view.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c49d005b
    • T
      OMAP: 4430SDP/Panda: add HDMI HPD gpio · aa74274b
      Tomi Valkeinen 提交于
      Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
      this GPIO in the board files.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      aa74274b