ARM allmodconfig gained a new warning when dma_addr_t is 32-bit wide:

drivers/iommu/arm-smmu.c: In function 'arm_smmu_iova_to_phys_hard':
drivers/iommu/arm-smmu.c:1255:3: warning: right shift count >= width of type

This changes the calculation so that the effective type is always
64-bit.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 859a732e ("iommu/arm-smmu: add support for iova_to_phys through ATS1PR")
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Commit ffcc3936 ("dm: enhance internal suspend and resume interface")
attempted to handle multiple internal suspends on the same device, but
it did that incorrectly.  When these functions are called in this order
on the same device the device is no longer suspended, but it should be:
	dm_internal_suspend_noflush
	dm_internal_suspend_noflush
	dm_internal_resume

Fix this bug by maintaining an 'internal_suspend_count' and resuming
the device when this count drops to zero.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

Use ATTRIBUTE_GROUPS macro to simplify the code a bit.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NJean Delvare <jdelvare@suse.de>

Use module_pci_driver to simplify the code a bit.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJean Delvare <jdelvare@suse.de>

On many motherboards, for an unknown reason, the thermal sensor seems
to be disabled and will return a constant temperature value of 36.5
degrees Celsius. Don't bind to the device in that case, so that we
don't report this bogus value to userspace.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Romain Dolbeau <romain@dolbeau.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>

Use devm_hwmon_device_register_with_groups() to simplify the code a
bit.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Romain Dolbeau <romain@dolbeau.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>

The Intel 5500, 5520 and X58 chipsets embed a digital thermal sensor.
This new driver supports it.

Note that on many boards the sensor seems to be disabled and reports
the minimum value (36.5 degrees Celsius) all the time.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Tested-by: NRomain Dolbeau <romain@dolbeau.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>

This reverts commit 02b2aaaa.

This interface was determined to be flawed and required too invasive a
fix for the RC cycle. This will be revisited in 3.20.
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Introduce a new variable to count the number of allocated migration
structures.  The existing variable cache->nr_migrations became
overloaded.  It was used to:

 i) track of the number of migrations in flight for the purposes of
    quiescing during suspend.

 ii) to estimate the amount of background IO occuring.

Recent discard changes meant that REQ_DISCARD bios are processed with
a migration.  Discards are not background IO so nr_migrations was not
incremented.  However this could cause quiescing to complete early.

(i) is now handled with a new variable cache->nr_allocated_migrations.
cache->nr_migrations has been renamed cache->nr_io_migrations.
cleanup_migration() is now called free_io_migration(), since it
decrements that variable.

Also, remove the unused cache->next_migration variable that got replaced
with with prealloc_structs a while ago.
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

If a DM table is reloaded with an inactive table when the device is not
suspended (normal procedure for LVM2), then there will be two dm-bufio
objects that can diverge.  This can lead to a situation where the
inactive table uses bufio to read metadata at the same time the active
table writes metadata -- resulting in the inactive table having stale
metadata buffers once it is promoted to the active table slot.

Fix this by using reference counting and a global list of cache metadata
objects to ensure there is only one metadata object per metadata device.
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

Introduce selftests for overlays using sub-devices present
in children nodes.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

cppcheck found the following issue:
(warning) Logical conjunction always evaluates to false:
  alloc_len < 4 && alloc_len > 65535.

..the test should be instead:

  if (alloc_len < 4 || alloc_len > 65536)

This error was introduced by recent commit 38d5c833
("scsi_debug: add Report supported opcodes+tmfs; Compare and write")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

When using overlays with drivers calling of_populate the notifier
will try to create the device twice. Using the populated bit
before proceeding protects against this.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

During the course of the rewrites a bug sneaked in when dealing
with children nodes of overlays, which ends up duplicating
sub nodes.

Simply remove the duplicate traversal of child nodes to fix.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

device_caps in struct v4l2_capability were inadequately set in
VIDIOC_QUERYCAP. Fix this. Without this a WARN_ON in the v4l2 core
is triggered. This WARN_ON was added for kernel 3.19 exactly to
detect these situations.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

First free the interrupt, then disable the PCI device. The other way
around will lead to this warning:

Jan 19 11:42:02 telek kernel: [ 1440.161234] WARNING: CPU: 0 PID: 2191 at kernel/irq/manage.c:1311 __free_irq+0x97/0x1f0()
Jan 19 11:42:02 telek kernel: [ 1440.161236] Trying to free already-free IRQ 0
Jan 19 11:42:02 telek kernel: [ 1440.161237] Modules linked in: tda8290 tda10048 cx25840 cx23885(-) altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core v4l2_common videodev media nouveau x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci
Jan 19 11:42:02 telek kernel: [ 1440.161266] CPU: 0 PID: 2191 Comm: rmmod Tainted: G        W      3.19.0-rc1-telek #345
Jan 19 11:42:02 telek kernel: [ 1440.161268] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014
Jan 19 11:42:02 telek kernel: [ 1440.161270]  ffffffff81bf1fce ffff8808958b7cc8 ffffffff8194a97f 0000000000000000
Jan 19 11:42:02 telek kernel: [ 1440.161274]  ffff8808958b7d18 ffff8808958b7d08 ffffffff810c56b0 0000000000000286
Jan 19 11:42:02 telek kernel: [ 1440.161279]  0000000000000000 0000000000000000 ffff88089f808890 ffff88089f808800
Jan 19 11:42:02 telek kernel: [ 1440.161284] Call Trace:
Jan 19 11:42:02 telek kernel: [ 1440.161290]  [<ffffffff8194a97f>] dump_stack+0x4f/0x7b
Jan 19 11:42:02 telek kernel: [ 1440.161295]  [<ffffffff810c56b0>] warn_slowpath_common+0x80/0xc0
Jan 19 11:42:02 telek kernel: [ 1440.161299]  [<ffffffff810c5731>] warn_slowpath_fmt+0x41/0x50
Jan 19 11:42:02 telek kernel: [ 1440.161303]  [<ffffffff81955d36>] ? _raw_spin_lock_irqsave+0x56/0x70
Jan 19 11:42:02 telek kernel: [ 1440.161307]  [<ffffffff81114849>] ? __free_irq+0x49/0x1f0
Jan 19 11:42:02 telek kernel: [ 1440.161311]  [<ffffffff81114897>] __free_irq+0x97/0x1f0
Jan 19 11:42:02 telek kernel: [ 1440.161316]  [<ffffffff81114a88>] free_irq+0x48/0xd0
Jan 19 11:42:02 telek kernel: [ 1440.161323]  [<ffffffffa00e6deb>] cx23885_finidev+0x4b/0x90 [cx23885]
Jan 19 11:42:02 telek kernel: [ 1440.161329]  [<ffffffff814529fa>] pci_device_remove+0x3a/0xc0
Jan 19 11:42:02 telek kernel: [ 1440.161334]  [<ffffffff8153b4ea>] __device_release_driver+0x7a/0xf0
Jan 19 11:42:02 telek kernel: [ 1440.161338]  [<ffffffff8153bc98>] driver_detach+0xc8/0xd0
Jan 19 11:42:02 telek kernel: [ 1440.161341]  [<ffffffff8153b1de>] bus_remove_driver+0x4e/0xb0
Jan 19 11:42:02 telek kernel: [ 1440.161345]  [<ffffffff8153c2eb>] driver_unregister+0x2b/0x60
Jan 19 11:42:02 telek kernel: [ 1440.161349]  [<ffffffff814525c5>] pci_unregister_driver+0x25/0x70
Jan 19 11:42:02 telek kernel: [ 1440.161355]  [<ffffffffa00f6ddc>] cx23885_fini+0x10/0x12 [cx23885]
Jan 19 11:42:02 telek kernel: [ 1440.161360]  [<ffffffff81139a98>] SyS_delete_module+0x1a8/0x1f0
Jan 19 11:42:02 telek kernel: [ 1440.161364]  [<ffffffff819561a9>] system_call_fastpath+0x12/0x17
Jan 19 11:42:02 telek kernel: [ 1440.161367] ---[ end trace a9c07cb5f3357020 ]---
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The VIDIOC_QUERYCAP function should set device_caps, but this was missing.
In addition, it set the version field as well, but that should be done by
the core, not by the driver.

If a driver doesn't set device_caps the v4l2 core will issue a WARN_ON, so
it's important that this is set correctly.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The locking scheme inside the vb2 thread is unsafe when stopping the
thread. In particular kthread_stop was called *after* internal data
structures were cleaned up instead of doing that before. In addition,
internal vb2 functions were called after threadio->stop was set to
true and vb2_internal_streamoff was called. This is also not allowed.

All this led to a variety of race conditions and kernel warnings and/or
oopses.

Fixed by moving the kthread_stop call up before the cleanup takes
place, and by checking threadio->stop before calling internal vb2
queuing operations.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: <stable@vger.kernel.org>      # for v3.16 and up
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The V4L2 API requires both .capabilities and .device_caps fields of
struct v4l2_capability to be set. Otherwise the compliance checker
complains and since commit "v4l2-ioctl: WARN_ON if querycap didn't fill
device_caps" a compile-time warning is issued. Fix this non-compliance
in the rcar_vin driver.
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The V4L2 API requires both .capabilities and .device_caps fields of
struct v4l2_capability to be set. Otherwise the compliance checker
complains and since commit "v4l2-ioctl: WARN_ON if querycap didn't fill
device_caps" a compile-time warning is issued. Fix this non-compliance
in several soc-camera camera host drivers.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Commit 2adb177e removed 2 devices
from the cxusb device table but failed to fix up the T230 properties
that follow, meaning that this device no longer gets detected properly.
Adjust the cxusb_table index appropriate so detection works.
Signed-off-by: NJonathan McDowell <noodles@earth.li>
Reviewed-by: NOlli Salonen <olli.salonen@iki.fi>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Unconditionally attaching Si2161/Si2165 demod driver
breaks Hauppauge WinTV Starburst.
So create own card entry for this.

Add card name comments to the subsystem ids.

This fixes a regression introduced in 3.17 by
36efec48 ([media] cx23885: Add si2165 support for HVR-5500)
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
CC: stable@vger.kernel.org # for 3.17 and upper
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

X-Patchwork-Delegate: m.chehab@samsung.com
Changeset ea2e813e moved the driver to staging, but it forgot to
preserve the existing dependency.

Fixes: ea2e813e ("[media] tlg2300: move to staging in preparation for removal")
Reported-by: NJim Davis <jim.epost@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Disable power down counter of the watchdog to avoid system resets. The
watchdog power down counter is set automatically by the chip. If it is
not set to 0 in the driver, the system resets.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Improve power management operations(suspend and resume) as part of
dev_pm_ops for IMX2 watchdog driver.

If PM will be supported, please make sure that the wdev->clk
could disable the watchdog's counter input clock source or can
mask watchdog's reset request to the core.

If watchdog is still used by consumers and resumes from deep
sleep state, we need to restart the watchdog again without
enabling the timer.

If watchdog been has started --> stopped by the consumers and
resumes from non-deep sleep state, then start the timer again.

If watchdog has been started --> stopped by the consumers and
resumes from deep sleep state, will do nothing. The watchdog
will be restarted by consumers next time to be used.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

There are still some places in the fb helper that need to avoid
sleeping in panic context. Here's an example:

[   65.615496] bad: scheduling from the idle thread!
[   65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G   M        E  3.18.0-rc4-7-default+ #20

[   65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRHSXSD1.86B.0056.R01.1409242327 09/24/2014
[   65.641923]  ffff88087f693d80 ffff88087f689878 ffffffff81566db9 0000000000000000
[   65.650226]  ffff88087f693d80 ffff88087f689898 ffffffff810871ff ffff88046eb3e0d0
[   65.658527]  ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa 000000017f6898b8
[   65.666830] Call Trace:
[   65.669557]  <#MC>  [<ffffffff81566db9>] dump_stack+0x46/0x58
[   65.675994]  [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
[   65.682412]  [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
[   65.688345]  [<ffffffff810804f3>] deactivate_task+0x23/0x30
[   65.694569]  [<ffffffff81569050>] __schedule+0x580/0x7f0
[   65.700502]  [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
[   65.707696]  [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
[   65.714891]  [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
[   65.721125]  [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
[   65.728132]  [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm]
[   65.735721]  [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
[   65.743015]  [<ffffffffa01af8bf>] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
[   65.751857]  [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
[   65.758081]  [<ffffffff81326010>] bit_update_start+0x20/0x50
[   65.764400]  [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
[   65.770528]  [<ffffffff813a01c9>] redraw_screen+0x189/0x240
[   65.776750]  [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
[   65.782778]  [<ffffffff8137d359>] ? erst_writer+0x209/0x330
[   65.789002]  [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
[   65.795710]  [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
[   65.801740]  [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
[   65.808255]  [<ffffffff813a0e10>] unblank_screen+0x10/0x20
[   65.814381]  [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
[   65.820508]  [<ffffffff81561ca7>] panic+0x106/0x1f5
[   65.825955]  [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
[   65.831789]  [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
[   65.837625]  [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
[   65.844138]  [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[   65.850166]  [<ffffffff8156f03f>] machine_check+0x1f/0x30
[   65.856195]  [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[   65.862222]  <<EOE>>  [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170
[   65.869823]  [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
[   65.875852]  [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
[   65.882467]  [<ffffffff8102fe29>] start_secondary+0x159/0x180

There's __drm_modeset_lock_all() which Daniel Vetter introduced for this
purpose. We can leverage that without reinventing anything. This patch
works with the latest kernel.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NRui Wang <rui.y.wang@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.

Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.

Cc: <stable@vger.kernel.org> # v3.16+
Fixes: 730876be ("mfd: Add realtek USB card reader driver")
Signed-off-by: NRoger Tseng <rogerable@realtek.com>
[Lee: Removed newly unused variable]
Signed-off-by: NLee Jones <lee.jones@linaro.org>

If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.

Fixes: 44b4dc61 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

STATUS register can be modified by the HW, so we
should bypass cache because of that.

In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.

Fixes: 44b4dc61 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Allow multiple DA9052 regulators be registered by registering with
PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.

The subdevices are currently registered with PLATFORM_DEVID_NONE, which
will cause a name collision on the platform bus when multiple regulators
are registered:

[    0.128855] da9052-regulator da9052-regulator: invalid regulator ID specified
[    0.128973] da9052-regulator: probe of da9052-regulator failed with error -22
[    0.129148] ------------[ cut here ]------------
[    0.129200] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x7c()
[    0.129233] sysfs: cannot create duplicate filename '/devices/platform/soc/60000000.aips/63fc8000.i2c/i2c-0/0-0048/da9052-regulator
...
[    0.132891] ------------[ cut here ]------------
[    0.132924] WARNING: CPU: 0 PID: 1 at lib/kobject.c:240 kobject_add_internal+0x24c/0x2cc()
[    0.132957] kobject_add_internal failed for da9052-regulator with -EEXIST, don't try to register things with the same name in the same directory.
...
[    0.137000] da9052 0-0048: mfd_add_devices failed: -17
[    0.138486] da9052: probe of 0-0048 failed with error -17

Based on the fix done by Johan Hovold at commit b6684228 ("mfd:
viperboard: Fix platform-device id collision").

Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Xen pciback driver assumes that pci_dev->irq won't change after calling
pci_disable_device(). But commit cffe0a2b
("x86, irq: Keep balance of IOAPIC pin reference count") frees irq
resources and resets pci_dev->irq to zero when pci_disable_device() is
called.

So this is a hotfix for 3.19 to avoid resetting pci_dev->irq, and
another proper fix will be prepared for next merging window.
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Tested-by: NSander Eikelenboom <linux@eikelenboom.it>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Link: http://lkml.kernel.org/r/1421720467-7709-3-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This can happen if a multipathed device uses DIX and another path is
added via an adapter that does not support it.  Multipath should not
allow this path to be added, but we should not depend upon that to avoid
crashing.
Signed-off-by: NEwan D. Milne <emilne@redhat.com>
Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

resp_rsup_opcodes() may get called from atomic context and would need to
use GFP_ATOMIC for allocations:

[ 1237.913419] BUG: sleeping function called from invalid context at mm/slub.c:1262
[ 1237.914865] in_atomic(): 1, irqs_disabled(): 0, pid: 7556, name: trinity-c311
[ 1237.916142] 3 locks held by trinity-c311/7556:
[ 1237.916981] #0: (sb_writers#5){.+.+.+}, at: do_readv_writev (include/linux/fs.h:2346 fs/read_write.c:844)
[ 1237.919713] #1: (&of->mutex){+.+.+.}, at: kernfs_fop_write (fs/kernfs/file.c:297)
[ 1237.922626] Mutex: counter: -1 owner: trinity-c311
[ 1237.924044] #2: (s_active#51){.+.+.+}, at: kernfs_fop_write (fs/kernfs/file.c:297)
[ 1237.925960] Preemption disabled blk_execute_rq_nowait (block/blk-exec.c:95)
[ 1237.927416]
[ 1237.927680] CPU: 24 PID: 7556 Comm: trinity-c311 Not tainted 3.19.0-rc4-next-20150116-sasha-00054-g4ad498c-dirty #1744
[ 1237.929603]  ffff8804fc9d8000 ffff8804d9bc3548 ffffffff9d439fb2 0000000000000000
[ 1237.931097]  0000000000000000 ffff8804d9bc3588 ffffffff9a18389a ffff8804d9bc3598
[ 1237.932466]  ffffffff9a1b1715 ffffffffa15935d8 ffffffff9e6f8cb1 00000000000004ee
[ 1237.933984] Call Trace:
[ 1237.934434] dump_stack (lib/dump_stack.c:52)
[ 1237.935323] ___might_sleep (kernel/sched/core.c:7339)
[ 1237.936259] ? mark_held_locks (kernel/locking/lockdep.c:2549)
[ 1237.937293] __might_sleep (kernel/sched/core.c:7305)
[ 1237.938272] __kmalloc (mm/slub.c:1262 mm/slub.c:2419 mm/slub.c:2491 mm/slub.c:3291)
[ 1237.939137] ? resp_rsup_opcodes (include/linux/slab.h:435 drivers/scsi/scsi_debug.c:1689)
[ 1237.940173] resp_rsup_opcodes (include/linux/slab.h:435 drivers/scsi/scsi_debug.c:1689)
[ 1237.941211] ? add_host_store (drivers/scsi/scsi_debug.c:1584)
[ 1237.942261] scsi_debug_queuecommand (drivers/scsi/scsi_debug.c:5276)
[ 1237.943404] ? blk_rq_map_sg (block/blk-merge.c:254)
[ 1237.944398] ? scsi_init_sgtable (drivers/scsi/scsi_lib.c:1095)
[ 1237.945402] sdebug_queuecommand_lock_or_not (drivers/scsi/scsi_debug.c:5300)
[ 1237.946735] scsi_dispatch_cmd (drivers/scsi/scsi_lib.c:1706)
[ 1237.947720] scsi_queue_rq (drivers/scsi/scsi_lib.c:1996)
[ 1237.948687] __blk_mq_run_hw_queue (block/blk-mq.c:816)
[ 1237.949796] blk_mq_run_hw_queue (block/blk-mq.c:896)
[ 1237.950903] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:154 kernel/locking/spinlock.c:183)
[ 1237.951862] blk_mq_insert_request (block/blk-mq.c:1037)
[ 1237.952876] blk_execute_rq_nowait (block/blk-exec.c:95)
[ 1237.953981] ? lockdep_init_map (kernel/locking/lockdep.c:3034)
[ 1237.954967] blk_execute_rq (block/blk-exec.c:131)
[ 1237.955929] ? blk_rq_bio_prep (block/blk-core.c:2835)
[ 1237.956913] scsi_execute (drivers/scsi/scsi_lib.c:252)
[ 1237.957821] scsi_execute_req_flags (drivers/scsi/scsi_lib.c:281)
[ 1237.958968] scsi_report_opcode (drivers/scsi/scsi.c:956)
[ 1237.960009] sd_revalidate_disk (drivers/scsi/sd.c:2707 drivers/scsi/sd.c:2792)
[ 1237.961139] revalidate_disk (fs/block_dev.c:1081)
[ 1237.962223] sd_rescan (drivers/scsi/sd.c:1532)
[ 1237.963142] scsi_rescan_device (drivers/scsi/scsi_scan.c:1579)
[ 1237.964165] store_rescan_field (drivers/scsi/scsi_sysfs.c:672)
[ 1237.965254] dev_attr_store (drivers/base/core.c:138)
[ 1237.966319] sysfs_kf_write (fs/sysfs/file.c:131)
[ 1237.967289] kernfs_fop_write (fs/kernfs/file.c:311)
[ 1237.968274] do_readv_writev (fs/read_write.c:722 fs/read_write.c:854)
[ 1237.969295] ? __acct_update_integrals (kernel/tsacct.c:145)
[ 1237.970452] ? kernfs_fop_open (fs/kernfs/file.c:271)
[ 1237.971505] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:154 kernel/locking/spinlock.c:183)
[ 1237.972512] ? context_tracking_user_exit (include/linux/vtime.h:89 include/linux/jump_label.h:114 include/trace/events/context_tracking.h:47 kernel/context_tracking.c:140)
[ 1237.973668] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2578 kernel/locking/lockdep.c:2625)
[ 1237.974882] ? trace_hardirqs_on (kernel/locking/lockdep.c:2633)
[ 1237.975850] vfs_writev (fs/read_write.c:893)
[ 1237.976691] SyS_writev (fs/read_write.c:926 fs/read_write.c:917)
[ 1237.977538] system_call_fastpath (arch/x86/kernel/entry_64.S:423)
Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

"sp->desc[i]" has 25 characters.  "dev->name" has 15 characters.  If we
used all 15 characters then the sprintf() would overflow.

I changed the "sprintf(sp->name, "%s Neterion %s"" to snprintf(), as
well, even though it can't overflow just to be consistent.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.

As a minimal fix for stable, don't use window 13. A full fix will
follow later.

Fixes: fddddb52 ("bus: introduce an Marvell EBU MBus driver")
Cc: <stable@vger.kernel.org> # v3.10+
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>

Read OCP register 0xa43a~0xa43b would clear some flags which the hw
would use, and it may let the device lost. However, the unit of
reading is 4 bytes. That is, it would read 0xa438~0xa43b when calling
sram_read() to read OCP_SRAM_DATA.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For ocp_write_word() and ocp_write_byte(), there is a generic_ocp_read()
which is used to read the whole 4 byte data, keep the unchanged bytes,
and modify the expected bytes. However, the "byen" could be used to
determine which bytes of the 4 bytes to write, so the action could be
removed.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

IRQs should only get activated when there is nothing to poll in the
queue any more and to after every poll.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

napi should get registered before the netdev and not after.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>