The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: NLuis de Bethencourt <luisbg@kernel.org>
Signed-off-by: NGreg 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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes checkpatch warnings:

  CHECK: Alignment should match open parenthesis
Signed-off-by: NValentin Vidic <Valentin.Vidic@CARNet.hr>
Signed-off-by: NGreg 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: NGilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: NGreg 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: NGilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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

Remove include files not needed for compilation.
Signed-off-by: NGilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: NGreg 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: NGilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Just call kzalloc(GFP_ATOMIC) directly.
We don't need the warning on failure.
Signed-off-by: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These are not called from filesystem context, so use
GFP_KERNEL, not LIBCFS_ALLOC().
Signed-off-by: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg 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: NNeilBrown <neilb@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes checkpatch warnings:

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

Fixed coding style issue regarding null comparison at multiple lines.
Issue reported by checkpatch.pl
Signed-off-by: NSumit Pundir <pundirsumit11@gmail.com>
Acked-by: NJohan Hovold <johan@kernel.org>
Reviewed-by: NAlex Elder <elder@linaro.org>
Signed-off-by: NGreg 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: Nsyzbot <syzkaller@googlegroups.com>
Signed-off-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NGreg 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: Nsyzbot <syzkaller@googlegroups.com>
Signed-off-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

Use the newly added DPIO service API to map cpu-affine DPIO services
to channels.

The DPAA2 Ethernet driver already had mappings of frame queues and
channels to cpus, but had no control over the DPIOs used. We can
now ensure full affinity of hotpath hardware resources to cores,
which improves performance and almost eliminates some resource
contentions (e.g. enqueue/dequeue busy counters should be close to
zero from now on).

Making the pull channel operation core affine brings the most
significant benefits. This ensures the same DPIO service will be
used for all dequeue commands issued for a certain frame queue,
which is in line with the way hardware is optimized.

Additionally, we also use affine DPIOs for the frame enqueue and
buffer release operations in order to avoid resource contention.
dpaa2_io_service_register() and dpaa2_io_service_rearm()
functions receive an affine DPIO as argument mostly for uniformity,
but this doesn't change the previous functionality.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All DPIO service API functions receive a dpaa2_io service pointer
as parameter (NULL meaning any service will do) which indicates
the hardware resource to be used to execute the specified command.

There isn't however any available API for obtaining such a service
reference that could be used further, effectively forcing the users
to always request a random service for DPIO operations.
(The DPIO driver holds internally an array mapping services to cpus,
and affine services can be indirectly requested by a couple of API
functions: dpaa2_io_service_register and dpaa2_io_service_rearm
use the cpu id provided by the user to select the corresponding
service)

This patch adds a function for selecting a DPIO service based on
the specified cpu id. If the user provides a "don't care" value
for the cpu, we revert to the default behavior and return the next
DPIO, taken in a round-robin fashion from a list of available
services.
Signed-off-by: NIoana Radulescu <ruxandra.radulescu@nxp.com>
Acked-by: NRoy Pledge <roy.pledge@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes one of the warnings as noted by checkpatch.pl related
to unnecessary 'out of memory' message.

This patch fixes the following checkpatch.pl error:

WARNING: Possible unnecessary 'out of memory' message
Signed-off-by: NSumit Pundir <pundirsumit11@gmail.com>

rtl8192_usb_probe is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep,
to avoid busy wait.
Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>

Changed 'firware' to 'firmware'
Signed-off-by: NRichard Sudaryono <richardsudaryono@gmail.com>

Remove unused variable and also remove unused code
associated with initializing the unused variable.

Unused variable was detected using the following
semantic patch by coccinelle.

@@
type T;
identifier i;
constant C;
@@

(
extern T i;
|
- T i;
  <+... when != i
- i = C;
  ...+>
)
Signed-off-by: NShreeya Patel <shreeya.patel23498@gmail.com>

Fix some errors for wrong brace position reported by checkpatch.
Signed-off-by: NSidong Yang <realwakka@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Coccinelle suggested to use BUG_ON instead of if condition followed by BUG
but BUG_ON should be used in situations where integrity of the system is no
longer guaranteed. In this case, as suggested by Stefan Wahren, vchiq isn't
critical.
Since it is not critical, BUG_ON should be avoided.
Replaced if condition followed by BUG with WARN_ON_ONCE.
Signed-off-by: NKishore KP <kishore.p@techveda.org>
Signed-off-by: NSuniel Mahesh <sunil.m@techveda.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Removed .owner field initialization, platform core does it automatically.
Pointed out by Coccinelle.
Signed-off-by: NKishore KP <kishore.p@techveda.org>
Signed-off-by: NSuniel Mahesh <sunil.m@techveda.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed two coding style issues.
Signed-off-by: NAndy Pusch <drag@black-pixel.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed a coding style issue.
Signed-off-by: NPhilippe Loctaux <loctauxphilippe@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

register_shrinker call is made in ashmem_init, it may return error code,
so we need to check it.
Signed-off-by: NXiongwei Song <sxwjean@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>