1. TRCRSCTLRn - Resource Selection Control Registers n=0~1 are reserved,
   we shouldn't access them.
2. The max number of 'n' here is defined in TRCIDR4.NUMRSPAIR whoes value
   indicates the number of resource selection *pairs*, and 0 indicates
   one resource selection pair, 1 indicates two pairs, and so on ...

So, the total number of resource selection control registers which we can
access is (TRCIDR4.NUMRSPAIR * 2)
Signed-off-by: NChunyan Zhang <zhang.chunyan@linaro.org>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is needed due to the duplicated iommu stuff to help with the merge
and to prevent future issues.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert 'commit 353649e5 ("iommu: Allow iova to be used without
requiring IOMMU_SUPPORT"). This commit is made unnecessary by
'commit ac6d83cc ("misc: mic: Fix SCIF build failure with
IOMMU_SUPPORT disabled") and will create a conflict upon merging
with 4.3-rc4. The correct long term solution is to move the iova
library from drivers/iommu into lib/iova which will be done in
a future patch.

Cc: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patches makes following changes to omap_hdq driver
 - Enable 1-wire mode.
 - Implement w1_triplet callback to facilitate search rom
   procedure and auto detection of 1-wire slaves.
 - Proper enabling and disabling of interrupt.
 - Cleanups (formatting and return value checks).

HDQ mode remains unchanged.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
Cc: Jonathan Corbet <corbet@lwn.net>
CC: Tony Lindgren <tony@atomide.com>
Cc: Vignesh R <vigneshr@ti.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Fabian Frederick <fabf@skynet.be>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, memsetting and kfreeing the device is bad behaviour.  The
device will have a reference count of 1 and hence can cause trouble
because it has kfree'd.  Proper way to handle a failed device_register is
to call put_device right after it fails.
Signed-off-by: NLevente Kurusa <levex@linux.com>
Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use kstrdup instead of kmalloc and strncpy.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Acked-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SCIF depends on IOVA which requires IOMMU_SUPPORT to be enabled.
The long term fix is to move IOVA from drivers/iommu to lib/
but this current patch should fix the reported issue.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add myself as a maintainer for the Intel(R) Trace Hub framework
and drivers.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Parallel Trace Interface (PTI) unit is a trace output device that sends
data over a PTI port.

The driver provides interfaces to configure bus width, bus clock divider
and mode. Tracing is enabled via output device's "active" attribute.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Memory Storage Unit (MSU) is a trace output device that collects trace
data to system memory. It consists of 2 independent Memory Storage
Controllers (MSCs).

This driver provides userspace interfaces to configure in-memory tracing
parameters, such as contiguous (high-order allocation) buffer or multiblock
(scatter list) buffer mode, wrapping (data overwrite) and number and sizes
of windows in multiblock mode. Userspace can read the buffers via mmap()ing
or read()ing of the corresponding device node.
Signed-off-by: NLaurent Fert <laurent.fert@intel.com>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Software Trace Hub (STH) is a trace source device in the Intel TH
architecture, it generates data that then goes through the switch into
one or several output ports.

STH collects data from software sources using the stm device class
abstraction.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Global Trace Hub (GTH) is the central component of Intel TH architecture;
it carries out switching between the trace sources and trace outputs, can
enable/disable tracing, perform STP encoding, internal buffering, control
backpressure from outputs to sources and so on.

This property is also reflected in the software model; GTH (switch) driver
is required for the other subdevices to probe, because it matches trace
output devices against its output ports and configures them accordingly.

It also implements an interface for output ports to request trace enabling
or disabling and a few other useful things.

For userspace, it provides an attribute group "masters", which allows
configuration of per-master trace output destinations for up to master 255
and "256+" meaning "masters 256 and above". It also provides an attribute
group to discover and configure some of the parameters of its output ports,
called "outputs". Via these the user can set up data retention policy for
an individual output port or check if it is in reset state.
Signed-off-by: NLaurent Fert <laurent.fert@intel.com>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds basic support for PCI-based Intel TH devices. It requests
2 bars (configuration registers for the subdevices and STH channel MMIO
region) and calls into Intel TH core code to create the bus with subdevices
etc.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel(R) Trace Hub (TH) is a set of hardware blocks (subdevices) that
produce, switch and output trace data from multiple hardware and
software sources over several types of trace output ports encoded
in System Trace Protocol (MIPI STPv2) and is intended to perform
full system debugging.

For these subdevices, we create a bus, where they can be discovered
and configured by userspace software.

This patch creates this bus infrastructure, three types of devices
(source, output, switch), resource allocation, some callback mechanisms
to facilitate communication between the subdevices' drivers and some
common sysfs attributes.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a simple stm_source class device driver (kernelspace stm trace
source) that registers a console and sends kernel messages over STM
devices.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a simple module that pretends to be an stm device and discards
all the data that comes in. Useful for testing stm class and its users.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add myself as a maintainer for the stm class framework.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A System Trace Module (STM) is a device exporting data in System Trace
Protocol (STP) format as defined by MIPI STP standards. Examples of such
devices are Intel(R) Trace Hub and Coresight STM.

This abstraction provides a unified interface for software trace sources
to send their data over an STM device to a debug host. In order to do
that, such a trace source needs to be assigned a pair of master/channel
identifiers that all the data from this source will be tagged with. The
STP decoder on the debug host side will use these master/channel tags to
distinguish different trace streams from one another inside one STP
stream.

This abstraction provides a configfs-based policy management mechanism
for dynamic allocation of these master/channel pairs based on trace
source-supplied string identifier. It has the flexibility of being
defined at runtime and at the same time (provided that the policy
definition is aligned with the decoding end) consistency.

For userspace trace sources, this abstraction provides write()-based and
mmap()-based (if the underlying stm device allows this) output mechanism.

For kernel-side trace sources, we provide "stm_source" device class that
can be connected to an stm device at run time.

Cc: linux-api@vger.kernel.org
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull strscpy string copy function implementation from Chris Metcalf.

Chris sent this during the merge window, but I waffled back and forth on
the pull request, which is why it's going in only now.

The new "strscpy()" function is definitely easier to use and more secure
than either strncpy() or strlcpy(), both of which are horrible nasty
interfaces that have serious and irredeemable problems.

strncpy() has a useless return value, and doesn't NUL-terminate an
overlong result.  To make matters worse, it pads a short result with
zeroes, which is a performance disaster if you have big buffers.

strlcpy(), by contrast, is a mis-designed "fix" for strlcpy(), lacking
the insane NUL padding, but having a differently broken return value
which returns the original length of the source string.  Which means
that it will read characters past the count from the source buffer, and
you have to trust the source to be properly terminated.  It also makes
error handling fragile, since the test for overflow is unnecessarily
subtle.

strscpy() avoids both these problems, guaranteeing the NUL termination
(but not excessive padding) if the destination size wasn't zero, and
making the overflow condition very obvious by returning -E2BIG.  It also
doesn't read past the size of the source, and can thus be used for
untrusted source data too.

So why did I waffle about this for so long?

Every time we introduce a new-and-improved interface, people start doing
these interminable series of trivial conversion patches.

And every time that happens, somebody does some silly mistake, and the
conversion patch to the improved interface actually makes things worse.
Because the patch is mindnumbing and trivial, nobody has the attention
span to look at it carefully, and it's usually done over large swatches
of source code which means that not every conversion gets tested.

So I'm pulling the strscpy() support because it *is* a better interface.
But I will refuse to pull mindless conversion patches.  Use this in
places where it makes sense, but don't do trivial patches to fix things
that aren't actually known to be broken.

* 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  tile: use global strscpy() rather than private copy
  string: provide strscpy()
  Make asm/word-at-a-time.h available on all architectures

Silences this static checker warning:

 drivers/spmi/spmi-pmic-arb.c:363
 pmic_arb_write_cmd() warn: always true condition
 '(opc <= 255) => (0-255 <= 255)'

Cc: Andy Gross <agross@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We don't want to swap bytes that we're reading and writing to the
FIFOs when we're running on a big-endian CPU. Doing so causes
problems like where the qcom-spmi-iadc driver can't detect the
type of device because the bytes are all mixed up. Use the raw IO
accessors for these API instead, and collapse pmic_arb_base_read()
into the byte reading API so that we aren't tempted to read non-FIFO
data like commands with that function.

Cc: Andy Gross <agross@codeaurora.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Get notified immediately when a balloon target is set, instead of waiting for
up to one second.

The up-to 1 second gap could be long enough to cause swapping inside of the
VM that receives the VM.
Acked-by: NAndy King <acking@vmware.com>
Signed-off-by: NXavier Deguillard <xdeguillard@vmware.com>
Tested-by: NSiva Sankar Reddy B <sankars@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unify the behavior of the first start of the balloon and a reset. Also on
unload, declare that the balloon driver does not have any capabilities
anymore.
Acked-by: NAndy King <acking@vmware.com>
Signed-off-by: NXavier Deguillard <xdeguillard@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

2m ballooning significantly reduces the hypervisor side (and guest side)
overhead of ballooning and unballooning.

hypervisor only:
      balloon  unballoon
4 KB  2 GB/s   2.6 GB/s
2 MB  54 GB/s  767 GB/s

Use 2 MB pages as the hypervisor is alwys 64bit and 2 MB is the smallest
supported super-page size.

The code has to run on older versions of ESX and old balloon drivers run on
newer version of ESX. Hence match the capabilities with the host before 2m
page ballooning could be enabled.
Signed-off-by: NXavier Deguillard <xdeguillard@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When VMware's hypervisor requests a VM to reclaim memory this is preferrably done
via ballooning. If the balloon driver does not return memory fast enough, more
drastic methods, such as hypervisor-level swapping are needed. These other methods
cause performance issues, e.g. hypervisor-level swapping requires the hypervisor to
swap in a page syncronously while the virtual CPU is blocked.

Hence it is in the interest of the VM to balloon memory as fast as possible. The
problem with doing this is that the VM might end up doing nothing else than
ballooning and the user might notice that the VM is stalled, esp. when the VM has
only a single virtual CPU.

This is less of a problem if the VM and the hypervisor perform balloon operations
faster. Also the balloon driver yields regularly, hence on a single virtual CPU
the Linux scheduler should be able to properly time-slice between ballooning and
other tasks.

Testing Done: quickly ballooned a lot of pages while wathing if there are any
perceived hickups (periods of non-responsiveness) in the execution of the
linux VM. No such hickups were seen.
Signed-off-by: NXavier Deguillard <xdeguillard@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This helps with debugging vmw_balloon behavior, as it is clear what
functionality is enabled.
Acked-by: NAndy King <acking@vmware.com>
Signed-off-by: NXavier Deguillard <xdeguillard@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of waiting for the next GET_TARGET command, we can react faster
by exploiting the fact that each hypervisor call also returns the
balloon target.
Signed-off-by: NXavier Deguillard <xdeguillard@vmware.com>
Acked-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NPhilip P. Moltmann <moltmann@vmware.com>
Acked-by: NAndy King <acking@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce a new capability to the driver that allow sending 512 pages in
one hypervisor call. This reduce the cost of the driver when reclaiming
memory.
Signed-off-by: NXavier Deguillard <xdeguillard@vmware.com>
Acked-by: NDmitry Torokhov <dtor@vmware.com>
Signed-off-by: NPhilip P. Moltmann <moltmann@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Just fix a typo in the code comment.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If kzalloc() fails then gms is NULL and we are returning NULL, but the
functions which called this function gru_register_mmu_notifier() are not
expecting NULL as the return. They are expecting either a valid pointer
or the error code in ERR_PTR.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Acked-by: NDimitri Sivanich <sivanich@sgi.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove the function tfh_restart() that is not used anywhere.

This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Acked-by: NDimitri Sivanich <sivanich@sgi.com>
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To be future-proof and for better readability the time comparisons are
modified to use time_before() instead of plain, error-prone math.
Signed-off-by: NManuel Schölling <manuel.schoelling@gmx.de>
Acked-by: NDimitri Sivanich <sivanich@sgi.com>
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds the SCIF kernel node QP control messages required to
enable SCIF RMAs. Examples of such node QP control messages include
registration, unregistration, remote memory allocation requests,
remote memory unmap and SCIF remote fence requests.

The patch also updates the SCIF driver with minor changes required to
enable SCIF RMAs by adding the new files to the build, initializing
RMA specific information during SCIF endpoint creation, reserving SCIF
DMA channels, initializing SCIF RMA specific global data structures,
adding the IOCTL hooks required for SCIF RMAs and updating RMA
specific debugfs hooks.
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: NNikhil Rao <nikhil.rao@intel.com>
Signed-off-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch implements the fence APIs required to synchronize
DMAs. SCIF provides an interface to return a "mark" for all DMAs
programmed at the instant the API was called. Users can then "wait" on
the mark provided previously by blocking inside the kernel. Upon
receipt of a DMA completion interrupt the waiting thread is woken
up. There is also an interface to signal DMA completion by polling for
a location to be updated via a "signal" cookie to avoid the interrupt
overhead in the mark/wait interface. SCIF allows programming fences on
both the local and the remote node for both the mark/wait or the fence
signal APIs.
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: NNikhil Rao <nikhil.rao@intel.com>
Signed-off-by: NJacek Lawrynowicz <jacek.lawrynowicz@intel.com>
Signed-off-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SCIF allows users to read from or write to registered remote memory
via CPU copies or DMA. The API verifies that both local and remote
windows are valid before initiating the CPU or DMA transfers. SCIF has
optimized algorithms for handling byte aligned as well as cache line
aligned DMA engines. A registration cache is maintained to avoid the
overhead of pinning pages repeatedly if buffers are reused. The
registration cache is invalidated upon receipt of MMU notifier
callbacks.  SCIF windows are destroyed and the pages are unpinned only
once all prior DMAs initiated using that window are drained. Users can
request synchronous DMA operations as well as tail byte ordering if
required. CPU copies are always performed synchronously.
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: NNikhil Rao <nikhil.rao@intel.com>
Signed-off-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch implements the SCIF mmap/munmap interface. A similar
capability is provided to kernel clients via the
scif_get_pages()/scif_put_pages() APIs. The SCIF mmap interface
queries to check if a window is valid and then remaps the local
virtual address to the remote physical pages. These mappings are
subsequently destroyed upon receipt of the VMA close operation or
scif_get_pages().  This functionality allows SCIF users to directly
access remote memory without any driver interaction once the mappings
are created thereby providing bare-metal PCIe latency. These mappings
are zapped to avoid RMA accesses from user space, if a Coprocessor is
reset.
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: NNikhil Rao <nikhil.rao@intel.com>
Signed-off-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds the implementation for operations performed on the
list of SCIF windows. Examples of such operations includes adding the
windows to the list of registered (or cached) windows, querying the
list of self or remote windows and unregistering windows. The query
operation is used by SCIF APIs which initiate DMAs, CPU copies or
fences to ensure that a window remains valid during a transfer.
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: NNikhil Rao <nikhil.rao@intel.com>
Signed-off-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>