This function is like drm_modeset_lock_all(), but it takes the lock
acquisition context as a parameter rather than storing it in the DRM
device's mode_config structure.

Implement drm_modeset_{,un}lock_all() in terms of the new function for
better code reuse, and add a note to the kerneldoc that new code should
use the new functions.

v2: improve kerneldoc
v4: rename drm_modeset_lock_all_crtcs() to drm_modeset_lock_all_ctx()
    and take mode_config's .connection_mutex instead of .mutex lock to
    avoid lock inversion (Daniel Vetter), use drm_modeset_drop_locks()
    which is now the equivalent of drm_modeset_unlock_all_ctx()
v5: do not take the dev->mode_config.connection_mutex in
    drm_atomic_legacy_backoff() since drm_modeset_lock_all_ctx()
    already keeps it, enhance kerneldoc for drm_modeset_lock_all_ctx()
    (Daniel Vetter)
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449075005-13937-1-git-send-email-thierry.reding@gmail.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's currently two places where the gma500 fault handler relies
upon dev->struct_mutex:
- To protect r->mappping
- To make sure vm_insert_pfn isn't called concurrently (in which case
  the 2nd thread would get an error code).

Everything else (specifically psb_gtt_pin) is already protected by
some other locks. Hence just create a new driver-private mmap_mutex
just for this function.

With this gma500 is complete dev->struct_mutex free!

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-21-git-send-email-daniel.vetter@ffwll.ch

Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-20-git-send-email-daniel.vetter@ffwll.ch

This is init/teardown code, locking is just to appease locking checks.
And since gem create/free doesn't need this any more there's really no
reason for grabbing dev->struct_mutex.

Again important to switch obj_unref to _unlocked variants.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-19-git-send-email-daniel.vetter@ffwll.ch

It's either init code or already protected by other means. Note
that psb_gtt_pin/unpin has it's own lock, and that's really the
only piece of driver private state - all the modeset state is
protected with modeset locks already.

The only important bit is to switch all gem_obj_unref calls to the
_unlocked variant.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-18-git-send-email-daniel.vetter@ffwll.ch

This is called without dev->struct_mutex held, we need to use the
_unlocked variant.

Never caught in the wild since you'd need an evil userspace which
races a gem_close ioctl call with the in-progress open.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-17-git-send-email-daniel.vetter@ffwll.ch

Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
in detailed timings.

drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
which only allows smaller errors for lower clocks (eg. for 25200 it
won't allow any error) and a bigger error for higher clocks (eg. for
297000 it actually matches 296913-297000). So it doesn't really match
what we want for the fixup. Using the explicit +-5kHz is much better
for this use case.

Not sure if we should change the normal mode matching to also use
something else besides KHZ2PICOS() since it allows a different
proportion of error depending on the clock. I believe VESA CVT
allows a maximum deviation of .5%, so using that for normal mode
matching might be a good idea?

Cc: Adam Jackson <ajax@redhat.com>
Tested-by: nathan.d.ciobanu@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
Fixes: fa3a7340 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add drm_atomic_helper_disable_planes_on_crtc() for disabling all
planes associated with the given CRTC. This can be used for instance
in the CRTC helper disable callback to disable all planes before
shutting down the display pipeline.

v2:
- Address Daniels review comments [1]
  - Do atomic_begin() and atomic_flush() always if they are defined and
    atomic knob is set
  - update kerneldoc
- Put drm_atomic_helper_disable_planes_on_crtc() after
  drm_atomic_helper_commit_planes_on_crtc() in drm_atomic_helper.c
  to have functions in the same order as in drm_atomic_helper.h
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448633641-6486-1-git-send-email-jsarha@ti.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The previous patch reintroduced a race condition whereby a failure in
one reader may allow a second reader to see out-of-order events.
Introduce a mutex to serialise readers so that an event is completed in
its entirety before another reader may process an event. The two readers
may race against each other, but the events each retrieves are in the
correct order.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462343-2072-2-git-send-email-chris@chris-wilson.co.ukReviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In

commit cdd1cf79
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Dec 4 21:03:25 2014 +0000

    drm: Make drm_read() more robust against multithreaded races

I fixed the races by serialising the use of the event by extending the
dev->event_lock. However, as Thomas pointed out, the copy_to_user() may
fault (even the __copy_to_user_inatomic() variant used here) and calling
into the driver backend with the spinlock held is bad news. Therefore we
have to drop the spinlock before the copy, but that exposes us to the
old race whereby a second reader could see an out-of-order event (as the
first reader may claim the first request but fail to copy it back to
userspace and so on returning it to the event list it will be behind the
current event being copied by the second reader).
Reported-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462343-2072-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have serious dangling else bugs waiting to happen in our for_each_
style macros with ifs. Consider, for example,

 #define for_each_power_domain(domain, mask)                         \
         for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
                 if ((1 << (domain)) & (mask))

If this is used in context:

	if (condition)
		for_each_power_domain(domain, mask);
	else
		foo();

foo() will be called for each domain *not* in mask, if condition holds,
and not at all if condition doesn't hold.

Fix this by reversing the conditions in the macros, and adding an else
branch for the "for each" block, so that other if/else blocks can't
interfere. Provide a "for_each_if" helper macro to make it easier to get
this right.

v2: move for_each_if to drmP.h in a separate patch.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-2-git-send-email-jani.nikula@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.

v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's an internal of the probe
helpers), or calling ->detect (which is again a layering violation
since it's used only by probe helpers) just call the official
->fill_modes function, like a GET_CONNECTOR ioctl call.

v3: Restore the accidentally removed forced-probe for echo "detect" >
force.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447951610-12622-22-git-send-email-daniel.vetter@ffwll.chReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the correct function name for drm_atomic_clean_old_fb docs.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We chase pointers/lists without taking the locks protecting them,
which isn't that good.

Fix it.

v2: Actually unlock properly, spotted by Julia.

v3: Put the label _before_ the mutex_unlock (Emil)

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Link: http://patchwork.freedesktop.org/patch/msgid/1443783662-23066-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To aid in debugging failures, print the src,dst,clip rectangles
when drm_plane_helper_check_update() fails.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Allow the caller to specify a "prefix" string to drm_rect_debug_print()
to make it easier to see which drm_rect is being printed.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Drivers shouldn't clobber the passed in addfb ioctl parameters.
i915 was doing just that. To prevent it from happening again,
pass the struct around as const, starting all the way from
internal_framebuffer_create().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The simple_strtoul function is marked as obsolete.
This patch replace it by kstrtouint.
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I noticed that intel_fbdev->our_mode is unused. Introduced by
79e53945 ("DRM: i915: add mode setting support").

Then I noticed that intel_fbdev->fbdev_list is unused as well.
Introduced by 38651674 ("drm/fb: fix fbdev object model +
cleanup properly.") in i915, nouveau and radeon.

Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl,
virtio and mgag200.

Already removed from the latter with cc59487a ("drm/mgag200:
'fbdev_list' in 'struct mga_fbdev' is not used").

Remove it from the others.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The drm_property_unreference_blob() function tests whether its argument
is NULL and then returns immediately.
Thus the tests around the calls are not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Link: http://patchwork.freedesktop.org/patch/msgid/563C8B3E.405@users.sourceforge.netSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev
emulation for the tegra kms driver.

Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-4-git-send-email-architt@codeaurora.orgSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev
emulation for the imx kms driver.

Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option where applicable. Using this config lets us also prevent
wrapping around drm_fb_helper_* calls with #ifdefs in certain places.
Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-2-git-send-email-architt@codeaurora.orgSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A bunch of things have been removed meanwhile and docs not fully
brought up to speed. And a few gaps closed where I noticed missing
kerneldoc while reading through the overview sections.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445533889-7661-3-git-send-email-daniel.vetter@ffwll.chReviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

fsl8250_handle_irq is now used by the of_serial driver, and that fails
if it is a loadable module:

ERROR: "fsl8250_handle_irq" [drivers/tty/serial/of_serial.ko] undefined!

This exports the symbol to avoid randconfig errors.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: d43b54d2 ("serial: Enable Freescale 16550 workaround on arm")
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: NJeff Mahoney <jeffm@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

8250_mid uses rational_best_approximation() function, so the
driver needs to select CONFIG_RATIONAL option.

This fixes build error when CONFIG_RATIONAL is not enabled:

drivers/built-in.o: In function `mid8250_set_termios':
8250_mid.c:(.text+0x10169a): undefined reference to `rational_best_approximation'
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The data to audit/record is in the 'from' buffer (ie., the input
read buffer).

Fixes: 72586c60 ("n_tty: Fix auditing support for cannonical mode")
Cc: stable <stable@vger.kernel.org> # 4.1+
Cc: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Acked-by: NLaura Abbott <labbott@fedoraproject.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit 7d8c70d8 ("serial: mctrl-gpio: rename init function"),
crisv32 either do not build or crash as follows.

Unable to handle kernel NULL pointer dereference
Linux 4.3.0-rc7-next-20151101 #1 Sun Nov 1 11:41:28 PST 2015
...
Call Trace: [<c0004a0e>] show_stack+0x0/0x9e
[<c004c0c0>] printk+0x0/0x2c
[<c00059d4>] show_registers+0x14a/0x1c2
[<c004c0c0>] printk+0x0/0x2c
[<c0004b52>] die_if_kernel+0x7c/0x9e
[<c0005346>] do_page_fault+0x32e/0x3e6
[<c01dc59c>] of_get_property+0x0/0x2c
[<c01e0558>] of_irq_parse_raw+0x12a/0x376
[<c01dc59c>] of_get_property+0x0/0x2c
[<c0053aca>] get_page_from_freelist+0x73e/0x856
[<c01dc59c>] of_get_property+0x0/0x2c
[<c0008912>] d_mmu_refill+0x10a/0x112
[<c01b488c>] devm_kmalloc+0x40/0x56
[<c01b47d0>] add_dr+0xc/0x1c
[<c01b4800>] devm_add_action+0x2/0x4e
[<c01abdbc>] mctrl_gpio_init_noauto+0x1c/0x76
[<c01abf9e>] mctrl_gpio_init+0x22/0x110

The function call in the etraxfs-uart driver was not renamed,
possibly due to interference with commit 7b9c5162 ("serial:
etraxfs-uart: use mctrl_gpio helpers for handling modem signals").

Fixes: 7d8c70d8 ("serial: mctrl-gpio: rename init function")
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NNiklas Cassel <nks@flawful.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Earlycon support for Freescale lpuart should only be enabled when
console support is enabled.

Fixes: 1d59b382 ("serial: fsl_lpuart: add earlycon support")
Acked-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the device name when registering an interrupt so that multiple
ports don't all have the same interrupt name.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Recent abstraction of tty buffer work introduced api to manage
tty input kworker; use it.

Fixes: e176058f ("tty: Abstract tty buffer work")
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The correct lock order is atomic_write_lock => termios_rwsem, as
established by tty_write() => n_tty_write().

Fixes: c274f6ef ("tty: Hold termios_rwsem for tcflow(TCIxxx)")
Reported-and-Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

pci_set_dma_mask returns a negative errno value, not a bool like
pci_dma_supported.  This of course was just a giant test for attention :)
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reported-by: NJongman Heo <jongman.heo@samsung.com>
Tested-by: Jongman Heo <jongman.heo@samsung.com>	[pcnet32]
Acked-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Adding Intel codename Lewisburg platform device IDs for SMBus.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch fixes obvious copy-past error in wake up irq parsing
code which leads to the fact that dev_pm_set_wake_irq() will
be called with wrong IRQ number when "wakeup" IRQ is not
defined in DT.

Fixes: 3fffd128 ("i2c: allow specifying separate wakeup interrupt in device tree")
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: <stable@vger.kernel.org> # v4.3

Prior to commit e6c9a037 ("i2c: xiic: Remove the disabling of
interrupts") IRQs where disabled when the initial __xiic_start_xfer() was
called. After the commit the interrupt is enabled while the function is
running, this means it is possible for the interrupt to be triggered while
the function is still running. When this happens the internal data
structures get corrupted and undefined behavior can occur like the
following crash:

	Internal error: Oops: 17 [#1] PREEMPT SMP ARM
	Modules linked in:
	CPU: 0 PID: 2040 Comm: i2cdetect Not tainted 4.0.0-02856-g047a308 #10956
	Hardware name: Xilinx Zynq Platform
	task: ee0c9500 ti: e99a2000 task.ti: e99a2000
	PC is at __xiic_start_xfer+0x6c4/0x7c8
	LR is at __xiic_start_xfer+0x690/0x7c8
	pc : [<c02bbffc>]    lr : [<c02bbfc8>]    psr: 800f0013
	sp : e99a3da8  ip : 00000000  fp : 00000000
	r10: 00000001  r9 : 600f0013  r8 : f0180000
	r7 : f0180000  r6 : c064e444  r5 : 00000017  r4 : ee031010
	r3 : 00000000  r2 : 00000000  r1 : 600f0013  r0 : 0000000f
	Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
	Control: 18c5387d  Table: 29a5404a  DAC: 00000015
	Process i2cdetect (pid: 2040, stack limit = 0xe99a2210)
	Stack: (0xe99a3da8 to 0xe99a4000)
	3da0:                   ee031010 00000000 00000001 ee031020 ee031224 c02bc5ec
	3dc0: ee34c604 00000000 ee0c9500 e99a3dcc e99a3dd0 e99a3dd0 e99a3dd8 c069f0e8
	3de0: 00000000 ee031020 c064e100 ffff90bb e99a3e48 c02b6590 ee031020 00000001
	3e00: e99a3e48 ee031020 00000000 e99a3e63 00000001 c02b6ec4 00000000 00000000
	3e20: 00000000 c02b7320 e99a3ef0 00000000 00000000 e99e3df0 00000000 00000000
	3e40: 00000103 2814575f 0000003e c00a0000 e99a3e85 0001003e ee0c0000 e99a3e63
	3e60: eefd3578 c064e61c ee0c9500 c0041e04 0000056c e9a56db8 00006e5a b6f5c000
	3e80: ee0c9548 eefd0040 00000001 eefd3540 ee0c9500 eefd39a0 c064b540 ee0c9500
	3ea0: 00000000 ee92b000 00000000 bef4862c ee34c600 e99ecdc0 00000720 00000003
	3ec0: e99a2000 00000000 00000000 c02b8b30 00000000 00000000 00000000 e99a3f24
	3ee0: b6e80000 00000000 00000000 c04257e8 00000000 e99a3f24 c02b8f08 00000703
	3f00: 00000003 c02116bc ee935300 00000000 bef4862c ee34c600 e99ecdc0 c02b91f0
	3f20: e99ecdc0 00000720 bef4862c eeb725f8 e99ecdc0 c00c9e2c 00000003 00000003
	3f40: ee248dc0 00000000 ee248dc8 00000002 eeb7c1a8 00000000 00000000 c00bb360
	3f60: 00000000 00000000 00000003 ee248dc0 bef4862c e99ecdc0 e99ecdc0 00000720
	3f80: 00000003 e99a2000 00000000 c00c9f68 00000000 00000000 b6f22000 00000036
	3fa0: c000dfa4 c000de20 00000000 00000000 00000003 00000720 bef4862c bef4862c
	3fc0: 00000000 00000000 b6f22000 00000036 00000000 00000000 b6f60000 00000000
	3fe0: 00013040 bef48614 00008cab b6ecdbe6 400f0030 00000003 2f7fd821 2f7fdc21
	[<c02bbffc>] (__xiic_start_xfer) from [<c02bc5ec>] (xiic_xfer+0x94/0x168)
	[<c02bc5ec>] (xiic_xfer) from [<c02b6590>] (__i2c_transfer+0x4c/0x7c)
	[<c02b6590>] (__i2c_transfer) from [<c02b6ec4>] (i2c_transfer+0x9c/0xc4)
	[<c02b6ec4>] (i2c_transfer) from [<c02b7320>] (i2c_smbus_xfer+0x3a0/0x4ec)
	[<c02b7320>] (i2c_smbus_xfer) from [<c02b8b30>] (i2cdev_ioctl_smbus+0xb0/0x214)
	[<c02b8b30>] (i2cdev_ioctl_smbus) from [<c02b91f0>] (i2cdev_ioctl+0xa0/0x1d4)
	[<c02b91f0>] (i2cdev_ioctl) from [<c00c9e2c>] (do_vfs_ioctl+0x4b0/0x5b8)
	[<c00c9e2c>] (do_vfs_ioctl) from [<c00c9f68>] (SyS_ioctl+0x34/0x5c)
	[<c00c9f68>] (SyS_ioctl) from [<c000de20>] (ret_fast_syscall+0x0/0x34)
	Code: e283300c e5843210 eafffe64 e5943210 (e1d320b4)

The issue can easily be reproduced by performing I2C access under high
system load or IO load.

To fix the issue protect the invocation to __xiic_start_xfer() form
xiic_start_xfer() with the same lock that is used to protect the interrupt
handler.

Fixes: e6c9a037 ("i2c: xiic: Remove the disabling of interrupts")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NShubhrajyoti Datta <shubhraj@xilinx.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit d701667b ("i2c: xiic: Do not reset controller before every
transfer") removed the reinitialization of the controller before the start
of each transfer. Apparently this change is not safe to make and the commit
results in random I2C bus failures.

An easy way to trigger the issue is to run i2cdetect.

Without the patch applied:
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
	 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
	 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 30: -- -- -- -- -- -- -- -- UU UU -- UU 3c -- -- UU
	 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 70: -- -- -- -- -- -- -- --

With the patch applied every other or so invocation:
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
	 00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
	 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
	 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
	 30: -- -- -- -- -- -- -- -- UU UU -- UU 3c -- -- UU
	 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	 70: -- -- -- -- -- -- -- --

So revert the commit for now.

Fixes: d701667b ("i2c: xiic: Do not reset controller before every transfer")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NShubhrajyoti Datta <shubhraj@xilinx.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

drivers/i2c/busses/i2c-imx.c:978:2: error: implicit declaration of
function ‘pinctrl_select_state’ [-Werror=implicit-function-declaration]
  pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_gpio);
  ^
Signed-off-by: NHou Zhiqiang <Zhiqiang.Hou@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It is not permitted to set task state before lock. usblp_wwait sets
the state to TASK_INTERRUPTIBLE and calls mutex_lock_interruptible.
Upon return from that function, the state will be TASK_RUNNING again.

This is clearly a bug and a warning is generated with LOCKDEP too:
WARNING: CPU: 1 PID: 5109 at kernel/sched/core.c:7404 __might_sleep+0x7d/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffa0c588d0>] usblp_wwait+0xa0/0x310 [usblp]
Modules linked in: ...
CPU: 1 PID: 5109 Comm: captmon Tainted: G        W       4.2.5-0.gef2823b-default #1
Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
 ffffffff81a4edce ffff880236ec7ba8 ffffffff81716651 0000000000000000
 ffff880236ec7bf8 ffff880236ec7be8 ffffffff8106e146 0000000000000282
 ffffffff81a50119 000000000000028b 0000000000000000 ffff8802dab7c508
Call Trace:
...
 [<ffffffff8106e1c6>] warn_slowpath_fmt+0x46/0x50
 [<ffffffff8109a8bd>] __might_sleep+0x7d/0x90
 [<ffffffff8171b20f>] mutex_lock_interruptible_nested+0x2f/0x4b0
 [<ffffffffa0c588fc>] usblp_wwait+0xcc/0x310 [usblp]
 [<ffffffffa0c58bb2>] usblp_write+0x72/0x350 [usblp]
 [<ffffffff8121ed98>] __vfs_write+0x28/0xf0
...

Commit 7f477358 (usblp: Implement the
ENOSPC convention) moved the set prior locking. So move it back after
the lock.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Fixes: 7f477358 ("usblp: Implement the ENOSPC convention")
Acked-By: NPete Zaitcev <zaitcev@yahoo.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When choose randconfig for kernel build, it reports below warning:
"warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG
which has unmet direct dependencies (USB_SUPPORT && USB && PM)"

In fact, USB_OTG is visible symbol and depends on PM, so the driver
needs to depend on it to reduce dependency problem.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Reported-by: NArnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>