1. 25 6月, 2015 2 次提交
  2. 08 6月, 2015 1 次提交
  3. 07 6月, 2015 1 次提交
    • T
      arch/*/io.h: Add ioremap_wt() to all architectures · 556269c1
      Toshi Kani 提交于
      Add ioremap_wt() to all arch-specific asm/io.h headers which
      define ioremap_wc() locally. These headers do not include
      <asm-generic/iomap.h>. Some of them include <asm-generic/io.h>,
      but ioremap_wt() is defined for consistency since they define
      all ioremap_xxx locally.
      
      In all architectures without Write-Through support, ioremap_wt()
      is defined indentical to ioremap_nocache().
      
      frv and m68k already have ioremap_writethrough(). On those we
      add ioremap_wt() indetical to ioremap_writethrough() and defines
      ARCH_HAS_IOREMAP_WT in both architectures.
      
      The ioremap_wt() interface is exported to drivers.
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Elliott@hp.com
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: arnd@arndb.de
      Cc: hch@lst.de
      Cc: hmh@hmh.eng.br
      Cc: jgross@suse.com
      Cc: konrad.wilk@oracle.com
      Cc: linux-mm <linux-mm@kvack.org>
      Cc: linux-nvdimm@lists.01.org
      Cc: stefan.bader@canonical.com
      Cc: yigal@plexistor.com
      Link: http://lkml.kernel.org/r/1433436928-31903-9-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      556269c1
  4. 01 6月, 2015 3 次提交
  5. 27 5月, 2015 1 次提交
  6. 19 5月, 2015 4 次提交
  7. 18 5月, 2015 1 次提交
  8. 13 5月, 2015 1 次提交
  9. 23 4月, 2015 1 次提交
    • C
      sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly · acc455cf
      chris hyser 提交于
      commit 5f4826a362405748bbf73957027b77993e61e1af
      Author: chris hyser <chris.hyser@oracle.com>
      Date:   Tue Apr 21 10:31:38 2015 -0400
      
          sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly
      
          The current sparc kernel has no representation for sockets though tools
          like lscpu can pull this from sysfs. This patch walks the machine
          description cache and socket hierarchy and marks sockets as well as cores
          and threads such that a representative sysfs is created by
          drivers/base/topology.c.
      
          Before this patch:
              $ lscpu
              Architecture:          sparc64
              CPU op-mode(s):        32-bit, 64-bit
              Byte Order:            Big Endian
              CPU(s):                1024
              On-line CPU(s) list:   0-1023
              Thread(s) per core:    8
              Core(s) per socket:    1     <--- wrong
              Socket(s):             128   <--- wrong
              NUMA node(s):          4
              NUMA node0 CPU(s):     0-255
              NUMA node1 CPU(s):     256-511
              NUMA node2 CPU(s):     512-767
              NUMA node3 CPU(s):     768-1023
      
              After this patch:
              $ lscpu
              Architecture:          sparc64
              CPU op-mode(s):        32-bit, 64-bit
              Byte Order:            Big Endian
              CPU(s):                1024
              On-line CPU(s) list:   0-1023
              Thread(s) per core:    8
              Core(s) per socket:    32
              Socket(s):             4
              NUMA node(s):          4
              NUMA node0 CPU(s):     0-255
              NUMA node1 CPU(s):     256-511
              NUMA node2 CPU(s):     512-767
              NUMA node3 CPU(s):     768-1023
      
          Most of this patch was done by Chris with updates by David.
      Signed-off-by: NChris Hyser <chris.hyser@oracle.com>
      Signed-off-by: NDavid Ahern <david.ahern@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acc455cf
  10. 22 4月, 2015 2 次提交
  11. 19 4月, 2015 4 次提交
  12. 17 4月, 2015 3 次提交
  13. 15 4月, 2015 2 次提交
  14. 13 4月, 2015 2 次提交
  15. 09 4月, 2015 1 次提交
    • A
      jump_label: Allow asm/jump_label.h to be included in assembly · 55dd0df7
      Anton Blanchard 提交于
      Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
      Since these are kernel only headers, we don't need #ifdef
      __KERNEL__ so can simplify things a bit.
      
      If an architecture wants to use jump labels in assembly, it
      will still need to define a macro to create the __jump_table
      entries (see ARCH_STATIC_BRANCH in the powerpc asm/jump_label.h
      for an example).
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: benh@kernel.crashing.org
      Cc: catalin.marinas@arm.com
      Cc: davem@davemloft.net
      Cc: heiko.carstens@de.ibm.com
      Cc: jbaron@akamai.com
      Cc: linux@arm.linux.org.uk
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: liuj97@gmail.com
      Cc: mgorman@suse.de
      Cc: mmarek@suse.cz
      Cc: mpe@ellerman.id.au
      Cc: paulus@samba.org
      Cc: ralf@linux-mips.org
      Cc: rostedt@goodmis.org
      Cc: schwidefsky@de.ibm.com
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1428551492-21977-1-git-send-email-anton@samba.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      55dd0df7
  16. 08 4月, 2015 1 次提交
  17. 24 3月, 2015 1 次提交
    • D
      sparc64: Fix several bugs in memmove(). · 2077cef4
      David S. Miller 提交于
      Firstly, handle zero length calls properly.  Believe it or not there
      are a few of these happening during early boot.
      
      Next, we can't just drop to a memcpy() call in the forward copy case
      where dst <= src.  The reason is that the cache initializing stores
      used in the Niagara memcpy() implementations can end up clearing out
      cache lines before we've sourced their original contents completely.
      
      For example, considering NG4memcpy, the main unrolled loop begins like
      this:
      
           load   src + 0x00
           load   src + 0x08
           load   src + 0x10
           load   src + 0x18
           load   src + 0x20
           store  dst + 0x00
      
      Assume dst is 64 byte aligned and let's say that dst is src - 8 for
      this memcpy() call.  That store at the end there is the one to the
      first line in the cache line, thus clearing the whole line, which thus
      clobbers "src + 0x28" before it even gets loaded.
      
      To avoid this, just fall through to a simple copy only mildly
      optimized for the case where src and dst are 8 byte aligned and the
      length is a multiple of 8 as well.  We could get fancy and call
      GENmemcpy() but this is good enough for how this thing is actually
      used.
      Reported-by: NDavid Ahern <david.ahern@oracle.com>
      Reported-by: NBob Picco <bpicco@meloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2077cef4
  18. 20 3月, 2015 4 次提交
  19. 19 3月, 2015 4 次提交
    • B
      PCI: Cleanup control flow · 9e808eb6
      Bjorn Helgaas 提交于
      Return errors immediately so the straightline path is the normal,
      no-error path.  No functional change.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      9e808eb6
    • Y
      sparc/PCI: Claim bus resources before pci_bus_add_devices() · a0c8a4d9
      Yijing Wang 提交于
      Pci_claim_bus_resources() should be called before pci_bus_add_devices(), or
      driver may failed to load, because the resources had not claimed.
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      a0c8a4d9
    • Y
      PCI: Assign resources before drivers claim devices (pci_scan_root_bus()) · b97ea289
      Yijing Wang 提交于
      Previously, pci_scan_root_bus() created a root PCI bus, enumerated the
      devices on it, and called pci_bus_add_devices(), which made the devices
      available for drivers to claim them.
      
      Most callers assigned resources to devices after pci_scan_root_bus()
      returns, which may be after drivers have claimed the devices.  This is
      incorrect; the PCI core should not change device resources while a driver
      is managing the device.
      
      Remove pci_bus_add_devices() from pci_scan_root_bus() and do it after any
      resource assignment in the callers.
      
      Note that ARM's pci_common_init_dev() already called pci_bus_add_devices()
      after pci_scan_root_bus(), so we only need to remove the first call:
      
        pci_common_init_dev
          pcibios_init_hw
            pci_scan_root_bus
              pci_bus_add_devices        # first call
          pci_bus_assign_resources
          pci_bus_add_devices            # second call
      
      [bhelgaas: changelog, drop "root_bus" var in alpha common_init_pci(),
      return failure earlier in mn10300, add "return" in x86 pcibios_scan_root(),
      return early if xtensa platform_pcibios_fixup() fails]
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Richard Henderson <rth@twiddle.net>
      CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      CC: Matt Turner <mattst88@gmail.com>
      CC: David Howells <dhowells@redhat.com>
      CC: Tony Luck <tony.luck@intel.com>
      CC: Michal Simek <monstr@monstr.eu>
      CC: Ralf Baechle <ralf@linux-mips.org>
      CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      CC: Sebastian Ott <sebott@linux.vnet.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Chris Metcalf <cmetcalf@ezchip.com>
      CC: Chris Zankel <chris@zankel.net>
      CC: Max Filippov <jcmvbkbc@gmail.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      b97ea289
    • D
      sparc: Fix /proc/kcore · 3c08158e
      David S. Miller 提交于
      /proc/kcore investigates the "System RAM" elements in /proc/iomem to
      initialize it's memory tables.  Therefore we have to register them
      before it tries to do so.  kcore uses device_initcall() so let's
      use arch_initcall() for the registry.
      
      Also we need ARCH_PROC_KCORE_TEXT to get the virtual addresses of
      the kernel image correct.
      Reported-by: NDavid Ahern <david.ahern@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c08158e
  20. 13 3月, 2015 1 次提交