linux-stable.git/drivers/pinctrl/intel, branch v4.9

pinctrl: cherryview: Prevent possible interrupt storm on resume

2016-11-04T21:23:04+00:00

When the system is suspended to S3 the BIOS might re-initialize certain
GPIO pins back to their original state or it may re-program interrupt mask
of others. For example Acer TravelMate B116-M had BIOS bug where certain
GPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the
pin state was high once the BIOS gave control to the OS on resume.

This triggers lots of messages like:

 irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0
 ->handle_irq():  ffffffff8109b613, handle_bad_irq+0x0/0x1e0
 ->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview]
 ->action():           (null)
    IRQ_NOPROBE set

We reset the mask back to known state in chv_pinctrl_resume() but that is
called only after device interrupts have already been enabled.

Now, this particular issue was fixed by upgrading the BIOS to the latest
(v1.23) but not everybody upgrades their BIOSes so we fix it up in the
driver as well.

Prevent the possible interrupt storm by moving suspend and resume hooks to
be called at _noirq time instead. Since device interrupts are still
disabled we can restore the mask back to known state before interrupt storm
happens.

Cc: stable@vger.kernel.org
Reported-by: Christian Steiner 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: cherryview: Serialize register access in suspend/resume

2016-11-04T21:22:28+00:00

If async suspend is enabled, the driver may access registers concurrently
with another instance which may fail because of the bug in Cherryview GPIO
hardware. Prevent this by taking the shared lock while accessing the
hardware in suspend and resume hooks.

Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: intel: Only restore pins that are used by the driver

2016-10-18T12:38:16+00:00

Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend
to explicitly disable USB touchscreen interrupt. This is done to prevent
situation where the lid is closed the touchscreen is left functional.

The pinctrl driver (wrongly) assumes it owns all pins which are owned by
host and not locked down. It is perfectly fine for BIOS to use those pins
as it is also considered as host in this context.

What happens is that when the lid of Dell XPS 13 is closed, the BIOS
configures CPU_GP_1 low disabling the touchscreen interrupt. During resume
we restore all host owned pins to the known state which includes CPU_GP_1
and this overwrites what the BIOS has programmed there causing the
touchscreen to fail as no interrupts are reaching the CPU anymore.

Fix this by restoring only those pins we know are explicitly requested by
the kernel one way or other.

Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361
Reported-by: AceLan Kao 
Tested-by: AceLan Kao 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: baytrail: Fix lockdep

2016-10-18T12:36:13+00:00

Initialize the spinlock before using it.

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4
Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014
 0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000
 0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002
 ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0
Call Trace:
 [] dump_stack+0x67/0x90
 [] register_lock_class+0x52e/0x540
 [] __lock_acquire+0x81/0x16b0
 [] ? save_trace+0x41/0xd0
 [] ? __lock_acquire+0x13b2/0x16b0
 [] ? __lock_is_held+0x4a/0x70
 [] lock_acquire+0xba/0x220
 [] ? byt_gpio_get_direction+0x3e/0x80
 [] _raw_spin_lock_irqsave+0x47/0x60
 [] ? byt_gpio_get_direction+0x3e/0x80
 [] byt_gpio_get_direction+0x3e/0x80
 [] gpiochip_add_data+0x319/0x7d0
 [] ? _raw_spin_unlock_irqrestore+0x43/0x70
 [] byt_pinctrl_probe+0x2fb/0x620
 [] platform_drv_probe+0x3c/0xa0
...

Based on the diff it looks like the problem was introduced in
commit 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
but I wasn't able to verify that empirically as the parent commit
just oopsed when I tried to boot it.

Cc: Cristina Ciocan 
Cc: stable@vger.kernel.org
Fixes: 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
Signed-off-by: Ville Syrjälä 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij

Merge branch 'fixes' into devel

2016-09-23T15:41:40+00:00

pinctrl: intel: Configure GPIO chip IRQ as wakeup interrupts

2016-09-23T13:14:21+00:00

On some Intel BXT platform, wake-up from suspend-to-idle on pressing
power-button is not working. Its noticed that gpio-keys driver marking the
second level IRQ/power-button as wake capable but Intel pintctrl
driver is missing to mark GPIO chip/controller IRQ which first level IRQ
as wake cable if its GPIO pin IRQ is wakeble. So, though the first level
IRQ gets generated on power-button press, since it is not marked as
wake capable resume/wake-up flow is not happening.
Intel pintctrl/GPIO driver need to mark GPIO chip/controller IRQ (first
level IRQ) as wake capable iff GPIO pin's IRQ (second level IRQ) is marked
as wake cable.

Changes in v2:
 - Add missing irq initialisation.

Signed-off-by: Nilesh Bacchewar 
Reviewed-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: cherryview: Convert to use devm_gpiochip_add_data()

2016-09-23T12:59:42+00:00

This simplifies the error handling and allows us to drop the whole
chv_pinctrl_remove() function.

Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain

2016-09-23T12:57:33+00:00

It turns out that for north and southwest communities, they can only
generate GPIO interrupts for lower 8 interrupts (IntSel value). The upper
part (8-15) can only generate GPEs (General Purpose Events).

Now the reason why EC events such as pressing hotkeys does not work if we
mask all the interrupts is that in order to generate either interrupts or
GPEs the INTMASK register must have that particular interrupt unmasked. In
case of GPEs the CPU does not trigger normal interrupt (and thus the GPIO
driver does not see it) but instead it causes SCI (System Control
Interrupt) to be triggered with the GPE in question set.

To make this all work as expected we only add those GPIOs to the IRQ domain
that can actually generate interrupts (IntSel value 0-7) and skip others.

Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: intel: merrifield: fix dup size in probe

2016-09-12T13:45:16+00:00

In function mrfld_pinctrl_probe(), when duplicating the mrfld_families
array the requested memory region length is multiplied once too many by the
number of elements in the original array. Fix this to spare some memory.

Fixes: 4e80c8f505741cbd ("pinctrl: intel: Add Intel Merrifield pin controller support")
Signed-off-by: Vincent Stehlé 
Acked-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

pinctrl: cherryview: Do not mask all interrupts in probe

2016-08-22T13:57:04+00:00

The Cherryview GPIO controller has 8 or 16 wires connected to the I/O-APIC
which can be used directly by the platform/BIOS or drivers. One such wire
is used as SCI (System Control Interrupt) which ACPI depends on to be able
to trigger GPEs (General Purpose Events).

The pinctrl driver itself uses another IRQ resource which is wire OR of all
the 8 (or 16) wires and follows what BIOS has programmed to the IntSel
register of each pin.

Currently the driver masks all interrupts at probe time and this prevents
these direct interrupts from working as expected. The reason for this is
that some early stage prototypes had some pins misconfigured causing lots
of spurious interrupts.

We fix this by leaving the interrupt mask untouched. This allows SCI and
other direct interrupts work properly. What comes to the possible spurious
interrupts we switch the default handler to be handle_bad_irq() instead of
handle_simple_irq() (which was not correct anyway).

Reported-by: Yu C Chen 
Reported-by: Anisse Astier 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij