1. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  2. 01 4月, 2015 1 次提交
  3. 17 9月, 2013 1 次提交
  4. 04 9月, 2013 1 次提交
  5. 07 8月, 2013 1 次提交
  6. 02 8月, 2013 3 次提交
  7. 03 10月, 2012 1 次提交
  8. 25 9月, 2012 1 次提交
  9. 19 7月, 2012 1 次提交
    • C
      arch/tile: provide kernel support for the tilegx USB shim · d1cc1732
      Chris Metcalf 提交于
      This change adds support for accessing the USB shim from within the
      kernel.  Note that this change by itself does not allow the kernel
      to act as a host or as a device; it merely exposes the built-in on-chip
      hardware to the kernel.
      
      The <arch/usb_host.h> and <arch/usb_host_def.h> headers are empty at
      the moment because the kernel does not require any types or definitions
      specific to the tilegx USB shim; the generic USB core code is all we need.
      The headers are left in as stubs so that we don't need to modify the
      hypervisor header (drv_usb_host_intf.h) from upstream.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      d1cc1732
  10. 12 7月, 2012 4 次提交
    • C
      arch/tile: provide kernel support for the tilegx TRIO shim · bce5bbbb
      Chris Metcalf 提交于
      Provide kernel support for the tilegx "Transaction I/O" (TRIO) on-chip
      hardware.  This hardware implements the PCIe interface for tilegx;
      the driver changes to use TRIO for PCIe are in a subsequent commit.
      
      The change is layered on top of the tilegx GXIO IORPC subsystem.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      bce5bbbb
    • C
      arch/tile: provide kernel support for the tilegx mPIPE shim · 4875f69f
      Chris Metcalf 提交于
      The TILE-Gx chip includes a packet-processing network engine called
      mPIPE ("Multicore Programmable Intelligent Packet Engine").  This
      change adds support for using the mPIPE engine from within the
      kernel.  The engine has more functionality than is exposed here,
      but to keep the kernel code and binary simpler, this is a subset
      of the full API designed to enable standard Linux networking only.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      4875f69f
    • C
      arch/tile: common DMA code for the GXIO IORPC subsystem · 63697980
      Chris Metcalf 提交于
      The dma_queue support is used by both the mPipe (networking)
      and Trio (PCI) hardware shims on tilegx.  This common code is
      selected when either of those drivers is built.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      63697980
    • C
      arch/tile: introduce GXIO IORPC framework for tilegx · 37b82b5d
      Chris Metcalf 提交于
      The GXIO I/O RPC subsystem handles exporting I/O hardware resources to
      Linux and to applications running under Linux.
      
      For instance, memory which is made available for I/O DMA must be mapped
      by an I/O TLB; that means that such memory must be locked down by Linux,
      so that it is not swapped or otherwise reused, as long as those I/O
      TLB entries are active. Similarly, configuring direct hardware access
      introduces new validation requirements. If a user application registers
      memory, Linux must ensure that the supplied virtual addresses are valid,
      and turn them into client physical addresses. Similarly, when Linux then
      supplies those client physical addresses to the Tilera hypervisor, it
      must in turn validate those before turning them into the real physical
      addresses which are required by the hardware.
      
      To the extent that these sorts of activities were required on previous
      TILE architecture processors, they were implemented in a device-specific
      fashion. This meant that every I/O device had its own Tilera hypervisor
      driver, its own Linux driver, and in some cases its own user-level
      library support. There was a large amount of more-or-less functionally
      identical code in different places, particularly in the different Linux
      drivers. For TILE-Gx, this support has been generalized into a common
      framework, known as the I/O RPC framework or just IORPC.
      
      The two "gxio" directories (one for headers, one for sources) start
      with just a few files in each with this infrastructure commit, but
      after adding support for the on-board I/O shims for networking, PCI,
      USB, crypto, compression, I2CS, etc., there end up being about 20 files
      in each directory.
      
      More information on the IORPC framework is in the <hv/iorpc.h> header,
      included in this commit.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      37b82b5d