When a CVL is received while we wait to select best FCF, we drop it
without handling it. This causes initiator and the switch to go
out-of-sync. Initiator proceeds selecting one of the FCFs and tries to
send FIP FLOGI. However the switch may reject the FLOGI, as it has
cleared its internal state, and expects the initiator to start FIP
discovery protocol. Fix this condition by resetting the fcoe
controller.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

This patch fixes following deadlock caused by destroying of
an FCoE interface with active NPIV ports on that interface.

    Call Trace:
    [<ffffffff814b7e88>] schedule+0x64/0x66
    [<ffffffff814b6b4f>] schedule_timeout+0x36/0xe3
    [<ffffffff81070c55>] ? update_curr+0xd6/0x110
    [<ffffffff81071f6b>] ? hrtick_update+0x1b/0x4d
    [<ffffffff81072405>] ? dequeue_task_fair+0x1ca/0x1d9
    [<ffffffff8106a369>] ? need_resched+0x1e/0x28
    [<ffffffff814b7d14>] wait_for_common+0x9b/0xf1
    [<ffffffff8106e7be>] ? try_to_wake_up+0x1e0/0x1e0
    [<ffffffff814b7e22>] wait_for_completion+0x1d/0x1f
    [<ffffffff8105ae82>] flush_workqueue+0x116/0x2a1
    [<ffffffff8105b357>] drain_workqueue+0x66/0x14c
    [<ffffffff8105b8ef>] destroy_workqueue+0x1a/0xcf
    [<ffffffffa009211e>] fc_remove_host+0x154/0x17f [scsi_transport_fc]
    [<ffffffffa00edbb8>] fcoe_if_destroy+0x184/0x1c9 [fcoe]
    [<ffffffffa00edc28>] fcoe_destroy_work+0x2b/0x44 [fcoe]
    [<ffffffff8105a82a>] process_one_work+0x1a8/0x2a4
    [<ffffffffa00edbfd>] ? fcoe_if_destroy+0x1c9/0x1c9 [fcoe]
    [<ffffffff8105c396>] worker_thread+0x1db/0x268
    [<ffffffff810604a3>] ? wake_up_bit+0x2a/0x2a
    [<ffffffff8105c1bb>] ? manage_workers.clone.16+0x1f6/0x1f6
    [<ffffffff8105ffd6>] kthread+0x6f/0x77
    [<ffffffff814c0304>] kernel_thread_helper+0x4/0x10
    [<ffffffff8105ff67>] ? kthread_freezable_should_stop+0x4b/0x4b

    Call Trace:
    [<ffffffff814b7e88>] schedule+0x64/0x66
    [<ffffffff814b8041>] schedule_preempt_disabled+0xe/0x10
    [<ffffffff814b70a1>] __mutex_lock_common.clone.5+0x117/0x17a
    [<ffffffff814b7117>] __mutex_lock_slowpath+0x13/0x15
    [<ffffffff814b6f76>] mutex_lock+0x23/0x37
    [<ffffffff8125b890>] ? list_del+0x11/0x30
    [<ffffffffa00edc84>] fcoe_vport_destroy+0x43/0x5f [fcoe]
    [<ffffffffa009130a>] fc_vport_terminate+0x48/0x110 [scsi_transport_fc]
    [<ffffffffa00913ef>] fc_vport_sched_delete+0x1d/0x79 [scsi_transport_fc]
    [<ffffffff8105a82a>] process_one_work+0x1a8/0x2a4
    [<ffffffffa00913d2>] ? fc_vport_terminate+0x110/0x110 [scsi_transport_fc]
    [<ffffffff8105c396>] worker_thread+0x1db/0x268
    [<ffffffff8105c1bb>] ? manage_workers.clone.16+0x1f6/0x1f6
    [<ffffffff8105ffd6>] kthread+0x6f/0x77
    [<ffffffff814c0304>] kernel_thread_helper+0x4/0x10
    [<ffffffff8105ff67>] ? kthread_freezable_should_stop+0x4b/0x4b
    [<ffffffff814c0300>] ? gs_change+0x13/0x13

A prior attempt to fix this issue is posted here:
http://lists.open-fcoe.org/pipermail/devel/2012-October/012318.html
or
http://article.gmane.org/gmane.linux.scsi.open-fcoe.devel/11924

Based on feedback and discussion with Neil Horman it seems that the above patch
may have a case where the fcoe_vport_destroy() and fcoe_destroy_work() can
race; hence that patch has been withdrawn with this patch that is trying to
solve the same problem in a different way.

In the current approach instead of removing the fcoe_config_mutex from the
vport_delete callback function; I've chosen to delete all the NPIV ports first
on a given root lport before continuing with the removal of the root lport.
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

When creating an fcoe interfce, we call fcoe_link_speed_update before we add the
lports fcoe interface to the fc_hostlist.  Since network device events like
NETDEV_CHANGE are only processed if an fcoe interface is found with an
underlying netdev that matches the netdev of the event.  Since this processing
in fcoe_device_notification is how link_speed changes get communicated to the
libfc  code (via fcoe_link_speed_update), we have a race condition - if a
NETDEV_CHANGE event is sent after the call to fcoe_link_speed_update in
fcoe_netdev_config, but before we add the interface to the fc_hostlist, we will
loose the event and attributes like /sys/class/fc_host/hostX/speed will not get
updated properly.

Fix this by moving the add to the fc_hostlist above the serialized call to
fcoe_netdev_config, ensuring that we catch netdev envents before we make a
direct call to fcoe_link_speed_update.

Also use this opportunity to clean up access to the fc_hostlist a bit by
creating a fcoe_hostlist_del accessor and replacing the cleanup in fcoe_exit to
use it properly.

Tested by myself successfully

[ Comment over 80 chars broken into multi-line by Robert Love to
  satisfy checkpatch.pl ]
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

	AFAICS, the situation for fcoe_transport_disable() seems to be
the same as for fcoe_transport_enable().  IOW, shouldn't it have
restart_syscall() removed as well?  I don't see any in-tree ->disable()
instances that could return -ERESTARTSYS, anyway...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Drop the bnx2fc_xxx versions as they are basically the same.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

We have fcoe_link_speed_update() in libfcoe ready for use now, take out the
bnx2fc version which is almost the same.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Adds support to fcoe_port's newly added get_netdev fucntion pointer for bnx2fc.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Similarly they can be moved into libfcoe instead of being private to fcoe now.
Also add comments particularly on the term LESB to the corresponding function.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

With the previous patch, fcoe_link_speed_update() can be moved into libfcoe and
exported to used by fcoe, bnx2fc, and etc.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Adds support to fcoe_port's newly added get_netdev fucntion pointer.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Convert libfc, libfcoe and fcoe's debug_logging macros
to use pr_info() instead of printk(KERN_INFO, ...). checkpatch.pl
now complains about this, so convert libfcoe to preferred
method.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>

This patch adds support for the new fcoe_sysfs
control interface to bnx2fc.ko. It keeps the deprecated
interface in tact and therefore either the legacy
or the new control interfaces can be used. A mixed mode
is not supported. A user must either use the new
interfaces or the old ones, but not both.

The fcoe_ctlr's link state is now driven by both the
netdev link state as well as the fcoe_ctlr_device's
enabled attribute. The link must be up and the
fcoe_ctlr_device must be enabled before the FCoE
Controller starts discovery or login.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

This patch adds support for the new fcoe_sysfs
control interface to fcoe.ko. It keeps the deprecated
interface in tact and therefore either the legacy
or the new control interfaces can be used. A mixed mode
is not supported. A user must either use the new
interfaces or the old ones, but not both.

The fcoe_ctlr's link state is now driven by both the
netdev link state as well as the fcoe_ctlr_device's
enabled attribute. The link must be up and the
fcoe_ctlr_device must be enabled before the FCoE
Controller starts discovery or login.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

This patch does a few things.

1) Makes /sys/bus/fcoe/ctlr_{create,destroy} interfaces.
   These interfaces take an <ifname> and will either
   create an FCoE Controller or destroy an FCoE
   Controller depending on which file is written to.

   The new FCoE Controller will start in a DISABLED
   state and will not do discovery or login until it
   is ENABLED. This pause will allow us to configure
   the FCoE Controller before enabling it.

2) Makes the 'mode' attribute of a fcoe_ctlr_device
   writale. This allows the user to configure the mode
   in which the FCoE Controller will start in when it
   is ENABLED.

   Possible modes are 'Fabric', or 'VN2VN'.

   The default mode for a fcoe_ctlr{,_device} is 'Fabric'.
   Drivers must implement the set_fcoe_ctlr_mode routine
   to support this feature.

   libfcoe offers an exported routine to set a FCoE
   Controller's mode. The mode can only be changed
   when the FCoE Controller is DISABLED.

   This patch also removes the get_fcoe_ctlr_mode pointer
   in the fcoe_sysfs function template, the code in
   fcoe_ctlr.c to get the mode and the assignment of
   the fcoe_sysfs function pointer to the fcoe_ctlr.c
   implementation (in fcoe and bnx2fc). fcoe_sysfs can
   return that value for the mode without consulting the
   LLD.

3) Make a 'enabled' attribute of a fcoe_ctlr_device. On a
   read, fcoe_sysfs will return the attribute's value. On
   a write, fcoe_sysfs will call the LLD (if there is a
   callback) to notifiy that the enalbed state has changed.

This patch maintains the old FCoE control interfaces as
module parameters, but it adds comments pointing out that
the old interfaces are deprecated.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

Add a macro to print fcoe_sysfs debug statements.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

Instead of creating a structure with an enum and a pointer
to a string, simply allocate an array of strings and use
the enum values for the indicies.

This means that we do not need to iterate through the list
of entries when looking up a string name by its enum key.

This will also help with a latter patch that will add
more fcoe_sysfs attributes that will also use the
fcoe_enum_name_search macro. One attribute will also do
a reverse lookup which requires less code when the
enum-to-string mappings are organized as this patch makes
them to be.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

Currently fc_fcp_timeout doesn't check FC_RP_FLAGS_REC_SUPPORTED
flag first, this prevents REC request ever going out at all
to the target having REC support. So this patches fixes the
fc_fcp_timeout by checking FC_RP_FLAGS_REC_SUPPORTED flag first.

The changed order won't cause any issue during clearing
FC_RP_FLAGS_REC_SUPPORTED on failed IO with target not supporting
FC_RP_FLAGS_REC_SUPPORTED, since retry on failed IO would succeed.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

cp_open
[...]
        rc = cp_alloc_rings(cp);
        if (rc)
                return rc;

cp_alloc_rings
[...]
        mem = dma_alloc_coherent(&cp->pdev->dev, CP_RING_BYTES,
                                 &cp->ring_dma, GFP_KERNEL);

- cp_alloc_rings never frees the coherent mapping it allocates
- neither do cp_open when cp_alloc_rings fails
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The tps65910_rtc data is registered as the platform driver data in
_probe(= ).  Therefore the tps65910_rtc should be used on unregistering
the rtc device.  And device pointer should be retrieved from the
platform_device structure.

This patch fixes the below oops:

 Unable to handle kernel NULL pointer dereference at virtual address 00000008
 Modules linked in: rtc_tps65910(-)
 CPU: 0    Not tainted  (3.7.0-rc7-next-20121128-g6b1f974-dirty #7)
 PC is at tps65910_rtc_alarm_irq_enable+0x20/0x2c [rtc_tps65910]
     (tps65910_rtc_alarm_irq_enable+0x20/0x2c [rtc_tps65910])
     (tps65910_rtc_remove+0x18/0x28 [rtc_tps65910])
     (platform_drv_remove+0x18/0x1c)
     (__device_release_driver+0x70/0xcc)
     (driver_detach+0xb4/0xb8)
     (bus_remove_driver+0x7c/0xc0)
     (sys_delete_module+0x148/0x21c)
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It apepars that this patch was innocent, and we hope that "mm: avoid
waking kswapd for THP allocations when compaction is deferred or
contended" will fix the final kswapd-spinning cause.

Cc: Zdenek Kabelac <zkabelac@redhat.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: Jiri Slaby <jirislaby@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts the block-device direct access code to the previous
unlocked code, now that fs/buffer.c no longer needs external locking.

With this, fs/block_dev.c is back to the original version, apart from a
whitespace cleanup that I didn't want to revert.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Race between bonding_store_slaves_active() and slave manipulation
 functions. The bond_for_each_slave use in bonding_store_slaves_active()
 is not protected by any synchronization mechanism.
 NULL pointer dereference is easy to reach.
 Fixed by acquiring the bond->lock for the slave walk.

 v2: Make description text < 75 columns
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The module can be loaded with arp_ip_target="255.255.255.255" which makes
 it impossible to remove as the function in sysfs checks for that value,
 so we make the parameter checks consistent with sysfs.

 v2: Fix formatting
 v3: Make description text < 75 columns
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

First I would give three observations which will be used later.
Observation 1: if (delayed_work_pending(wq)) cancel_delayed_work(wq)
 This usage is wrong because the pending bit is cleared just before the
 work's fn is executed and if the function re-arms itself we might end up
 with the work still running. It's safe to call cancel_delayed_work_sync()
 even if the work is not queued at all.
Observation 2: Use of INIT_DELAYED_WORK()
 Work needs to be initialized only once prior to (de/en)queueing.
Observation 3: IFF_UP is set only after ndo_open is called

Related race conditions:
1. Race between bonding_store_miimon() and bonding_store_arp_interval()
 Because of Obs.1 we can end up having both works enqueued.
2. Multiple races with INIT_DELAYED_WORK()
 Since the works are not protected by anything between INIT_DELAYED_WORK()
 and calls to (en/de)queue it is possible for races between the following
 functions:
 (races are also possible between the calls to INIT_DELAYED_WORK()
  and workqueue code)
 bonding_store_miimon() - bonding_store_arp_interval(), bond_close(),
			  bond_open(), enqueued functions
 bonding_store_arp_interval() - bonding_store_miimon(), bond_close(),
				bond_open(), enqueued functions
3. By Obs.1 we need to change bond_cancel_all()

Bugs 1 and 2 are fixed by moving all work initializations in bond_open
which by Obs. 2 and Obs. 3 and the fact that we make sure that all works
are cancelled in bond_close(), is guaranteed not to have any work
enqueued.
Also RTNL lock is now acquired in bonding_store_miimon/arp_interval so
they can't race with bond_close and bond_open. The opposing work is
cancelled only if the IFF_UP flag is set and it is cancelled
unconditionally. The opposing work is already cancelled if the interface
is down so no need to cancel it again. This way we don't need new
synchronizations for the bonding workqueue. These bugs (and fixes) are
tied together and belong in the same patch.
Note: I have left 1 line intentionally over 80 characters (84) because I
      didn't like how it looks broken down. If you'd prefer it otherwise,
      then simply break it.

 v2: Make description text < 75 columns
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Eliminate an erroneous invocation of rproc_shutdown inside
the error path of rproc_virtio_find_vqs.
Reported-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>

Do this in the same way bonding does. This fixed setup resolves performance
issues when using some cards with certain offloading.
Signed-off-by: NJiri Pirko <jiri@resnulli.us>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There was a forever loop introduced here when we converted this to
request_firmware() back in 2008.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NChas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If a single descriptor crosses a region, the
second chunk length should be decremented
by size translated so far, instead it includes
the full descriptor length.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Huawei E173 is a QMI/wwan device which normally appear
as 12d1:1436 in Linux. The descriptors displayed in that
mode will be picked up by cdc_ether.  But the modem has
another mode with a different device ID and a slightly
different set of descriptors. This is the mode used by
Windows like this:

3Modem:      USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001
Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002
PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
Reported-by: NThomas Schäfer <tschaefer@t-online.de>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Had a typo in memcpy.
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The i7core_edac addrmatch_dev and chancounts_dev have sysfs files
associated with them.  The sysfs files, however, are coded so that the
parent device is is the mci device.  This is incorrect and the mci struct
should be obtained through the addrmatch_dev and chancounts_dev device's
private data field which is populated in i7core_create_sysfs_devices().
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This fix black screen on resume issue that some people are
experiencing. There is a bug in the atombios code regarding
pll/crtc mapping. The atombios code reverse the logic for
the pll and crtc mapping.

agd5f: drop unnecessary crtc id check, cc stable in case
we miss 3.7.

This fixes the root cause that was worked around by commits:
drm/radeon: allocate PPLLs from low to high
drm/radeon/dce3: switch back to old pll allocation order for discrete
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

With "mm: vmscan: scale number of pages reclaimed by reclaim/compaction
based on failures" reverted, Zdenek Kabelac reported the following

  Hmm,  so it's just took longer to hit the problem and observe
  kswapd0 spinning on my CPU again - it's not as endless like before -
  but still it easily eats minutes - it helps to	turn off  Firefox
  or TB  (memory hungry apps) so kswapd0 stops soon - and restart
  those apps again.  (And I still have like >1GB of cached memory)

  kswapd0         R  running task        0    30      2 0x00000000
  Call Trace:
    preempt_schedule+0x42/0x60
    _raw_spin_unlock+0x55/0x60
    put_super+0x31/0x40
    drop_super+0x22/0x30
    prune_super+0x149/0x1b0
    shrink_slab+0xba/0x510

The sysrq+m indicates the system has no swap so it'll never reclaim
anonymous pages as part of reclaim/compaction.  That is one part of the
problem but not the root cause as file-backed pages could also be
reclaimed.

The likely underlying problem is that kswapd is woken up or kept awake
for each THP allocation request in the page allocator slow path.

If compaction fails for the requesting process then compaction will be
deferred for a time and direct reclaim is avoided.  However, if there
are a storm of THP requests that are simply rejected, it will still be
the the case that kswapd is awake for a prolonged period of time as
pgdat->kswapd_max_order is updated each time.  This is noticed by the
main kswapd() loop and it will not call kswapd_try_to_sleep().  Instead
it will loopp, shrinking a small number of pages and calling
shrink_slab() on each iteration.

The temptation is to supply a patch that checks if kswapd was woken for
THP and if so ignore pgdat->kswapd_max_order but it'll be a hack and not
backed up by proper testing.  As 3.7 is very close to release and this
is not a bug we should release with, a safer path is to revert "mm:
remove __GFP_NO_KSWAPD" for now and revisit it with the view to ironing
out the balance_pgdat() logic in general.
Signed-off-by: NMel Gorman <mgorman@suse.de>
Cc: Zdenek Kabelac <zkabelac@redhat.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: Jiri Slaby <jirislaby@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the raid1 or raid10 unplug function gets called
from a make_request function (which is very possible) when
there are bios on the current->bio_list list, then it will not
be able to successfully call bitmap_unplug() and it could
need to submit more bios and wait for them to complete.
But they won't complete while current->bio_list is non-empty.

So detect that case and handle the unplugging off to another thread
just like we already do when called from within the scheduler.

RAID1 version of bug was introduced in 3.6, so that part of fix is
suitable for 3.6.y.  RAID10 part won't apply.

Cc: stable@vger.kernel.org
Reported-by: NTorsten Kaiser <just.for.lkml@googlemail.com>
Reported-by: NPeter Maloney <peter.maloney@brockmann-consult.de>
Signed-off-by: NNeilBrown <neilb@suse.de>

The skb->tstamp is set to the hardware timestamp when available in the USB
urb message. This leads to user visible timestamps which contain the 'uptime'
of the USB adapter - and not the usual system generated timestamp.

Fix this wrong assignment by applying the available hardware timestamp to the
skb_shared_hwtstamps data structure - which is intended for this purpose.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

When one input buffer has multiple frames, it should be fed
again to the hardware with the remaining bytes. Removed the
check for P frame in this scenario as this condition can come with
all frame types.
Signed-off-by: NArun Kumar K <arun.kk@samsung.com>
Signed-off-by: NARUN MANKUZHI <arun.m@samsung.com>
Acked-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Modified the function s5p_mfc_get_dec_y_adr_v6 to access the
decode Y address register instead of display Y address.
Signed-off-by: NSunil Mazhavanchery <sunilm@samsung.com>
Signed-off-by: NArun Kumar K <arun.kk@samsung.com>
Acked-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

vfl_dir should be set to VFL_DIR_M2M so valid ioctls for this
mem-to-mem device can be properly determined in the v4l2 core.
Signed-off-by: NSylwester Nawrocki <sylvester.nawrocki@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Macros used to set input and output RGB type aren't correct.
Updating the macros as per register manual.
Signed-off-by: NShaik Ameer Basha <shaik.ameer@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use uninterruptible mutex_lock in the release() file op to make
sure all resources are properly freed when a process is being
terminated. Returning -ERESTARTSYS has no effect for a terminating
process and this may cause driver resources not to be released.
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>