Commit 561eb9d0 ("fbdev: omap/lcd: Make callbacks optional") made
panel callbacks optional but forgot to update check_required_callbacks().
As a result many (all?) OMAP systems using omapfb will crash at boot.
Fix by deleting the whole function.

Fixes: 561eb9d0 ("fbdev: omap/lcd: Make callbacks optional")
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

The raw_spinlock in the IMX GPCV2 interupt chip is not initialized before
usage. That results in a lockdep splat:

  INFO: trying to register non-static key.
  the code is fine but needs lockdep annotation.
  turning off the locking correctness validator.

Add the missing raw_spin_lock_init() to the setup code.

Fixes: e324c4dc ("irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources")
Signed-off-by: NTyler Baker <tyler.baker@linaro.org>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Cc: jason@lakedaemon.net
Cc: marc.zyngier@arm.com
Cc: shawnguo@kernel.org
Cc: andrew.smirnov@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20170413222731.5917-1-tyler.baker@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The copy_page is optimized memcpy for page-alinged address.  If it is
used with non-page aligned address, it can corrupt memory which means
system corruption.  With zram, it can happen with

1. 64K architecture
2. partial IO
3. slub debug

Partial IO need to allocate a page and zram allocates it via kmalloc.
With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
address.  And finally, copy_page(mem, cmem) corrupts memory.

So, this patch changes it to memcpy.

Actuaully, we don't need to change zram_bvec_write part because zsmalloc
returns page-aligned address in case of PAGE_SIZE class but it's not
good to rely on the internal of zsmalloc.

Note:
 When this patch is merged to stable, clear_page should be fixed, too.
 Unfortunately, recent zram removes it by "same page merge" feature so
 it's hard to backport this patch to -stable tree.

I will handle it when I receive the mail from stable tree maintainer to
merge this patch to backport.

Fixes: 42e99bd9 ("zram: optimize memory operations with clear_page()/copy_page()")
Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.orgSigned-off-by: NMinchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In zram_rw_page, the logic to get offset is wrong by operator precedence
(i.e., "<<" is higher than "&").  With wrong offset, zram can corrupt
the user's data.  This patch fixes it.

Fixes: 8c7f0102 ("zram: implement rw_page operation of zram")
Link: http://lkml.kernel.org/r/1492042622-12074-1-git-send-email-minchan@kernel.orgSigned-off-by: NMinchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Revert commit 57707a9a (ACPICA: Resources: Not a valid resource if
buffer length too long) as it is reported to prevent the TPM module
from loading on Lenovo X60 with Coreboot.

It also causes new confusing warnings to show up in the kernel log.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=195311Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 10c7e20b (ACPI / scan: fix enumeration (visited) flags for
bus rescans) attempted to fix a problem with ACPI-based enumerateion
of I2C/SPI devices, but it forgot to ensure that the visited flag
will be set for all of the other enumerated devices, so fix that.

Fixes: 10c7e20b (ACPI / scan: fix enumeration (visited) flags for bus rescans)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885Reported-and-tested-by: NKevin Locke <kevin@kevinlocke.name>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: 4.8+ <stable@vger.kernel.org> # 4.8+

There is a report that after commit 27622b06 ("cpufreq: Convert
to hotplug state machine"), the normal CPU offline/online cycle
fails on some platforms.

According to the ftrace result, this problem was triggered on
platforms using acpi-cpufreq as the default cpufreq driver,
and due to the lack of some ACPI freq method (eg. _PCT),
cpufreq_online() failed and returned a negative value, so the CPU
hotplug state machine rolled back the CPU online process.  Actually,
from the user's perspective, the failure of cpufreq_online() should
not prevent that CPU from being brought up, although cpufreq might
not work on that CPU.

BTW, during system startup cpufreq_online() is not invoked via CPU
online but by the cpufreq device creation process, so the APs can be
brought up even though cpufreq_online() fails in that stage.

This patch ignores the return value of cpufreq_online/offline() and
lets the cpufreq framework deal with the failure.  cpufreq_online()
itself will do a proper rollback in that case and if _PCT is missing,
the ACPI cpufreq driver will print a warning if the corresponding
debug options have been enabled.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194581
Fixes: 27622b06 ("cpufreq: Convert to hotplug state machine")
Reported-and-tested-by: NTomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 4.9+ <stable@vger.kernel.org> # 4.9+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.
Reported-by: NTommi Rantala <tommi.t.rantala@nokia.com>
Tested-by: NTommi Rantala <tommi.t.rantala@nokia.com>
Signed-off-by: NKees Cook <keescook@chromium.org>

Add the missing unlock before return from function etnaviv_gpu_submit()
in the error handling case.

lst: fixed label name.

Fixes: f3cd1b06 ("drm/etnaviv: (re-)protect fence allocation with
GPU mutex")
CC: stable@vger.kernel.org #4.9+
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

On SPARC, the udl driver filled my kernel log with these messages:

[186668.910612] Kernel unaligned access at TPC[76609c] udl_render_hline+0x13c/0x3a0

Use put_unaligned_be16 to avoid them. On x86 this results in the same
code, but on SPARC the compiler emits two single-byte stores.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Acked-by: NDavid Airlie <airlied@linux.ie>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170407200229.20642-1-j.neuschaefer@gmx.net

Only call synchronize_rcu_expedited after unlocking struct_mutex to
avoid deadlock because the workqueues depend on struct_mutex.

>From original patch by Andrea:

synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
hang until its own workqueues are run. The i915 gem workqueues will
wait on the struct_mutex to be released. So we cannot wait for a
quiescent state using those rcu primitives while holding the
struct_mutex or it creates a circular lock dependency resulting in
kernel hangs (which is reproducible but goes undetected by lockdep).

kswapd0         D    0   700      2 0x00000000
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? _synchronize_rcu_expedited.constprop.65+0x2ef/0x300
? wake_up_bit+0x20/0x20
? rcu_stall_kick_kthreads.part.54+0xc0/0xc0
? rcu_exp_wait_wake+0x530/0x530
? i915_gem_shrink+0x34b/0x4b0
? i915_gem_shrinker_scan+0x7c/0x90
? i915_gem_shrinker_scan+0x7c/0x90
? shrink_slab.part.61.constprop.72+0x1c1/0x3a0
? shrink_zone+0x154/0x160
? kswapd+0x40a/0x720
? kthread+0xf4/0x130
? try_to_free_pages+0x450/0x450
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30
plasmashell     D    0  4657   4614 0x00000000
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? i915_gem_close_object+0x26/0xc0
? i915_gem_close_object+0x26/0xc0
? drm_gem_object_release_handle+0x48/0x90
? drm_gem_handle_delete+0x50/0x80
? drm_ioctl+0x1fa/0x420
? drm_gem_handle_create+0x40/0x40
? pipe_write+0x391/0x410
? __vfs_write+0xc6/0x120
? do_vfs_ioctl+0x8b/0x5d0
? SyS_ioctl+0x3b/0x70
? entry_SYSCALL_64_fastpath+0x13/0x94
kworker/0:0     D    0 29186      2 0x00000000
Workqueue: events __i915_gem_free_work
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? del_timer_sync+0x44/0x50
? update_curr+0x57/0x110
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_work+0x2d/0x40
? process_one_work+0x13a/0x3b0
? worker_thread+0x4a/0x460
? kthread+0xf4/0x130
? process_one_work+0x3b0/0x3b0
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30

Fixes: 3d3d18f0 ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")
Reported-by: NAndrea Arcangeli <aarcange@redhat.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 8f612d05)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

i915 is currently doing a full GPU reset at the end of
i915_gem_suspend() followed by GuC suspend in i915_drm_suspend(). This
GPU reset clobbers the GuC, causing the suspend request to then fail,
leaving the GuC in an undefined state. We need to tell the GuC to
suspend before we do the direct intel_gpu_reset().

v2: Commit message update. (Chris, Daniele)

Fixes: 1c777c5d ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state")
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491387710-20553-1-git-send-email-sagar.a.kamble@intel.comReviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit fd089233)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit 279967a6.

Multiple regressions [1] [2] [3] have been reported. The hid-rmi
support would have to fixed and redone in 4.11+.

[1] http://lkml.kernel.org/r/b79b88c8-770a-13f6-5668-c3a94254e5e0@gmail.com
[2] http://lkml.kernel.org/r/375e67b5-2cb8-3491-1d71-d8650d6e9451@gmail.com
[3] https://bugzilla.kernel.org/show_bug.cgi?id=195287Reported-by: NCameron Gutman <aicommander@gmail.com>
Reported-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: NLorenzo J. Lucchini <ljlbox@tiscali.it>
Reported-by: NThorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

After commit 47c950d1 ("pinctrl: cherryview: Do not add all
southwest and north GPIOs to IRQ domain") the driver does not add all
GPIOs to the irqdomain. The reason for that is that those GPIOs cannot
generate IRQs at all, only GPEs (General Purpose Events). This causes
Linux virtual IRQ numbering to change.

However, it seems some CYAN Chromebooks, including Acer Chromebook
hardcodes these Linux IRQ numbers in the ACPI tables of the machine.
Since the numbering is different now, the IRQ meant for keyboard does
not match the Linux virtual IRQ number anymore making the keyboard
non-functional.

Work this around by adding special quirk just for these machines where
we add back all GPIOs to the irqdomain. Rest of the Cherryview/Braswell
based machines will not be affected by the change.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=194945
Fixes: 47c950d1 ("pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain")
Reported-by: NAdam S Levy <theadamlevy@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Commit 57e5568f ("sata_via: Implement hotplug for VT6421") adds
hotplug IRQ handler for VT6421 but enables hotplug on all chips. This
is a bug because it causes "irq xx: nobody cared" error on VT6420 when
hot-(un)plugging a drive:

[  381.839948] irq 20: nobody cared (try booting with the "irqpoll" option)
[  381.840014] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc5+ #148
[  381.840066] Hardware name:          P4VM800/P4VM800, BIOS P1.60 05/29/2006
[  381.840117] Call Trace:
[  381.840167]  <IRQ>
[  381.840225]  ? dump_stack+0x44/0x58
[  381.840278]  ? __report_bad_irq+0x14/0x97
[  381.840327]  ? handle_edge_irq+0xa5/0xa5
[  381.840376]  ? note_interrupt+0x155/0x1cf
[  381.840426]  ? handle_edge_irq+0xa5/0xa5
[  381.840474]  ? handle_irq_event_percpu+0x32/0x38
[  381.840524]  ? handle_irq_event+0x1f/0x38
[  381.840573]  ? handle_fasteoi_irq+0x69/0xb8
[  381.840625]  ? handle_irq+0x4f/0x5d
[  381.840672]  </IRQ>
[  381.840726]  ? do_IRQ+0x2e/0x8b
[  381.840782]  ? common_interrupt+0x2c/0x34
[  381.840836]  ? mwait_idle+0x60/0x82
[  381.840892]  ? arch_cpu_idle+0x6/0x7
[  381.840949]  ? do_idle+0x96/0x18e
[  381.841002]  ? cpu_startup_entry+0x16/0x1a
[  381.841057]  ? start_kernel+0x319/0x31c
[  381.841111]  ? startup_32_smp+0x166/0x168
[  381.841165] handlers:
[  381.841219] [<c12a7263>] ata_bmdma_interrupt
[  381.841274] Disabling IRQ #20

Seems that VT6420 can do hotplug too (there's no documentation) but the
comments say that SCR register access (required for detecting hotplug
events) can cause problems on these chips.

For now, just keep hotplug disabled on anything other than VT6421.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

virtio-pci registers a per-vq affinity hint when using MSIX,
but fails to remove it when freeing the interrupt, resulting
in this type of splat:

[   31.111202] WARNING: CPU: 0 PID: 2823 at kernel/irq/manage.c:1503 __free_irq+0x2c4/0x2c8
[   31.114689] Modules linked in:
[   31.116101] CPU: 0 PID: 2823 Comm: kexec Not tainted 4.10.0+ #6941
[   31.118911] Hardware name: Generic DT based system
[   31.121319] [<c022fb78>] (unwind_backtrace) from [<c0229d8c>] (show_stack+0x18/0x1c)
[   31.125017] [<c0229d8c>] (show_stack) from [<c05192f4>] (dump_stack+0x84/0x98)
[   31.128427] [<c05192f4>] (dump_stack) from [<c023d940>] (__warn+0xf4/0x10c)
[   31.131910] [<c023d940>] (__warn) from [<c023da20>] (warn_slowpath_null+0x28/0x30)
[   31.135543] [<c023da20>] (warn_slowpath_null) from [<c0290238>] (__free_irq+0x2c4/0x2c8)
[   31.139355] [<c0290238>] (__free_irq) from [<c02902d0>] (free_irq+0x44/0x78)
[   31.142909] [<c02902d0>] (free_irq) from [<c059d3a8>] (vp_del_vqs+0x68/0x1c0)
[   31.146299] [<c059d3a8>] (vp_del_vqs) from [<c056ca4c>] (pci_device_shutdown+0x3c/0x78)

The obvious fix is to drop the affinity hint before freeing the
interrupt.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit 5c34d002.

Conflicts:
	drivers/virtio/virtio_pci_common.c

The cleanup seems to be one of the changes that broke
hybernation for some users. We are still not sure why
but revert helps.

This reverts the cleanup changes but keeps the affinity support.
Tested-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit 07ec5148.

Conflicts:
	drivers/virtio/virtio_pci_common.c

Unfortunately the idea does not work with threadirqs
as more than 32 queues can then map to a single interrupts.

Further, the cleanup seems to be one of the changes that broke
hybernation for some users. We are still not sure why
but revert helps.

This reverts the cleanup changes but keeps the affinity support.
Tested-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit 53a020c6.

The cleanup seems to be one of the changes that broke
hybernation for some users. We are still not sure why
but revert helps.
Tested-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit 52a61516.

Conflicts:
	drivers/virtio/virtio_pci_common.c

The cleanup seems to be one of the changes that broke
hybernation for some users. We are still not sure why
but revert helps.

This reverts the cleanup changes but keeps the affinity support.
Tested-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit de85ec8b.

Follow-up patches will revert 07ec5148 ("virtio_pci: use shared
interrupts for virtqueues") that triggered the problem so no need for
this one anymore.
Tested-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The commit 1259fedd("pinctrl: samsung: Fix the width of
PINCFG_TYPE_DRV bitfields for Exynos5433") already fixed
the different width of PINCFG_TYPE_DRV from previous Exynos SoC.

However wrong merge conflict resolution was chosen in commit
7f36f5d1 ("Merge tag 'v4.10-rc6' into devel") effectively dropping
the changes for PINCFG_TYPE_DRV.  Re-do them here.

The macro EXYNOS_PIN_BANK_EINTW is no longer used so remove it.

Fixes: 7f36f5d1 ("Merge tag 'v4.10-rc6' into devel")
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add FMODE_LSEEK to ashmem file.

Comment From Greg Hackmann:
	ashmem_llseek() passes the llseek() call through to the backing
	shmem file.  91360b02 ("ashmem: use vfs_llseek()") changed
	this from directly calling the file's llseek() op into a VFS
	layer call.  This also adds a check for the FMODE_LSEEK bit, so
	without that bit ashmem_llseek() now always fails with -ESPIPE.

Fixes: 91360b02 ("ashmem: use vfs_llseek()")
Signed-off-by: NShuxiao Zhang <zhangshuxiao@xiaomi.com>
Tested-by: NGreg Hackmann <ghackmann@google.com>
Cc: stable <stable@vger.kernel.org> # 3.18+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

While running the srp-test software I noticed that request
processing stalls sporadically at the beginning of a test, namely
when mkfs is run against a dm-mpath device. Every time when that
happened the following command was sufficient to resume request
processing:

    echo run >/sys/kernel/debug/block/dm-0/state

This patch avoids that such request processing stalls occur. The
test I ran is as follows:

    while srp-test/run_tests -d -r 30 -t 02-mq; do :; done
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: NJens Axboe <axboe@fb.com>

If a .queue_rq() function returns BLK_MQ_RQ_QUEUE_BUSY then the block
driver that implements that function is responsible for rerunning the
hardware queue once requests can be queued again successfully.

commit 52d7f1b5 ("blk-mq: Avoid that requeueing starts stopped
queues") removed the blk_mq_stop_hw_queue() call from scsi_queue_rq()
for the BLK_MQ_RQ_QUEUE_BUSY case. Hence change all calls to functions
that are intended to rerun a busy queue such that these examine all
hardware queues instead of only stopped queues.

Since no other functions than scsi_internal_device_block() and
scsi_internal_device_unblock() should ever stop or restart a SCSI
queue, change the blk_mq_delay_queue() call into a
blk_mq_delay_run_hw_queue() call.

Fixes: commit 52d7f1b5 ("blk-mq: Avoid that requeueing starts stopped queues")
Fixes: commit 7e79dadc ("blk-mq: stop hardware queue in blk_mq_delay_queue()")
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagi@grimberg.me>
Cc: Long Li <longli@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

Connecting to the backend isn't working reliably in xen-fbfront: in
case XenbusStateInitWait of the backend has been missed the backend
transition to XenbusStateConnected will trigger the connected state
only without doing the actions required when the backend has
connected.

Cc: stable@vger.kernel.org
Signed-off-by: NJuergen Gross <jgross@suse.com>
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

SSD1306 needs VBAT when it is wired in charge pump configuration only.
Other controllers of the SSD1307 family do not need it at all. This was
introduced by commit ba14301e ("fbdev/ssd1307fb: add support to
enable VBAT").

Without VBAT configuration the driver now fails with:

	failed to get VBAT regulator: -19

This is caused by misinterpretation of devm_regulator_get_optional
which "returns a struct regulator corresponding to the regulator
producer or IS_ERR() condition".

Handle -ENODEV without bailing out and making VBAT support really
optional.
Signed-off-by: NBastian Stender <bst@pengutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Roger Quadros <rogerq@ti.com>
[b.zolnierkie: minor fixups]
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

We try to disable callbacks on c_ivq even without multiport
even though that vq is not initialized in this configuration.

Fixes: c743d09d ("virtio: console: Disable callbacks for virtqueues at start of S4 freeze")
Suggested-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

virtio attempts to clear the MTU feature bit if the value is out of the
supported range, but this has no real effect since FEATURES_OK has
already been set.

Fix this up by checking the MTU in the new validate callback.

Fixes: 14de9d11 ("virtio-net: Add initial MTU advice feature")
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Some drivers can't support all features in all configurations.  At the
moment we blindly set FEATURES_OK and later FAILED.  Support this better
by adding a callback drivers can use to do some early checks.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

If one enables e.g. jumbo frames without mergeable
buffers, packets won't fit in 1500 byte buffers
we use. Switch to big packet mode instead.
TODO: make sizing more exact, possibly extend small
packet mode to use larger pages.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Recent pinctrl changes to allow dynamic allocation of pins exposed one
more issue with the pinctrl pins claimed early by the controller itself.
This caused a regression for IMX6 pinctrl hogs.

Before enabling the pin controller driver we need to wait until it has
been properly initialized, then claim the hogs, and only then enable it.

To fix the regression, split the code into pinctrl_claim_hogs() and
pinctrl_enable(). And then let's require that pinctrl_enable() is always
called by the pin controller driver when ready after calling
pinctrl_register_and_init().

Depends-on: 950b0d91 ("pinctrl: core: Fix regression caused by delayed
work for hogs")
Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
Fixes: e566fc11 ("pinctrl: imx: use generic pinctrl helpers for
managing groups")
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Mika Penttilä <mika.penttila@nextfour.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NGary Bisson <gary.bisson@boundarydevices.com>
Tested-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If the PWM was not enabled at U-Boot loader, PWM could not work for
clock always disabled at PWM driver. The PWM clock is enabled at
beginning of pwm_apply(), but disabled at end of pwm_apply().

If the PWM was enabled at U-Boot loader, PWM clock is always enabled
unless closed by ATF. The pwm-backlight might turn off the power at
early suspend, should disable PWM clock for saving power consume.

It is important to provide opportunity to enable/disable clock at PWM
driver, the PWM consumer should ensure correct order to call PWM enable
and disable, and PWM driver ensure state of PWM clock synchronized with
PWM enabled state.

Fixes: 2bf1c98a ("pwm: rockchip: Add support for atomic update")
Cc: stable@vger.kernel.org
Signed-off-by: NDavid Wu <david.wu@rock-chips.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

This device has a different vendor id but responds to initialization.
Signed-off-by: NXiaolei Yu <dreifachstein@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

At least on cherrytrail, the update bit will never go low when the
enabled bit is not set.

This causes the backlight on my cube iwork8 air tablet to never turn on
again after being turned off because in the pwm_lpss_apply enable path
pwm_lpss_update will fail causing an error exit and the enable-bit to
never get set. Any following pwm_lpss_apply calls will fail the
pwm_lpss_is_updating check.

Since the docs say that the update bit should be set before the
enable-bit, split pwm_lpss_update into setting the update-bit and
pwm_lpss_wait_for_update, and move the pwm_lpss_wait_for_update call
in the enable path to after setting the enable-bit.

Fixes: 10d56a4c ("pwm: lpss: Avoid reconfiguring while UPDATE bit...")
Cc: Ilkka Koskinen <ilkka.koskinen@intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

As a preparation for special treatment for Broxton we split Tangier
configuration.

Fixes: b89b4b7a ("pwm: lpss: pci: Enable PWM module on Intel Edison")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Forked from GP106 implementation.

Split out from commit enabling secboot/gr support so that it can be
added to earlier kernels.

Cc: stable@vger.kernel.org	[4.10+]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

When the atomic support was added to nouveau, the DRM core did not do this.

However, later in the same merge window, a commit (drm/fence: add in-fences
support) was merged that added it, leading to use-after-frees of the fence
object.

Cc: stable@vger.kernel.org	[4.10+]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Cc: stable@vger.kernel.org	[4.10+]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
and PCI varieties, rather than a core PCIE chip with a bridge for
AGP/PCI as necessary. As a result, it appears that the MMU is also
non-functional. For AGP cards, the vast majority of the NV4A lineup,
this worked out since we force AGP cards to use the nv04 mmu. However
for PCI variants, this did not work.

Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
the suggestion. This should be a no-op for NV4A AGP boards, as they were
using it already.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>