ioat/dca: Use dev_is_pci() to check whether it is pci device

Use PCI standard marco dev_is_pci() instead of directly compare
pci_bus_type to check whether it is pci device.

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
dma: mv_xor: Add DMA API error checks

This commit adds proper error checking for various DMA API calls,
as reported by DMA_API_DEBUG=y.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
drivers: dma: Mark functions as static in dma_v3.c

Mark the functions ioat3_prep_xor_val(), ioat3_prep_pq_val() and
ioat3_prep_pqxor_val() as static in dma_v3.c because they are not used
outside this file.

This eliminates the following warnings in dma_v3.c:
drivers/dma/ioat/dma_v3.c:741:1: warning: no previous prototype for ‘ioat3_prep_xor_val’ [-Wmissing-prototypes]
drivers/dma/ioat/dma_v3.c:1092:1: warning: no previous prototype for ‘ioat3_prep_pq_val’ [-Wmissing-prototypes]
drivers/dma/ioat/dma_v3.c:1134:1: warning: no previous prototype for ‘ioat3_prep_pqxor_val’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
drivers: dma: Include appropriate header file in dca.c

Includes an appropriate header file dma_v2.h in ioat/dca.c because
functions ioat2_dca_init() and ioat3_dca_init() have their function
declarations in dma_v2.h.

This eliminates the following warning in ioat/dca.c:
drivers/dma/ioat/dca.c:410:22: warning: no previous prototype for ‘ioat2_dca_init’ [-Wmissing-prototypes]
drivers/dma/ioat/dca.c:624:22: warning: no previous prototype for ‘ioat3_dca_init’ [-Wmissing-prototypes]

Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
ioat: Use pci_enable_msix_exact() instead of pci_enable_msix()

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Function pci_enable_msix() returns a tri-state value while
pci_enable_msi_exact() is a canonical zero/-errno variant.
The former is being phased out in favor of the latter.
In case of 'ioat' there (should be) no difference.

Cc: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
dma: mv_xor: Remove unneeded mv_xor_clean_completed_slots() call

In mv_xor_status(), we are currently calling mv_xor_clean_completed_slots()
when the transaction is complete (the cookie status is DMA_COMPLETE).
However, a completed status means that mv_xor_slot_cleanup() was called,
which cleans the completed slots.

In other words, there's nothing to cleanup for a completed transaction in
mv_xor_status(). Remove the unneeded call to mv_xor_clean_completed_slots().

Reported-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
dma: mv_xor: Remove all callers of mv_xor_slot_cleanup()

In order to simplify the code, remove all the calls to the locked
mv_xor_slot_cleanup() and instead use the unlocked version only,

It's less error prone to have just one function, and require the caller
to ensure proper locking.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
dma: mv_xor: Rename __mv_xor_slot_cleanup() to mv_xor_slot_cleanup()

Now that mv_xor_slot_cleanup() has no remaining callers, we remove it
and rename __mv_xor_slot_cleanup() to mv_xor_slot_cleanup().

We take this opportunity to add a comment that makes it clear that the
channel spinlock should be held before calling mv_xor_slot_cleanup().

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
dmaengine: fix xor sources continuation

the partial xor result must be kept until the next
tx is generated.

Cc: <stable@vger.kernel.org>
Signed-off-by: Xuelin Shi <xuelin.shi@freescale.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
ioat: Use time_before_jiffies()

To be future-proof and for better readability the time comparisons are modified
to use time_before_jiffies() instead of plain, error-prone math.

Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de>
[djbw: use time_before_jiffies() to make argument order more clear]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
dmatest: prevent memory leakage on error path in thread

When we fail to allocate memory for thread->srcs or thread->dsts and src_cnt or
dst_cnt great than 1 we leak memory on error path. This patch fixes the issue.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
dmaengine maintainer update

I am stepping down as dmaengine maintainer as the bulk of the activity
in the subsystem is primarily targeted at the slave-dma case handled by
Vinod, and I have recently been unable to give the few patches I do
receive timely review.  There is still an item in my backlog to
eliminate the async_tx api and the constraints it poses on dmaengine
drivers, but I need not hold on to the maintainer role in the meantime.
I will still be subscribed to dmaengine@vger.kernel.org to answer
questions, but all patches should be routed through Vinod unless/until a
maintainer for the non-slave-dma use case arrives.  It is non-entirely
clear at this point that there is enough work going forward for a
separate maintainer of the pure-offload case.

Ongoing development of the ioatdma driver is handled by Dave.  I'm still
interested in reviewing ioatdma patches, but he is the primary
maintainer/developer going forward.

IOP platforms are not generating any traffic in my inbox, but if a patch
did arrive I've long since lost access to hardware.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
module: rename KERNEL_PARAM_FL_NOARG to avoid confusion

Make it clear this is about kernel_param_ops, not kernel_param (which
will soon have a flags field of its own). No functional changes.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Jon Mason <jon.mason@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
module: make it possible to have unsafe, tainting module params

Add flags field to struct kernel_params, and add the first flag: unsafe
parameter. Modifying a kernel parameter with the unsafe flag set, either
via the kernel command line or sysfs, will issue a warning and taint the
kernel.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Jon Mason <jon.mason@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
module: add module_param_unsafe and module_param_named_unsafe

Add the helpers to be used by modules wishing to expose unsafe debugging
or testing module parameters that taint the kernel when set.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Jon Mason <jon.mason@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
drm/i915: taint the kernel if unsafe module parameters are set

Taint the kernel if the semaphores, enable_rc6, enable_fbc, or ppgtt
module parameters are modified. These module parameters are for
debugging and testing only, and should never be changed from their
platform specific default values by the users. We do not provide support
for people enabling all the experimental features. Make this clear by
tainting the kernel if the parameters are set.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
param: check for tainting before calling set op.

This means every set op doesn't need to call it, and it can move into
params.c.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
modpost: reduce visibility of symbols and constify r/o arrays

Internally used symbols of modpost don't need to be externally visible;
make them static. Also constify the string arrays so they resist in the
r/o section instead of being runtime writable.

Those changes lead to a small size reduction as can be seen below:

   text    data     bss     dec     hex filename
  51381    2640   12416   66437   10385 scripts/mod/modpost.old
  51765    2224   12416   66405   10365 scripts/mod/modpost.new

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
modpost: simplify file name generation of *.mod.c files

Avoid the variable length array (vla), just use PATH_MAX instead.
This not only makes this code clang friedly, it also leads to a
code size reduction:

   text    data     bss     dec     hex filename
  51765    2224   12416   66405   10365 scripts/mod/modpost.old
  51677    2224   12416   66317   1030d scripts/mod/modpost.new

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
modsign: lookup lines ending in .ko in .mod files

This does the same as commit ef591a5 (scripts/Makefile.modpost: error
in finding modules from .mod files), but for scripts/Makefile.modsign

Maybe we should also apply to Makefile.modsign and Makefile.modinst
the change applied to Makefile.modpost by commit ea4054a (modpost:
handle huge numbers of modules) ?

Reviewed-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Bertrand Jacquin <beber@meleeweb.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>