frv: remove unnecessary code

remove unnecessary code that matches this coccinelle pattern

	if (...)
		return ret;
	return ret;

Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
target: Fix bug for transport_generic_wait_for_tasks with direct operation

This patch fixes a bug in transport_handle_cdb_direct() usage with target_core
where transport_generic_wait_for_tasks() was bypassing active I/O + usage of
cmd->t_transport_stop_comp because cmd->t_transport_active=1 was not being set
before dispatching with transport_generic_new_cmd().  The fix follows existing
usage in transport_generic_handle_cdb*() -> transport_add_cmd_to_queue() and
set these directly, as well as handle transport_generic_new_cmd() exceptions
for QUEUE_FULL and CHECK_CONDITION instead of propigating up to RX context
fabric code.

The bug was manifesting itself with the following SLUB poison overwritten
warnings with iscsi-target v4.1 LUNs using the new process context direct
operation during session reinstatement with active I/O exception handling:

[885410.498267] =============================================================================
[885410.621622] BUG lio_cmd_cache: Poison overwritten
[885410.621791] -----------------------------------------------------------------------------
[885410.621792]
[885410.623420] INFO: 0xffff880000cf3750-0xffff880000cf378d. First byte 0x6a instead of 0x6b
[885410.626332] INFO: Allocated in iscsit_allocate_cmd+0x1c/0xd4 [iscsi_target_mod] age=345 cpu=1 pid=22554
[885411.855189] INFO: Freed in iscsit_release_cmd+0x208/0x217 [iscsi_target_mod] age=1410 cpu=1 pid=22554
[885411.856048] INFO: Slab 0xffffea000002d480 objects=22 used=0 fp=0xffff880000cf7300 flags=0x4080
[885411.856368] INFO: Object 0xffff880000cf33c0 @offset=13248 fp=0xffff880000cf6780

<SNIP>

[885411.955678] Pid: 22554, comm: iscsi_trx Not tainted 3.0.0-rc7+ #30
[885411.956040] Call Trace:
[885411.957029]  [<ffffffff810e5cf9>] print_trailer+0x12e/0x137
[885412.752879]  [<ffffffff810e61d9>] check_bytes_and_report+0xb9/0xfd
[885412.754933]  [<ffffffff810e62d2>] check_object+0xb5/0x192
[885412.755099]  [<ffffffff810e6445>] __free_slab+0x96/0x13a
[885412.757008]  [<ffffffff810e652a>] discard_slab+0x41/0x43
[885412.758171]  [<ffffffff810e7a4c>] __slab_free+0xf3/0xfe
[885412.761027]  [<ffffffffa030a536>] ? iscsit_release_cmd+0x208/0x217 [iscsi_target_mod]
[885412.761354]  [<ffffffff810e7e95>] kmem_cache_free+0x6f/0xac
[885412.761536]  [<ffffffffa030a536>] iscsit_release_cmd+0x208/0x217 [iscsi_target_mod]
[885412.762056]  [<ffffffffa020e467>] ? iblock_free_task+0x34/0x39 [target_core_iblock]
[885412.762368]  [<ffffffffa0314131>] lio_release_cmd+0x10/0x12 [iscsi_target_mod]
[885412.764129]  [<ffffffffa02c2254>] transport_release_cmd+0x2f/0x33 [target_core_mod]
[885412.805024]  [<ffffffffa02c230e>] transport_generic_remove+0xb6/0xc3 [target_core_mod]
[885412.806424]  [<ffffffff81035b5f>] ? try_to_wake_up+0x1bd/0x1bd
[885412.809033]  [<ffffffffa02c241f>] transport_generic_free_cmd+0x75/0x7d [target_core_mod]
[885412.810066]  [<ffffffffa02c2643>] transport_generic_wait_for_tasks+0x21c/0x22b [target_core_mod]
[885412.811056]  [<ffffffff8139f0b1>] ? mutex_lock+0x11/0x32
[885412.813059]  [<ffffffff8139f0b1>] ? mutex_lock+0x11/0x32
[885412.813200]  [<ffffffffa030b81d>] iscsit_close_connection+0x1d5/0x63a [iscsi_target_mod]
[885412.813517]  [<ffffffffa0300a82>] iscsit_take_action_for_connection_exit+0xdb/0xe0 [iscsi_target_mod]
[885412.813851]  [<ffffffffa03111e9>] iscsi_target_rx_thread+0x11f6/0x1221 [iscsi_target_mod]
[885412.829024]  [<ffffffff81033e8d>] ? pick_next_task_fair+0xbe/0x10e
[885412.831010]  [<ffffffffa030fff3>] ? iscsit_handle_scsi_cmd+0x91d/0x91d [iscsi_target_mod]
[885412.833011]  [<ffffffffa030fff3>] ? iscsit_handle_scsi_cmd+0x91d/0x91d [iscsi_target_mod]
[885412.835010]  [<ffffffff8105388a>] kthread+0x7d/0x85
[885412.837022]  [<ffffffff813a7124>] kernel_thread_helper+0x4/0x10
[885412.838008]  [<ffffffff8105380d>] ? kthread_worker_fn+0x145/0x145
[885412.840047]  [<ffffffff813a7120>] ? gs_change+0x13/0x13
[885412.842007] FIX lio_cmd_cache: Restoring 0xffff880000cf3750-0xffff880000cf378d=0x6

Cc: Christoph Hellwig <hch@lst.de>
Cc: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
ext4: fix races in ext4_sync_parent()

Fix problems if fsync() races against a rename of a parent directory
as pointed out by Al Viro in his own inimitable way:

>While we are at it, could somebody please explain what the hell is ext4
>doing in
>static int ext4_sync_parent(struct inode *inode)
>{
>        struct writeback_control wbc;
>        struct dentry *dentry = NULL;
>        int ret = 0;
>
>        while (inode && ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY)) {
>                ext4_clear_inode_state(inode, EXT4_STATE_NEWENTRY);
>                dentry = list_entry(inode->i_dentry.next,
>                                    struct dentry, d_alias);
>                if (!dentry || !dentry->d_parent || !dentry->d_parent->d_inode)
>                        break;
>                inode = dentry->d_parent->d_inode;
>                ret = sync_mapping_buffers(inode->i_mapping);
>                ...
>Note that dentry obviously can't be NULL there.  dentry->d_parent is never
>NULL.  And dentry->d_parent would better not be negative, for crying out
>loud!  What's worse, there's no guarantees that dentry->d_parent will
>remain our parent over that sync_mapping_buffers() *and* that inode won't
>just be freed under us (after rename() and memory pressure leading to
>eviction of what used to be our dentry->d_parent)......

Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4: change umode_t in tracepoint headers to be an explicit __u16

As requested by Al Viro, since umode_t may be changing to a u32 for
some architectures.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Additional readdir cookie loop information

Print out the name of the file that triggers the cookie loop  message to
make it slightly easier to track down the cause.

Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Input: psmouse - hgpk.c needs module.h

hgpk.c uses interfaces from linux/module.h, so it should include that file.
This fixes build errors.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Input: tegra-kbc - fix computation of polling time

Fix a constant definition and computation of polling time.

[dtor@mail.ru: switched to using DIV_ROUND_UP as was suggested by
 Thierry Reding <thierry.reding@avionic-design.de>]

Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Input: lm8323 - add missing device_remove_file for dev_attr_time

Add missing device_remove_file() for dev_attr_time in lm8323_remove().
Also calling device_remove_file() in lm8323_probe() error path to
remove sysfs attribute file.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
m68k/amiga: Chip RAM - Use tabs for indentation

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
m68k/amiga: Chip RAM - Convert from printk() to pr_*()

and fix a few formattings:
  - resource sizes are now resource_size_t, use %pR to make it future proof,
  - use %lu for unsigned long.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
m68k/amiga: Chip RAM - Always allocate from the start of memory

As of commit 5df1abdbd37af2ae317a1c5b5944173284dc55d6 ('m68k/amiga: Fix
"debug=mem"'), "debug=mem" no longer uses amiga_chip_alloc_res(), so we
can remove the hack to prefer memory at the safe end.

This allows to simplify the code and make amiga_chip_alloc() just call
amiga_chip_alloc_res() internally.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
m68k/amiga: Chip RAM - Change chipavail to an atomic_t

While the core resource handling code is safe, our global counter must
still be protected against concurrent modifications.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
m68k/amiga: Chip RAM - Use resource_size() to fix off-by-one error

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
m68k/amiga: Chip RAM - Offset resource end by CHIP_PHYSADDR

Technically, the end of Chip RAM should be offset by CHIP_PHYSADDR (which is
zero).

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
sparc: _sparc_find_resource() should check for exact matches

The address that's passed to _sparc_find_resource() should always be the
start address of a resource:
  - iounmap() passes a page-aligned virtual address, while the original
    address was created by adding the in-page offset to the resource's
    start address,
  - sbus_free_coherent() and pci32_free_coherent() should be passed an
    address obtained from sbus_alloc_coherent() resp. pci32_alloc_coherent(),
    which is always a resource's start address.

Hence replace the range check by a check for an exact match.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: David S. Miller <davem@davemloft.net>
resources: Add lookup_resource()

Add a function to find an existing resource by a resource start address.
This allows to implement simple allocators (with a malloc/free-alike API)
on top of the resource system.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
m68k/amiga: Chip RAM - Use lookup_resource()

Replace a custom implementation (which doesn't lock the resource tree) by a
call to lookup_resource()

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
m68k/atari: Reserve some ST-RAM early on for device buffer use

Based on an original patch from Michael Schmitz:

Because mem_init() is now called before device init, devices that rely on
ST-RAM may find all ST-RAM already allocated to other users by the time
device init happens. In particular, a large initrd RAM disk may use up
enough of ST-RAM to cause atari_stram_alloc() to resort to
__get_dma_pages() allocation.

In the current state of Atari memory management, all of RAM is marked
DMA capable, so __get_dma_pages() may well return RAM that is not in actual
fact DMA capable. Using this for frame buffer or SCSI DMA buffer causes
subtle failure.

The ST-RAM allocator has been changed to allocate memory from a pool of
reserved ST-RAM of configurable size, set aside on ST-RAM init (i.e.
before mem_init()). As long as this pool is not exhausted, allocation of
real ST-RAM can be guaranteed.

Other changes:
  - Replace the custom allocator in the ST-RAM pool by the existing allocator
    in the resource subsystem,
  - Remove mem_init_done and its hook, as memory init is now done before
    device init,
  - Remove /proc/stram, as ST-RAM usage now shows up under /proc/iomem, e.g.

	005f2000-006f1fff : ST-RAM Pool
	  005f2000-0063dfff : atafb
	  0063e000-00641fff : ataflop
	  00642000-00642fff : SCSI

Signed-off-by: Michael Schmitz <schmitz@debian.org>
[Andreas Schwab <schwab@linux-m68k.org>: Use memparse()]
[Geert: Use the resource subsystem instead of a custom allocator]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
sparc: iounmap() and *_free_coherent() - Use lookup_resource()

Replace a custom implementation (which doesn't lock the resource tree) by a
call to lookup_resource()

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: David S. Miller <davem@davemloft.net>
m68k/atari: Prefix GPIO_{IN,OUT} with CODEC_

These defines are way to generic, and cause conflicts:

drivers/net/wireless/rtlwifi/rtl8192c/../rtl8192ce/reg.h:369:1: warning: "GPIO_IN" redefined
drivers/net/wireless/rtlwifi/rtl8192c/../rtl8192ce/reg.h:370:1: warning: "GPIO_OUT" redefined
drivers/net/wireless/rtlwifi/rtl8192se/reg.h:252:1: warning: "GPIO_IN" redefined
drivers/net/wireless/rtlwifi/rtl8192se/reg.h:253:1: warning: "GPIO_OUT" redefined

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>