The local variable 'mode' is not necessary. We can determine the mode
by checking the cmd->convert_src and cmd->start_src. Do this instead
to clarify the code.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the cmd->convert_src == TRIG_TIMER the divisors needed to
generate the pacer time are calculated in the (*do_cmdtest) to
validate the cmd->convert_arg. The core always does the (*do_cmdtest)
before the (*do_cmd) so there is no reason to recalc the divisors.

Save the calculated divisors in the private data as 'next_divisor[12]'.
The (*do_cmd) then transfers them to the private data 'divisor[12]' so
that they can be used to set the timer for the command immediately or
later when the cmd->start_src is TRIG_EXT (mode 2 in this driver).
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This member of the private data is is not necessary. We can just check the
cmd->flags for TRIG_WAKE_EOS when needed. Remvoe the member.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This member of the private data is set to 0 but never used. Just remove it.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This member of the private data is not necessary. We can determine if
the analog input command is neverending by checking the cmd->stop_src:

  TRIG_COUNT -> !neverending_ai
  TRIG_NONE -> neverending_ai

Do that instead and remove the unnecessary member.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The chanlist is checked in Step 5 of the (*do_cmdtest) there is no
reason to check it again in the (*do_cmd). The only reason its done
again is to get the actual 'seglen', the non-repeating length of the
chanlist.

Save the 'seglen' found by pci171x_ai_check_chanlist() in the private
data and use that in the (*do_cmd). Rename the private data member to
clarify it. Also, remove the unused 'act_chanlist_pos' member from the
private data.

Refactor the error handling in pci171x_ai_check_chanlist() so it returns
and errno for failure and 0 for success.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Tidy up this function to clarify what the chanlist is being checked for.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a patch to fix coding style
warnings found by checkpatch.pl tool
Signed-off-by: NRaghavendra Chandra Ganiga <ravi23ganiga@gmail.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This driver no longer reads the eeprom to find the board specific data,
all the necessary data is in the boardinfo. Use the boardinfo directly
instead of passing through devpriv->s_EeParameters.
Signed-off-by: NChase Southwood <chase.southwood@gmail.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The i_IorangeBase1, i_PCIEeprom, and pc_EepromChip data in the boardinfo
was only needed to work out the usage of the PCI bars.  Now that that is
squared away, this info is no longer needed and can be removed.
Signed-off-by: NChase Southwood <chase.southwood@gmail.com>
Reviewed-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This driver only uses PCI bar 0 (devpriv->i_IobaseAmcc), and PCI bar 1
(dev->iobase), don't bother reading the unused PCI bars.
Signed-off-by: NChase Southwood <chase.southwood@gmail.com>
Reviewed-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This board always has 32 digital inputs. Remove the test when
initializing the subdevice.

Also, since this board is the only one supported by this driver,
remove the boardinfo about the digital inputs and just use the
data directly in the subdevice init.
Signed-off-by: NChase Southwood <chase.southwood@gmail.com>
Reviewed-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This include is no longer needed.
Signed-off-by: NChase Southwood <chase.southwood@gmail.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reading the eeprom on this board is not necessary.  All information
required is in the boardinfo.

Remove the eeprom support code which is not really useful here.
Signed-off-by: NChase Southwood <chase.southwood@gmail.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some board pointer are assigned twice via comedi_board() in the comedi low
level driver attach functions. Remove the duplicate assignment from the
variable definition where the pointer is not used anyway until assigned later
in the function when dev->board_ptr, that comedi_board() relies on, is setup
correctly.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Reviewed-by: NIan Abbott <abbotti@mev.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a bug fix that has been lurking in the Google tree but not pushed
upstream.

From: Octavian Purdila <octavian.purdila@intel.com>

The memory region is already reserved in goldfish_init() during
platform init.
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Signed-off-by: NJun Tian <jun.j.tian@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The base code imported from the Google tree is ifdef heaven. Prepare to fix
this by adding a helper function.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable the 64-bit nand data support in the goldfish nand driver.
Signed-off-by: NJun Tian <jun.j.tian@intel.com>
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable the 64-bit goldfish audio driver.
Support 64-bit buffer address and data read/write.
Signed-off-by: NJun Tian <jun.j.tian@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes "Missing a blank line after declarations" warnings.
Signed-off-by: NSeunghun Lee <waydi1@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The white space was all wrong here.  The case statements were indented
too far.  The if else blocks weren't indented at all.  There was a break
statement aligned with the else block and it confused my static checker
because "were curly braces intended" so that the break statement was
only on the else side?  Also I removed some commented out code.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There were a couple lines which were not indented far enough and it was
confusing.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The for loop body wasn't indented so it upset my static checker.  Also
I removed an obsolete comment on the same line.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

"*(p + 1)" and "len" are the same thing.  For reviewers who don't know
that, then this code is worrying because we cap "len", but pass
"*(p + 1)" to memcpy().

I have changed the code to use "len" throughout.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fold a line to make it less than 80 characters
Signed-off-by: NSarath Lakshman <sarathlakshman@slynux.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Change old way of ops->setsockopt or ops->getsockopt in kernel
to kernel_setsockopt or kernel_getsockopt.
Signed-off-by: NFredrick John Berchmans <fredrickprashanth@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If CONFIG_FS_POSIX_ACL=n:

drivers/staging/lustre/lustre/llite/xattr.c: In function 'll_setxattr_common':
drivers/staging/lustre/lustre/llite/xattr.c:115:27: warning: unused variable 'rce' [-Wunused-variable]
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/staging/lustre/lustre/llite/rw26.c: In function 'll_direct_IO_26':
drivers/staging/lustre/lustre/llite/rw26.c:383:2: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'ssize_t' [-Wformat]
drivers/staging/lustre/lustre/llite/rw26.c:383:2: warning: format '%lu' expects argument of type 'long unsigned int', but argument 10 has type 'ssize_t' [-Wformat]

Join the quoted string split across lines to fix a checkpatch warning while
we're at it.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When CONFIG_SMP=n:

drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h:58:31: fatal error: libcfs/libcfs_cpu.h: No such file or directory

drivers/staging/lustre/lustre/libcfs/libcfs_cpu.c:78:1: error: redefinition of 'cfs_cpt_table_print'
drivers/staging/lustre/include/linux/libcfs/libcfs_cpu.h:109:1: note: previous definition of 'cfs_cpt_table_print' was here
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The obd_ioctl_getdata() function caps "data->ioc_len" at
OBD_MAX_IOCTL_BUFFER and then calls this obd_ioctl_is_invalid() to check
that the other values inside data are valid.

There are several lengths inside data but when they are added together
they must not be larger than "data->ioc_len".  The checks against
"(data->ioc_inllen1 > (1<<30))" are supposed to ensure that the addition
does not have an integer overflow.  But "(1<<30) * 4" actually can
overflow 32 bits, so the checks are insufficient.

I have changed it to "> OBD_MAX_IOCTL_BUFFER" instead.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Pointer 'ni' checked for NULL at line 1569 may be passed to
function and may be dereferenced there by passing argument 1 to
function 'lnet_ni_notify_locked' at line 1621.
found by Klocwork Insight tool
Signed-off-by: NOleg Drokin <oleg.drokin@intel.com>
CC: Dmitry Eremin <dmitry.eremin@intel.com>
CC: Liang Zhen <liang.zhen@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Null pointer 'cp' that comes from line 2544 may be dereferenced
at line 2618.
found by Klocwork Insight tool
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NIsaac Huang <he.huang@intel.com>
Signed-off-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Local variable 'hash' is never used
found by Klocwork Insight tool
Signed-off-by: NDmitry Eremin <dmitry.eremin@intel.com>
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629Reviewed-by: NJohn L. Hammond <john.hammond@intel.com>
Reviewed-by: NIsaac Huang <he.huang@intel.com>
Signed-off-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It should never be NULL because our interface list is up to date,
and even if it does, we'll just crash anyway so we are no better off.
Signed-off-by: NOleg Drokin <oleg.drokin@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Insted of meddling directly in process environment variables
(which is also not possible on certain platforms due to not exported
symbols), create jobid_name proc file to represent this info
(to be filled by job scheduler epilogue).
Signed-off-by: NOleg Drokin <oleg.drokin@intel.com>
CC: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In ll_ioctl_fiemap(), a user-supplied value is used to calculate a
length of a buffer which is later allocated with user data.
Signed-off-by: NVitaly Osipov <vitaly.osipov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The asm-generic, big-endian version of zero_bytemask creates a mask of
bytes preceding the first zero-byte by left shifting ~0ul based on the
position of the first zero byte.

Unfortunately, if the first (top) byte is zero, the output of
prep_zero_mask has only the top bit set, resulting in undefined C
behaviour as we shift left by an amount equal to the width of the type.
As it happens, GCC doesn't manage to spot this through the call to fls(),
but the issue remains if architectures choose to implement their shift
instructions differently.

An example would be arch/arm/ (AArch32), where LSL Rd, Rn, #32 results
in Rd == 0x0, whilst on arch/arm64 (AArch64) LSL Xd, Xn, #64 results in
Xd == Xn.

Rather than check explicitly for the problematic shift, this patch adds
an extra shift by 1, replacing fls with __fls. Since zero_bytemask is
never called with a zero argument (has_zero() is used to check the data
first), we don't need to worry about calling __fls(0), which is
undefined.

Cc: <stable@vger.kernel.org>
Cc: Victor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This merges the patch to fix possible loss of dirty bit on munmap() or
madvice(DONTNEED).  If there are concurrent writers on other CPU's that
have the unmapped/unneeded page in their TLBs, their writes to the page
could possibly get lost if a third CPU raced with the TLB flush and did
a page_mkclean() before the page was fully written.

Admittedly, if you unmap() or madvice(DONTNEED) an area _while_ another
thread is still busy writing to it, you deserve all the lost writes you
could get.  But we kernel people hold ourselves to higher quality
standards than "crazy people deserve to lose", because, well, we've seen
people do all kinds of crazy things.

So let's get it right, just because we can, and we don't have to worry
about it.

* safe-dirty-tlb-flush:
  mm: split 'tlb_flush_mmu()' into tlb flushing and memory freeing parts