1. 03 5月, 2011 4 次提交
    • W
      ARM: mach-stmp378x: remove mach · f295dc68
      Wolfram Sang 提交于
      This mach has not seen any updates since the initial inclusion besides
      generic cleanup. Furthermore:
      
      - The i.MX23 covered in mach-mxs is just a renamed version of the
        STMP378x.
      
      - mach-stmp378x has a lot of reinvented interfaces, leaking all sorts of
        mach-related includes into the drivers. One example is the dmaengine
        which does not use the linux dmaengine-API but some privately exported
        symbols. So drivers cannot be reused. mach-mxs does it better.
      
      - There is only one board defined (which I couldn't find any trace of
        despite being a development board). It has been converted to
        mach-mxs in a previous patch.
      
      Since the only user of this mach was converted, it means that
      mach-stmp378x can go.
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f295dc68
    • W
      ARM: mach-stmp37xx: remove mach · 76359658
      Wolfram Sang 提交于
      This mach has not seen any updates since the initial inclusion besides
      generic cleanup. Furthermore:
      
      - It has a lot of reinvented interfaces, leaking all sorts of
        mach-related includes into the drivers. One example is the dmaengine
        which does not use the linux dmaengine-API but some privately exported
        symbols. So, drivers cannot be reused. mach-mxs is very similar and
        does it better.
      
      - It can be doubted that this worked at all. Check the DMA routines in
        stmp37xx.c for copy/paste bugs. A lot of APBX-related stuff is
        actually writing into registers for APBH.
      
      - There is only one board defined (which I couldn't find any trace of
        despite being a development board). In this board, only two devices
        have resources, the debug uart and the application uart. Neither of
        those have the needed custom drivers merged (and never will). debug
        uart is amba-pl011 which has an in-kernel driver without the
        mach-specific-stuff. appuart has a driver which was introduced for
        mach-mxs, and this one is reusable for a properly done mach.
      
      So, this single board registers only unsupported devices and the
      generic code looks suspicious and has poor design. Delete this
      stuff. If there is interest, it is wiser to restart using
      mach-mxs.
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      76359658
    • W
      ARM: configs: add defconfig for mach-mxs · cde7c41f
      Wolfram Sang 提交于
      Covers MX23, MX28 and STMP378x.
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Cc: Shawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      cde7c41f
    • W
      ARM: mach-mxs: add stmp378x-devb · a98253e8
      Wolfram Sang 提交于
      STMP378x and MX23 are the same and just relabeled. There is a
      mach-stmp378x, however, it has a lot of reinvented interfaces, leaking
      all sorts of mach-specific functions into the drivers. One example is
      the dmaengine which does not use the linux dmaengine-API but some
      privately exported symbols. This makes generic use of the drivers
      impossible. mach-mxs does it better, so convert the board to mach-mxs.
      After that, it is possible to delete all stmp-specific code which should
      ease further ARM-consolidation.
      
      Compile tested only due to no hardware (seems not available anymore).
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a98253e8
  2. 29 4月, 2011 3 次提交
  3. 28 4月, 2011 2 次提交
  4. 27 4月, 2011 4 次提交
    • D
      perf, x86, nmi: Move LVT un-masking into irq handlers · 2bce5dac
      Don Zickus 提交于
      It was noticed that P4 machines were generating double NMIs for
      each perf event.  These extra NMIs lead to 'Dazed and confused'
      messages on the screen.
      
      I tracked this down to a P4 quirk that said the overflow bit had
      to be cleared before re-enabling the apic LVT mask.  My first
      attempt was to move the un-masking inside the perf nmi handler
      from before the chipset NMI handler to after.
      
      This broke Nehalem boxes that seem to like the unmasking before
      the counters themselves are re-enabled.
      
      In order to keep this change simple for 2.6.39, I decided to
      just simply move the apic LVT un-masking to the beginning of all
      the chipset NMI handlers, with the exception of Pentium4's to
      fix the double NMI issue.
      
      Later on we can move the un-masking to later in the handlers to
      save a number of 'extra' NMIs on those particular chipsets.
      
      I tested this change on a P4 machine, an AMD machine, a Nehalem
      box, and a core2quad box.  'perf top' worked correctly along
      with various other small 'perf record' runs.  Anything high
      stress breaks all the machines but that is a different problem.
      
      Thanks to various people for testing different versions of this
      patch.
      Reported-and-tested-by: NShaun Ruffell <sruffell@digium.com>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Link: http://lkml.kernel.org/r/1303900353-10242-1-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      CC: Cyrill Gorcunov <gorcunov@gmail.com>
      2bce5dac
    • M
      m68k/mm: Set all online nodes in N_NORMAL_MEMORY · 4aac0b48
      Michael Schmitz 提交于
      For m68k, N_NORMAL_MEMORY represents all nodes that have present memory
      since it does not support HIGHMEM.  This patch sets the bit at the time
      node_present_pages has been set by free_area_init_node.
      At the time the node is brought online, the node state would have to be
      done unconditionally since information about present memory has not yet
      been recorded.
      
      If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it
      uses this nodemask to setup per-cache kmem_cache_node data structures.
      
      This pach is an alternative to the one proposed by David Rientjes
      <rientjes@google.com> attempting to set node state immediately when
      bringing the node online.
      Signed-off-by: NMichael Schmitz <schmitz@debian.org>
      Tested-by: NThorsten Glaser <tg@debian.org>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      CC: stable@kernel.org
      4aac0b48
    • L
      Revert wrong fixes for common misspellings · e9c54999
      Lucas De Marchi 提交于
      These changes were incorrectly fixed by codespell. They were now
      manually corrected.
      Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
      e9c54999
    • I
      perf events, x86: Work around the Nehalem AAJ80 erratum · ec75a716
      Ingo Molnar 提交于
      On Nehalem CPUs the retired branch-misses event can be completely bogus,
      when there are no branch-misses occuring. When there are a lot of branch
      misses then the count is pretty accurate. Still, this leaves us with an
      event that over-counts a lot.
      
      Detect this erratum and work it around by using BR_MISP_EXEC.ANY events.
      These will also count speculated branches but still it's a lot more
      precise in practice than the architectural event.
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/n/tip-yyfg0bxo9jsqxd6a0ovfny27@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      ec75a716
  5. 26 4月, 2011 7 次提交
  6. 22 4月, 2011 4 次提交
    • P
      perf, x86: Update/fix Intel Nehalem cache events · f4929bd3
      Peter Zijlstra 提交于
      Change the Nehalem cache events to use retired memory instruction counters
      (similar to Westmere), this greatly improves the provided stats.
      
      Using:
      
      main ()
      {
              int i;
      
              for (i = 0; i < 1000000000; i++) {
                      asm("mov (%%rsp), %%rbx;"
                          "mov %%rbx, (%%rsp);" : : : "rbx");
              }
      }
      
      We find:
      
       $ perf stat --repeat 10 -e instructions:u -e l1-dcache-loads:u -e l1-dcache-stores:u ./loop_1b_loads+stores
        Performance counter stats for './loop_1b_loads+stores' (10 runs):
            4,000,081,056 instructions:u           #      0.000 IPC ( +-   0.000% )
            4,999,502,846 l1-dcache-loads:u          ( +-   0.008% )
            1,000,034,832 l1-dcache-stores:u         ( +-   0.000% )
               1.565184942  seconds time elapsed   ( +-   0.005% )
      
      The 5b is surprising - we'd expect 1b:
      
       $ perf stat --repeat 10 -e instructions:u -e r10b:u -e l1-dcache-stores:u ./loop_1b_loads+stores
        Performance counter stats for './loop_1b_loads+stores' (10 runs):
            4,000,081,054 instructions:u           #      0.000 IPC ( +-   0.000% )
            1,000,021,961 r10b:u                     ( +-   0.000% )
            1,000,030,951 l1-dcache-stores:u         ( +-   0.000% )
               1.565055422  seconds time elapsed   ( +-   0.003% )
      
      Which this patch thus fixes.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Link: http://lkml.kernel.org/n/tip-q9rtru7b7840tws75xzboapv@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      f4929bd3
    • C
      perf, x86: P4 PMU - Don't forget to clear cpuc->active_mask on overflow · 1ea5a6af
      Cyrill Gorcunov 提交于
      It's not enough to simply disable event on overflow the
      cpuc->active_mask should be cleared as well otherwise counter
      may stall in "active" even in real being already disabled (which
      potentially may lead to the situation that user may not use this
      counter further).
      
      Don pointed out that:
      
       " I also noticed this patch fixed some unknown NMIs
         on a P4 when I stressed the box".
      Tested-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Acked-by: NDon Zickus <dzickus@redhat.com>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Link: http://lkml.kernel.org/r/1303398203-2918-3-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      1ea5a6af
    • I
      x86, perf event: Turn off unstructured raw event access to offcore registers · b52c55c6
      Ingo Molnar 提交于
      Andi Kleen pointed out that the Intel offcore support patches were merged
      without user-space tool support to the functionality:
      
       |
       | The offcore_msr perf kernel code was merged into 2.6.39-rc*, but the
       | user space bits were not. This made it impossible to set the extra mask
       | and actually do the OFFCORE profiling
       |
      
      Andi submitted a preliminary patch for user-space support, as an
      extension to perf's raw event syntax:
      
       |
       | Some raw events -- like the Intel OFFCORE events -- support additional
       | parameters. These can be appended after a ':'.
       |
       | For example on a multi socket Intel Nehalem:
       |
       |    perf stat -e r1b7:20ff -a sleep 1
       |
       | Profile the OFFCORE_RESPONSE.ANY_REQUEST with event mask REMOTE_DRAM_0
       | that measures any access to DRAM on another socket.
       |
      
      But this kind of usability is absolutely unacceptable - users should not
      be expected to type in magic, CPU and model specific incantations to get
      access to useful hardware functionality.
      
      The proper solution is to expose useful offcore functionality via
      generalized events - that way users do not have to care which specific
      CPU model they are using, they can use the conceptual event and not some
      model specific quirky hexa number.
      
      We already have such generalization in place for CPU cache events,
      and it's all very extensible.
      
      "Offcore" events measure general DRAM access patters along various
      parameters. They are particularly useful in NUMA systems.
      
      We want to support them via generalized DRAM events: either as the
      fourth level of cache (after the last-level cache), or as a separate
      generalization category.
      
      That way user-space support would be very obvious, memory access
      profiling could be done via self-explanatory commands like:
      
        perf record -e dram ./myapp
        perf record -e dram-remote ./myapp
      
      ... to measure DRAM accesses or more expensive cross-node NUMA DRAM
      accesses.
      
      These generalized events would work on all CPUs and architectures that
      have comparable PMU features.
      
      ( Note, these are just examples: actual implementation could have more
        sophistication and more parameter - as long as they center around
        similarly simple usecases. )
      
      Now we do not want to revert *all* of the current offcore bits, as they
      are still somewhat useful for generic last-level-cache events, implemented
      in this commit:
      
        e994d7d2: perf: Fix LLC-* events on Intel Nehalem/Westmere
      
      But we definitely do not yet want to expose the unstructured raw events
      to user-space, until better generalization and usability is implemented
      for these hardware event features.
      
      ( Note: after generalization has been implemented raw offcore events can be
        supported as well: there can always be an odd event that is marginally
        useful but not useful enough to generalize. DRAM profiling is definitely
        *not* such a category so generalization must be done first. )
      
      Furthermore, PERF_TYPE_RAW access to these registers was not intended
      to go upstream without proper support - it was a side-effect of the above
      e994d7d2 commit, not mentioned in the changelog.
      
      As v2.6.39 is nearing release we go for the simplest approach: disable
      the PERF_TYPE_RAW offcore hack for now, before it escapes into a released
      kernel and becomes an ABI.
      
      Once proper structure is implemented for these hardware events and users
      are offered usable solutions we can revisit this issue.
      Reported-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1302658203-4239-1-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      b52c55c6
    • A
      perf: Support Xeon E7's via the Westmere PMU driver · b2508e82
      Andi Kleen 提交于
      There's a new model number public, 47, for Xeon E7 (aka Westmere EX).
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: a.p.zijlstra@chello.nl
      Link: http://lkml.kernel.org/r/1303429715-10202-1-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      b2508e82
  7. 21 4月, 2011 8 次提交
    • D
      [PARISC] set memory ranges in N_NORMAL_MEMORY when onlined · d9b41e0b
      David Rientjes 提交于
      When a DISCONTIGMEM memory range is brought online as a NUMA node, it
      also needs to have its bet set in N_NORMAL_MEMORY.  This is necessary for
      generic kernel code that utilizes N_NORMAL_MEMORY as a subset of N_ONLINE
      for memory savings.
      
      These types of hacks can hopefully be removed once DISCONTIGMEM is either
      removed or abstracted away from CONFIG_NUMA.
      
      Fixes a panic in the slub code which only initializes structures for
      N_NORMAL_MEMORY to save memory:
      
      	Backtrace:
      	 [<000000004021c938>] add_partial+0x28/0x98
      	 [<000000004021faa0>] __slab_free+0x1d0/0x1d8
      	 [<000000004021fd04>] kmem_cache_free+0xc4/0x128
      	 [<000000004033bf9c>] ida_get_new_above+0x21c/0x2c0
      	 [<00000000402a8980>] sysfs_new_dirent+0xd0/0x238
      	 [<00000000402a974c>] create_dir+0x5c/0x168
      	 [<00000000402a9ab0>] sysfs_create_dir+0x98/0x128
      	 [<000000004033d6c4>] kobject_add_internal+0x114/0x258
      	 [<000000004033d9ac>] kobject_add_varg+0x7c/0xa0
      	 [<000000004033df20>] kobject_add+0x50/0x90
      	 [<000000004033dfb4>] kobject_create_and_add+0x54/0xc8
      	 [<00000000407862a0>] cgroup_init+0x138/0x1f0
      	 [<000000004077ce50>] start_kernel+0x5a0/0x840
      	 [<000000004011fa3c>] start_parisc+0xa4/0xb8
      	 [<00000000404bb034>] packet_ioctl+0x16c/0x208
      	 [<000000004049ac30>] ip_mroute_setsockopt+0x260/0xf20
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: stable@kernel.org
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      d9b41e0b
    • D
      x86, numa: Fix cpu nodemasks for NUMA emulation and CONFIG_DEBUG_PER_CPU_MAPS · 7a6c6547
      David Rientjes 提交于
      The cpu<->node mappings under CONFIG_DEBUG_PER_CPU_MAPS=y
      when NUMA emulation is enabled is currently broken because it does
      not iterate through every emulated node and bind cpus that have
      affinity to it.
      
      NUMA emulation should bind each cpu to every local node to
      accurately represent the true NUMA topology of the underlying
      machine.
      
      debug_cpumask_set_cpu() needs to be fixed at the same time so
      that the debugging information that it emits shows the new
      cpumask of the node being assigned when the cpu is being added
      or removed.
      
      It can now take responsibility of setting or clearing the cpu
      itself to remove the need for duplicate code.
      
      Also change its last parameter, "enable", to have the correct bool
      type since it can only be true or false.
      
       -v2: Fix the return statements, by Kosaki Motohiro
      Acked-and-Tested-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.00.1104201918470.12634@chino.kir.corp.google.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      7a6c6547
    • D
      Revert "x86, NUMA: Fix fakenuma boot failure" · 37f8527d
      David Rientjes 提交于
      Andreas Herrmann reported that 7d6b4670 ("x86, NUMA: Fix fakenuma
      boot failure") causes certain physical NUMA topologies (for example
      AMD Magny-Cours) to move sibling cpus to a single node when in reality
      they are in separate domains.
      
      This may result in some nodes being completely void of cpus, which
      doesn't accurately represent the correct topology. The system will
      boot, but will have suboptimal NUMA performance.
      
      This commit was intended as a fix for NUMA emulation, but should
      not cause a regression for real NUMA machines as a side effect.
      
      ( There will be a separate fix for the numa-debug code, which
        will not affect physical topologies. )
      Reported-by: NAndreas Herrmann <herrmann.der.user@googlemail.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Acked-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.00.1104201918110.12634@chino.kir.corp.google.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      37f8527d
    • A
      OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. · f95440ca
      Avinash.H.M 提交于
      GPIO module expects the debounce clocks to be enabled during reset. It doesn't
      reset properly and timeouts are seen, if this clock isn't enabled during
      reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
      which the debounce clocks are enabled during reset.
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f95440ca
    • E
      OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL · a8ae645c
      Eduardo Valentin 提交于
      As per OMAP3 erratum (i671), ROM code adds extra latencies while
      restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1.
      
      This patch stores 0's in scratchpad content area corresponding to
      AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since
      it won't respect proper programing scheme.
      
      This register is then stored in prcm context. The saving and restore
      is now done by kernel side.
      
      Here follow the erratum description
      
      DESCRIPTION
      
      After OFF mode transition, among many restorations, the ROM Code restores the
      CM_AUTOIDLE_PLL register, and after that, it tries to relock the PER DPLL.
      
      In case the restoration data stored in scratchpad memory contains a field
      CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM Code restores and
      locks the PER DPLL does not respect the PER DPLL programming scheme.
      
      In that case, the DPLL might not lock. Meanwhile, when trying to lock the PER
      DPLL, the ROM Code does not hang. Only extra latencies are introduced at
      wake-up.
      
      WORKAROUND
      
      When saving the context-restore structure in scratchpad memory, in order to
      respect the PER DPLL programming scheme, it is advised to store 0 in the
      CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL field of the saved structure.
      
      After wake-up, the application should store in CM_AUTOIDLE_PLL register the
      right desired value.
      Signed-off-by: NEduardo Valentin <eduardo.valentin@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a8ae645c
    • E
      OMAP2+: PM: Fix the saving of CM_AUTOIDLE_PLL register on scratchpad area · 8bc2e98b
      Eduardo Valentin 提交于
      The saving of CCR.CM_AUTOIDLE_PLL is done in scratchpad area.
      
      However, in current code, the saving is done for CM_AUTOIDLE2_PLL
      (offset 0x34) instead of CM_AUTOIDLE_PLL (offset 0x30).
      
      This patch changes the code to save the correct register.
      Signed-off-by: NEduardo Valentin <eduardo.valentin@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      8bc2e98b
    • T
      OMAP4: clock data: Change DSS clock aliases · 2df122f5
      Tomi Valkeinen 提交于
      DSS driver has used fck and ick clocks on OMAP2/3 to get DSS HW up and
      running, and also to get the pixel clock's source clock rate from the
      fck.
      
      On OMAP4 the clock data is set up in a different way, as there's no ick,
      dss_fck points to a fake clock which just affects DSS's MODULEMODE, and
      dss_dss_clk if the DSS_FCK.
      
      >From DSS driver's point of view the dss_fck sounds like an ick, and
      dss_dss_clk is the fck. While this is not entirely correct from HW point
      of view, especially for the ick, configuring the clock aliases that way
      makes DSS "just work" with OMAP4's clock setup.
      
      In the (hopefully near) future DSS driver will be reworked to use
      pm_runtime support which should clean up the clock code.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      2df122f5
    • L
      mach-ux500: fix i2c0 device setup regression · cf568c58
      Linus Walleij 提交于
      Adding two sets of I2C devices to the same bus doesn't quite work,
      atleast not anymore. Stash one array and determine how much of it
      shall be added instead.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      cf568c58
  8. 20 4月, 2011 8 次提交
    • S
      xen: mask_rw_pte: do not apply the early_ioremap checks on x86_32 · ee176455
      Stefano Stabellini 提交于
      The two "is_early_ioremap_ptep" checks in mask_rw_pte are only used on
      x86_64, in fact early_ioremap is not used at all to setup the initial
      pagetable on x86_32.
      Moreover on x86_32 the two checks are wrong because the range
      pgt_buf_start..pgt_buf_end initially should be mapped RW because
      the pages in the range are not pagetable pages yet and haven't been
      cleared yet. Afterwards considering the pgt_buf_start..pgt_buf_end is
      part of the initial mapping, xen_alloc_pte is capable of turning
      the ptes RO when they become pagetable pages.
      
      Fix the issue and improve the readability of the code providing two
      different implementation of mask_rw_pte for x86_32 and x86_64.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ee176455
    • S
      xen: do not create the extra e820 region at an addr lower than 4G · 24bdb0b6
      Stefano Stabellini 提交于
      Do not add the extra e820 region at a physical address lower than 4G
      because it breaks e820_end_of_low_ram_pfn().
      
      It is OK for us to move the xen_extra_mem_start up and down because this
      is the index of the memory that can be ballooned in/out - it is memory
      not available to the kernel during bootup.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      24bdb0b6
    • C
      [S390] kvm-390: Let kernel exit SIE instruction on work · 9ff4cfb3
      Carsten Otte 提交于
      From: Christian Borntraeger <borntraeger@de.ibm.com>
      
      This patch fixes the sie exit on interrupts. The low level
      interrupt handler returns to the PSW address in pt_regs and not
      to the PSW address in the lowcore.
      Without this fix a cpu bound guest might never leave guest state
      since the host interrupt handler would blindly return to the
      SIE instruction, even on need_resched and friends.
      
      Cc: stable@kernel.org
      Signed-off-by: NCarsten Otte <cotte@de.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9ff4cfb3
    • H
      [S390] pfault: fix token handling · e35c76cd
      Heiko Carstens 提交于
      f6649a7e "[S390] cleanup lowcore access from external interrupts" changed
      handling of external interrupts. Instead of letting the external interrupt
      handlers accessing the per cpu lowcore the entry code of the kernel reads
      already all fields that are necessary and passes them to the handlers.
      The pfault interrupt handler was incorrectly converted. It tries to
      dereference a value which used to be a pointer to a lowcore field. After
      the conversion however it is not anymore the pointer to the field but its
      content. So instead of a dereference only a cast is needed to get the
      task pointer that caused the pfault.
      
      Fixes a NULL pointer dereference and a subsequent kernel crash:
      
      Unable to handle kernel pointer dereference at virtual kernel address (null)
      Oops: 0004 [#1] SMP
      Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc
                         loop qeth_l3 qeth vmur ccwgroup ext3 jbd mbcache dm_mod
                         dasd_eckd_mod dasd_diag_mod dasd_mod
      CPU: 0 Not tainted 2.6.38-2-s390x #1
      Process cron (pid: 1106, task: 000000001f962f78, ksp: 000000001fa0f9d0)
      Krnl PSW : 0404200180000000 000000000002c03e (pfault_interrupt+0xa2/0x138)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
      Krnl GPRS: 0000000000000000 0000000000000001 0000000000000000 0000000000000001
                 000000001f962f78 0000000000518968 0000000090000002 000000001ff03280
                 0000000000000000 000000000064f000 000000001f962f78 0000000000002603
                 0000000006002603 0000000000000000 000000001ff7fe68 000000001ff7fe48
      Krnl Code: 000000000002c036: 5820d010            l       %r2,16(%r13)
                 000000000002c03a: 1832                lr      %r3,%r2
                 000000000002c03c: 1a31                ar      %r3,%r1
                >000000000002c03e: ba23d010            cs      %r2,%r3,16(%r13)
                 000000000002c042: a744fffc            brc     4,2c03a
                 000000000002c046: a7290002            lghi    %r2,2
                 000000000002c04a: e320d0000024        stg     %r2,0(%r13)
                 000000000002c050: 07f0                bcr     15,%r0
      Call Trace:
       ([<000000001f962f78>] 0x1f962f78)
        [<000000000001acda>] do_extint+0xf6/0x138
        [<000000000039b6ca>] ext_no_vtime+0x30/0x34
        [<000000007d706e04>] 0x7d706e04
      Last Breaking-Event-Address:
        [<0000000000000000>] 0x0
      
      For stable maintainers:
      the first kernel which contains this bug is 2.6.37.
      Reported-by: NStephen Powell <zlinuxman@wowway.com>
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e35c76cd
    • J
      [S390] fix page table walk for changing page attributes · e4c031b4
      Jan Glauber 提交于
      The page table walk for changing page attributes used the wrong
      address for pgd/pud/pmd lookups if the range was bigger than
      a pmd entry. Fix the lookup by using the correct address.
      Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e4c031b4
    • J
      [S390] prng: prevent access beyond end of stack · c708c57e
      Jan Glauber 提交于
      While initializing the state of the prng only the first 8 bytes of
      random data where used, the second 8 bytes were read from the memory
      after the stack. If only 64 bytes of the kernel stack are used and
      CONFIG_DEBUG_PAGEALLOC is enabled a kernel panic may occur because of
      the invalid page access. Use the correct multiplicator to stay within
      the random data buffer.
      Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c708c57e
    • R
      PM: Add missing syscore_suspend() and syscore_resume() calls · 19234c08
      Rafael J. Wysocki 提交于
      Device suspend/resume infrastructure is used not only by the suspend
      and hibernate code in kernel/power, but also by APM, Xen and the
      kexec jump feature.  However, commit 40dc166c
      (PM / Core: Introduce struct syscore_ops for core subsystems PM)
      failed to add syscore_suspend() and syscore_resume() calls to that
      code, which generally leads to breakage when the features in question
      are used.
      
      To fix this problem, add the missing syscore_suspend() and
      syscore_resume() calls to arch/x86/kernel/apm_32.c, kernel/kexec.c
      and drivers/xen/manage.c.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      19234c08
    • T
      xtensa: Fixup irq conversion fallout and nmi_count · 2ea4db65
      Thomas Gleixner 提交于
      Some unnamed moron fatfingered the arguments of the irq chip callbacks
      to irq_chip instead of irq_data.
      
      While at it remove the nmi_count() print in arch_show_interrupts()
      which has been broken before the irq conversion already.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      2ea4db65