The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.

Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.

iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.

It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).

But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device.  This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.

	Unable to handle kernel NULL pointer dereference at virtual address 00000008
	pgd = c0004000
	[00000008] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
	Modules linked in:
	CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
	Hardware name: Xilinx Zynq Platform
	task: ef04f640 task.stack: ef050000
	PC is at iio_trigger_notify_done+0x30/0x68
	LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
	pc : [<c042d868>]    lr : [<c042d924>]    psr: 60000193
	sp : ef051bb8  ip : 00000000  fp : ef106400
	r10: c081d80a  r9 : ef3bfa00  r8 : 00000087
	r7 : ef051bec  r6 : 00000000  r5 : ef3bfa00  r4 : ee92ab00
	r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : ee97e400
	Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
	Control: 18c5387d  Table: 0000404a  DAC: 00000051
	Process swapper/0 (pid: 1, stack limit = 0xef050210)
	[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
	[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
	[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
	[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
	[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
	[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
	[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
	[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
	[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
	[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)

To fix this make sure that the trigger is fully initialized before
requesting the interrupt.

Fixes: ccd2b52f ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz@analog.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Functions for triggered buffer support are needed by this module.
If they are not defined accidentally by another driver, there's an error
thrown out while linking.

Add a select of IIO_BUFFER and IIO_TRIGGERED_BUFFER in the Kconfig file.
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Fixes: a8319593 ("iio: srf08: add triggered buffer support")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Since commit 152a6a88 ("staging:iio:accel:sca3000 move
to hybrid hard / soft buffer design.")
the buffer mechanism has changed and the
INDIO_BUFFER_HARDWARE flag has been unused.

Since commit 2d6ca60f ("iio: Add a DMAengine framework
based buffer")
the INDIO_BUFFER_HARDWARE flag has been re-purposed for
DMA buffers.

This driver has lagged behind these changes, and
in order for buffers to work, the INDIO_BUFFER_SOFTWARE
needs to be used.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Fixes: 2d6ca60f ("iio: Add a DMAengine framework based buffer")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Error handling in stm32h7_adc_enable routine doesn't unwind enable
sequence correctly. ADEN can only be cleared by hardware (e.g. by
writing one to ADDIS).
It's also better to clear ADRDY just after it's been set by hardware.

Fixes: 95e339b6 ("iio: adc: stm32: add support for STM32H7")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The external clock frequency was set only when selecting
the internal clock, which is fixed at 4.9152 Mhz.

This is incorrect, since it should be set when any of
the external clock or crystal settings is selected.

Added range validation for the external (crystal/clock)
frequency setting.
Valid values are between 2.4576 and 5.12 Mhz.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The labels and branching order of the error path of 'aspeed_adc_probe()'
are broken.
Re-order the labels and goto statements.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

This patch changes the indentation of the statements after case labels.
The linux coding guidelines do not explicitly mentiond this but pretty
much all existing code doesn't put any statements into the same line of
their belonging case labels. Therefore this adapts to the more usual style.

Please note that there is still a lot of > 80 character lines which will
cause checkpatch warnings. This patch does not intent to fix this
already existing issue.
Signed-off-by: Michael Panzlaff <michael.panzlaff@fau.de>
Signed-off-by: Tillmann Zipperer <tillmann.zipperer@fau.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The trailing semicolon is an empty statement that does nothing.
Removing it since it has no purpose.
Signed-off-by: Luis de Bethencourt <luisbg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt <luisbg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This fixes the checkpatch message:

    CHECK: Alignment should match open parenthesis
    #1380: FILE: drivers/staging/fbtft/fbtft-core.c:1380:
    +		dev_warn(dev,
    +			"no default functions for regwidth=%d and buswidth=%d\n",
Signed-off-by: Luis Gerhorst <linux-kernel@luisgerhorst.de>
Signed-off-by: Jonny Schaefer <schaefer.jonny@gmail.com>
Acked-by: Alexander Wuerstlein <arw@cs.fau.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes the misspelled constant to 'SWITCH_NO_ERR'.
Issue reported by checkpatch.pl
Signed-off-by: Sumit Pundir <pundirsumit11@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Several staging directories have TODO files that indicate a
subsystem will be removed in the future.

Using a status entry of "S:	Obsolete" helps indicate the
subsystem files should not be modified unnecessarily.

checkpatch also tests this setting and emits a warning that
the matching subsystem files should not be modified.

This might help avoid receiving patches that will be dropped.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt <luisbg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Casting a value returned by memory an allocation function is
not required and can be removed. Also add in a newline after before
the first statement. Code clean up as suggested by coccinelle.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes checkpatch warnings:

  CHECK: Alignment should match open parenthesis
Signed-off-by: Valentin Vidic <Valentin.Vidic@CARNet.hr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The dma mask var was defined as dma_addr_t but should be
u64. This showed as a sparse warning when building for 32 bit.
Fix it by changing type to u64 and drop the cast.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The debugfs interface defines stub function if debugfs is not
enabled, which were missing the 'static inline' qualifiers causing
sparse warnings.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the missing include of include file with function declarations.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove include files not needed for compilation.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The ccree driver source files were using an inconsistent
naming convention stemming from what the company was called
when they were added.

Move to a single consistent naming convention for better
code readability.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

LIBCFS_ALLOC
LIBCFS_ALLOC_ATOMIC
LIBCFS_ALLOC_POST
LIBCFS_CPT_ALLOC
LIBCFS_FREE

are no longer used, and so are removed.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

LIBCFS_APT_ALLOC() calls kvmalloc_node() with GFP_NOFS
which is not permitted.
Mostly, a kmalloc_node(GFP_NOFS) is appropriate, though occasionally
the allocation is large and GFP_KERNEL is acceptable, so
kvmalloc_node() can be used.

This patch introduces 4 alternatives to LIBCFS_CPT_ALLOC():
 kmalloc_cpt()
 kzalloc_cpt()
 kvmalloc_cpt()
 kvzalloc_cpt().

Each takes a size, gfp flags, and cpt number.

Almost every call to LIBCFS_CPT_ALLOC() passes lnet_cpt_table()
as the table.  This patch embeds that choice in the k*alloc_cpt()
macros, and opencode kzalloc_node(..., cfs_cpt_spread_node(..))
in the one case that lnet_cpt_table() isn't used.

When LIBCFS_CPT_ALLOC() is replaced, the matching LIBCFS_FREE()
is also replaced, with with kfree() or kvfree() as appropriate.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Just call kzalloc(GFP_ATOMIC) directly.
We don't need the warning on failure.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

this allocation is called from several places, but all are
during initialization, so GFP_NOFS is not needed.
So use kvmalloc and GFP_KERNEL.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The size of the data structure is primarily controlled
by the iovec size, which is limited to 256.
Entries in this vector are 12 bytes, so the whole
will always fit in a page.
So it is safe to use kmalloc (kvmalloc not needed).
So replace LIBCFS_ALLOC with kmalloc.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This allocation is reasonably small.
As the function is called "*_locked", it might not be safe
to perform a GFP_KERNEL allocation, so be safe and
use GFP_NOFS.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

These are not called from filesystem context, so use
GFP_KERNEL, not LIBCFS_ALLOC().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

None of these need GFP_NOFS so allocate directly.
Change matching LIBCFS_FREE() to kfree() or kvfree().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

None of these need to be GFP_NOFS, so use GFP_KERNEL explicitly
with kmalloc(), kvmalloc(), or kvmalloc_array().
Change matching LIBCFS_FREE() to kfree() or kvfree()
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When an allocation happens from process context rather than
filesystem context, it is best to use GFP_KERNEL rather than
LIBCFS_ALLOC() which always uses GFP_NOFS.
This include initialization during, or prior to, mount,
and code run from separate worker threads.

So for some of these cases, switch to kmalloc, kvmalloc, or
kvmalloc_array() as appropriate.
In some cases we preserve __GFP_ZERO (via kzalloc/kvzalloc), but in
others it is clear that allocated memory is immediately initialized.

In each case, the matching LIBCFS_FREE() is converted to
kfree() or kvfree()

This is just a subset of locations that need changing.
As there are quite a lot, I've broken them up into several
ad-hoc sets to avoid review-fatigue.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The buffers allocated in router_proc are to temporarily
hold strings created for procfs files.
So they do not need to be zeroed and are safe to use
GFP_KERNEL.
So use kmalloc() directly except in two cases where it
isn't trivial to confirm that the size is always small.
In those cases, use kvmalloc().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

All of the "name" buffers here are at most LST_NAME_SIZE+1
bytes, so 33 bytes at most.
They are only used temporarily during the life of the function
that allocates them.
So it is much simpler to just allocate on the stack.
Worst case is lst_tet_add_ioct(), which allocates
3 for these which 99 bytes on the stack, instead of the 24 that would
have been allocated for 64-bit pointers.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

So that we can use the common cpumask allocation functions,
switch to cpumask_var_t.
We need to be careful not to free a cpumask_var_t until the
variable has been initialized, and it cannot be initialized
directly.
So we must be sure either that it is filled with zeros, or
that zalloc_cpumask_var() has been called on it.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

All usages of the form
  LIBCFS_ALLOC(variable, sizeof(variable))
or
  LIBCFS_ALLOC(variable, sizeof(variable's-type))

are changed to
  variable = kzalloc(sizeof(...), GFP_NOFS);

Similarly, all
   LIBCFS_FREE(variable, sizeof(variable))
become
   kfree(variable);

None of these need the vmalloc option, or any of the other minor
benefits of LIBCFS_ALLOC().
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes checkpatch warnings:

  CHECK: Prefer using the BIT macro
Signed-off-by: Valentin Vidic <Valentin.Vidic@CARNet.hr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed coding style issue regarding null comparison at multiple lines.
Issue reported by checkpatch.pl
Signed-off-by: Sumit Pundir <pundirsumit11@gmail.com>
Acked-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Syzbot reported a warning with Ion:

WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73 ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
Kernel panic - not syncing: panic_on_warn set ...

This is a warning that validation of the ioctl fields failed. This was
deliberately added as a warning to make it very obvious to developers that
something needed to be fixed. In reality, this is overkill and disturbs
fuzzing. Switch to pr_warn for a message instead.

Reported-by: syzbot+fa2d5f63ee5904a0115a@syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

syzbot reported a warning from Ion:

  WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926

  ...
   __alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
  alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
  alloc_pages include/linux/gfp.h:492 [inline]
  ion_system_contig_heap_allocate+0x40/0x2c0
  drivers/staging/android/ion/ion_system_heap.c:374
  ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
  ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
  ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
  vfs_ioctl fs/ioctl.c:46 [inline]
  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
  SYSC_ioctl fs/ioctl.c:701 [inline]
  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692

This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.

Reported-by: syzbot+76e7efc4748495855a4d@syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch removes FSF's mailing address issue from io.h found by
checkpatch.pl tool.
Signed-off-by: Shubham Kumaram <shubhamkumaram@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove multiple blank lines. Issue found by checkpatch.
Signed-off-by: Marcelo Guzmán Lamperti <marcelo.guzman.lamperti@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>