kernel/linux.git/drivers, branch v4.6.3

gpio: make sure gpiod_to_irq() returns negative on NULL desc

2016-06-24T17:22:06+00:00

commit 79bb71bd1d93197ce227fa167b450b633f30a52b upstream. commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264 ("gpio: bail out silently on NULL descriptors") doesn't work for gpiod_to_irq(): drivers assume that NULL descriptors will give negative IRQ numbers in return. It has been pointed out that returning 0 is NO_IRQ and that drivers should be amended to treat this as an error, but that is for the longer term: now let us repair the semantics. Cc: Maxime Ripard Reported-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

Revert "drm/i915: Exit cherryview_irq_handler() after one pass"

2016-06-24T17:22:05+00:00

This reverts commit 9dbaab56ac09f07a73fe83bf69bec3e31060080a. Turns out it was a bad idea and was fixed up "properly" in 4.7 but those patches are too big to put into 4.6, so let's just revert it for now. Reported-by: Ville Syrjälä Cc: Daniel Vetter Cc: Peter Frühberger Cc: Chris Wilson Cc: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/core: Do not preserve framebuffer on rmfb, v4.

2016-06-24T17:22:05+00:00

commit f2d580b9a8149735cbc4b59c4a8df60173658140 upstream. It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impossible. There is no way to remove the framebuffer from the lists and active planes without introducing a race because of the different locking requirements. Instead call drm_framebuffer_remove from a workqueue, which is unaffected by signals. Changes since v1: - Add comment. Changes since v2: - Add fastpath for refcount = 1. (danvet) Changes since v3: - Rebased. - Restore lastclose framebuffer removal too. Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.") Testcase: kms_rmfb_basic References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html Cc: Thomas Hellstrom Cc: David Herrmann Reviewed-by: Daniel Vetter Tested-by: Thomas Hellstrom #v3 Tested-by: Tvrtko Ursulin Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/6c63ca37-0e7e-ac7f-a6d2-c7822e3d611f@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

gpio: zynq: initialize clock even without CONFIG_PM

2016-06-24T17:22:04+00:00

commit 0f84f29ff30bdb1bca23017b118b4ea3999cac32 upstream. When the PM initialization was moved in the commit referenced below, the code enabling the clock was removed from the probe function. On CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables the clock, but when power management is disabled, all those pm_* functions are noops and the clock is never enabled resulting in a dysfunctional gpio controller. Put the clock initialization back to support CONFIG_PM=n. Signed-off-by: Helmut Grohne Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: zynq: Fix the error path

2016-06-24T17:22:04+00:00

commit 615d23f80efc60f8c5146223f305d19207c742e4 upstream. pm_runtime_disable is called only in remove it is missed out in the error path. Fix the same. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Linus Walleij Cc: Helmut Grohne Signed-off-by: Greg Kroah-Hartman

pinctrl: mediatek: fix dual-edge code defect

2016-06-24T17:22:03+00:00

commit 5edf673d07fdcb6498be24914f3f38f8d8843199 upstream. When a dual-edge irq is triggered, an incorrect irq will be reported on condition that the external signal is not stable and this incorrect irq has been registered. Correct the register offset. Signed-off-by: Hongkun Cao Reviewed-by: Matthias Brugger Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Fix AES XTS error for request sizes above 4096

2016-06-24T17:22:03+00:00

commit ab6a11a7c8ef47f996974dd3c648c2c0b1a36ab1 upstream. The ccp-crypto module for AES XTS support has a bug that can allow requests greater than 4096 bytes in size to be passed to the CCP hardware. The CCP hardware does not support request sizes larger than 4096, resulting in incorrect output. The request should actually be handled by the fallback mechanism instantiated by the ccp-crypto module. Add a check to insure the request size is less than or equal to the maximum supported size and use the fallback mechanism if it is not. Signed-off-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

gpiolib: Fix unaligned used of reference counters

2016-06-24T17:22:02+00:00

commit f4833b8cc7edab57d3f3033e549111a546c2e02b upstream. gpiolib relies on the reference counters to clean up the gpio_device structure. Although the number of get/put is properly aligned on gpiolib.c itself, it does not take into consideration how the referece counters are affected by other external functions such as cdev_add and device_add. Because of this, after the last call to put_device, the reference counter has a value of +3, therefore never calling gpiodevice_release. Due to the fact that some of the device has already been cleaned on gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call to of_gpiochip_find_and_xlate). Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpiolib: Fix NULL pointer deference

2016-06-24T17:22:02+00:00

commit 11f33a6d15bfa397867ac0d7f3481b6dd683286f upstream. Under some circumstances, a gpiochip might be half cleaned from the gpio_device list. This patch makes sure that the chip pointer is still valid, before calling the match function. [ 104.088296] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [ 104.089772] IP: [] of_gpiochip_find_and_xlate+0x15/0x80 [ 104.128273] Call Trace: [ 104.129802] [] ? of_parse_own_gpio+0x1f0/0x1f0 [ 104.131353] [] gpiochip_find+0x60/0x90 [ 104.132868] [] of_get_named_gpiod_flags+0x9a/0x120 ... [ 104.141586] [] gpio_led_probe+0x11b/0x360 Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings

2016-06-24T17:22:02+00:00

commit b66b2a0adf0e48973b582e055758b9907a7eee7c upstream. The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs() with what looks like the wrong parameter. The write_lock_regs function takes a pointer to the registers, not the bcm_kona_gpio structure. Fix the warning, and probably bug by changing the function to pass reg_base instead of kona_gpio, fixing the following warning: drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1 (different address spaces) expected void [noderef] *reg_base got struct bcm_kona_gpio *kona_gpio warning: incorrect type in argument 1 (different address spaces) expected void [noderef] *reg_base got struct bcm_kona_gpio *kona_gpio Signed-off-by: Ben Dooks Acked-by: Ray Jui Reviewed-by: Markus Mayer Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman