Fix a memory leak in the genwqe_pin_mem() error path as called by
ioctl GENWQE_PIN_MEM. In case there is an error encountered when
mapping memory, the already allocated dma_mapping struct needs to
be freed correctly.

Detected by Coverity: CID 1162606.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Acked-by: NFrank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In case of error, the function device_create_with_groups()
returns ERR_PTR() and never returns NULL. The NULL test in
the return value check should be replaced with IS_ERR().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NFrank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dma_addr_t was not used, where it should have been used.
Some format strings were not optimal.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NFrank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of remaining bytes of a failing copy_to_user, the flash-update
ioctl is returning now -EFAULT. In addtion Dan discovered user triggerable
dev_errs(). Those I removed now from card_dev.c too. Some dev_infos()
were deleted and some others turned into dev_dbgs().
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFrank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: NGreg 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: NFrank Haverkamp <haver@linux.vnet.ibm.com>
Signed-off-by: NGreg 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: NFrank 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>