GenWQE used to call pci_enable_msi_block to allocate a desired number
of MSI's. If that was not possible pci_enable_msi_block returned with a
smaller number which might be possible to allocate. GenWQE then called
pci_enable_msi_block with that number.
Since commit a30d0108b
"GenWQE: Use pci_enable_msi_exact() instead of pci_enable_msi_block()"
pci_enable_msi_exact is used which fails if the desired number of MSI's
was not possible to allocate. Change GenWQE to use pci_enable_msi_range
to restore the old behavior.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch implements the callbacks and functions necessary to have EEH
recovery support.
It adds a config option to enable or disable explicit calls to trigger
platform specific mechanisms on error recovery paths. This option is
enabled by default only on PPC64 systems and can be overritten via
debugfs. If this option is enabled, on the error recovery path the
driver will call pci_channel_offline() to check for error condition and
issue non-raw MMIO reads to trigger early EEH detection in case of
hardware failures. This is necessary since the driver MMIO helper
funtions use raw accessors.
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Acked-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rc is not initialized, so genwqe_finish_queue() either returns -EIO or
garbage. Fortunately the return is not being checked by any callers,
so this has not yet caused any problems. Even so, it makes sense to
fix this small bug in case is is checked in future.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Needed to add wmb() before we send the DDCB for execution.
Without the syncronizing it failed on System p.
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The header which contained the declaration for kcalloc() was not
inlcuded.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fengguang Wu used CF=-D__CHECK_ENDIAN__ to check the GenWQE driver for
endian issues. Sparse found a couple of those. Most of them were caused
by not correctly handling __be64/32 and __u64/32. Those I was able to
fix with appropriate castings.
One more serious issue was the ATS entry in struct genwqe_ddcb_cmd.
The kernel expected it in big-endian, but the type was defined __u64.
I decided that it is better to keep the interface consistent using
host endian byte-odering instead of having a mixture. With this change
the kernel likes to see host endian byte order for the ATS entry. That
would have been an interface change, if someone would have used the
driver already. Since this is not the case, I hope it is ok to fix it
now.
For the genqwe_readq/writeq/readl/writel functions I enforced the casts.
It still complains, as far as I can see, about some copy_to/from_user()
usages:
CHECK char-misc/drivers/misc/genwqe/card_dev.c
char-misc/arch/x86/include/asm/uaccess.h:625:18: warning: incorrect type in argument 1 (different modifiers)
char-misc/arch/x86/include/asm/uaccess.h:625:18: expected void *<noident>
char-misc/arch/x86/include/asm/uaccess.h:625:18: got void const *from
char-misc/arch/x86/include/asm/uaccess.h:625:18: warning: incorrect type in argument 1 (different modifiers)
char-misc/arch/x86/include/asm/uaccess.h:625:18: expected void *<noident>
char-misc/arch/x86/include/asm/uaccess.h:625:18: got void const *from
char-misc/arch/x86/include/asm/uaccess.h:625:18: warning: incorrect type in argument 1 (different modifiers)
char-misc/arch/x86/include/asm/uaccess.h:625:18: expected void *<noident>
char-misc/arch/x86/include/asm/uaccess.h:625:18: got void const *from
char-misc/arch/x86/include/asm/uaccess.h:625:18: warning: incorrect type in argument 1 (different modifiers)
char-misc/arch/x86/include/asm/uaccess.h:625:18: expected void *<noident>
char-misc/arch/x86/include/asm/uaccess.h:625:18: got void const *from
CC [M] drivers/misc/genwqe/card_dev.o
CHECK char-misc/drivers/misc/genwqe/card_ddcb.c
char-misc/arch/x86/include/asm/uaccess.h:625:18: warning: incorrect type in argument 1 (different modifiers)
char-misc/arch/x86/include/asm/uaccess.h:625:18: expected void *<noident>
char-misc/arch/x86/include/asm/uaccess.h:625:18: got void const *from
char-misc/arch/x86/include/asm/uaccess.h:625:18: warning: incorrect type in argument 1 (different modifiers)
char-misc/arch/x86/include/asm/uaccess.h:625:18: expected void *<noident>
char-misc/arch/x86/include/asm/uaccess.h:625:18: got void const *from
CC [M] drivers/misc/genwqe/card_ddcb.o
LD [M] drivers/misc/genwqe/genwqe_card.o
I appreciate some help from you to figure out what is causig those, and
making a proposal how to fix them.
I included the missing header file to fix the
implicit-function-declaration warning when using dynamic_hex_dump.
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The GenWQE card itself provides access to a generic work queue into
which the work can be put, which should be executed, e.g. compression
or decompression request, or whatever the card was configured to do.
Each request comes with a set of input data (ASV) and will produce some
output data (ASIV). The request will also contain a sequence number,
some timestamps and a command code/subcode plus some fields for hardware-/
software-interaction.
A request can contain references to blocks of memory. Since the card
requires DMA-addresses of that memory, the driver provides two ways to
solve that task:
1) The drivers mmap() will allocate some DMAable memory for the user.
The driver has a lookup table such that the virtual userspace
address can properly be replaced and checked.
2) The user allocates memory and the driver will pin/unpin that
memory and setup a scatter gatherlist with matching DMA addresses.
Currently work requests are synchronous.
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Co-authors: Joerg-Stephan Vogt <jsvogt@de.ibm.com>,
Michael Jung <MIJUNG@de.ibm.com>,
Michael Ruettger <michael@ibmra.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
