linux-stable.git/drivers/pinctrl, branch v4.1.41

pinctrl: qcom: Don't clear status bit on irq_unmask

2017-05-17T19:07:43+00:00

[ Upstream commit a6566710adaa4a7dd5e0d99820ff9c9c30ee5951 ]

Clearing the status bit on irq_unmask will discard any pending interrupt
that did arrive after the irq_ack, i.e. while the IRQ handler function
was executing.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Cc: stable@vger.kernel.org
Cc: Stephen Boyd 
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl/amd: Remove the default de-bounce time

2016-08-31T23:21:09+00:00

[ Upstream commit 8cf4345575a416e6856a6856ac6eaa31ad883126 ]

In the function amd_gpio_irq_enable() and
amd_gpio_direction_input(), remove the code which is setting
the default de-bounce time to 2.75ms.

The driver code shall use the same settings as specified in
BIOS. Any default assignment impacts TouchPad behaviour when
the LevelTrig is set to EDGE FALLING.

Cc: stable@vger.kernel.org
Reviewed-by:  Ken Xue 
Signed-off-by: Nitesh Kumar Agrawal 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: cherryview: prevent concurrent access to GPIO controllers

2016-08-16T12:25:04+00:00

[ Upstream commit 0bd50d719b004110e791800450ad204399100a86 ]

Due to a silicon issue on the Atom X5-Z8000 "Cherry Trail" processor
series, a common lock must be used to prevent concurrent accesses
across the 4 GPIO controllers managed by this driver.

See Intel Atom Z8000 Processor Series Specification Update
(Rev. 005), errata #CHT34, for further information.

Cc: stable 
Signed-off-by: Dan O'Donovan 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: cherryview: Use raw_spinlock for locking

2016-08-16T12:25:04+00:00

[ Upstream commit 109fdf1572be86aaf681e69b30dc5ada90ce6f35 ]

When running -rt kernel and an interrupt happens on a GPIO line controlled by
Intel Cherryview/Braswell pinctrl driver we get:

 BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
 Preemption disabled at:[] cpu_startup_entry+0x17f/0x480

 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #16
  ...
 Call Trace:
    [] dump_stack+0x4a/0x61
  [] ___might_sleep+0xe7/0x170
  [] rt_spin_lock+0x1f/0x50
  [] chv_gpio_irq_ack+0x3d/0xa0
  [] handle_edge_irq+0x75/0x180
  [] generic_handle_irq+0x27/0x40
  [] chv_gpio_irq_handler+0x7e/0x110
  [] handle_irq+0xaa/0x190
  ...

This is because desc->lock is raw_spinlock and is held when chv_gpio_irq_ack()
is called by the genirq core. chv_gpio_irq_ack() in turn takes pctrl->lock
which in -rt is an rt-mutex causing might_sleep() rightfully to complain about
sleeping function called from invalid context.

In order to keep -rt happy but at the same time make sure that register
accesses get serialized, convert the driver to use raw_spinlock instead.

Suggested-by: Linus Walleij 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: cherryview: Serialize all register access

2016-08-16T12:25:03+00:00

[ Upstream commit 4585b000ace6438d0b142746baab658056b223d9 ]

There is a hardware issue in Intel Braswell/Cherryview where concurrent
GPIO register access might results reads of 0xffffffff and writes might get
dropped.

Prevent this from happening by taking the serializing lock for all places
where it is possible that more than one thread might be accessing the
hardware concurrently.

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

pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs

2016-07-11T03:07:10+00:00

[ Upstream commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe ]

pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
ranging from 1 to MAX. This leads to a corner case where we try to request
the pin number = MAX and fails.

bit_pos value is being calculted using ffs. pin_num_from_lsb uses
bit_pos value. pins array is populated with:

pin + pin_num_from_lsb.

The above is 1 more than usual bit indices as bit_pos uses ffs to compute
first set bit. Hence the last of the pins array is populated with the MAX
value and not MAX - 1 which causes error when we call pin_request.

mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
Consequently val_pos and submask are correct.

Hence use __ffs which gives (ffs(x) - 1) as the first bit set.

fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
Signed-off-by: Keerthy 
Acked-by: Tony Lindgren 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: nomadik: fix pull debug print inversion

2016-07-11T03:07:07+00:00

[ Upstream commit 6ee334559324a55725e22463de633b99ad99fcad ]

Pull up was reported as pull down and vice versa. Fix this.

Fixes: 8f1774a2a971 "pinctrl: nomadik: improve GPIO debug prints"
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: single: Fix missing flush of posted write for a wakeirq

2016-07-11T00:20:01+00:00

[ Upstream commit 0ac3c0a4025f41748a083bdd4970cb3ede802b15 ]

With many repeated suspend resume cycles, the pin specific wakeirq
may not always work on omaps. This is because the write to enable the
pin interrupt may not have reached the device over the interconnect
before suspend happens.

Let's fix the issue with a flush of posted write with a readback.

Cc: stable@vger.kernel.org
Reported-by: Nishanth Menon 
Signed-off-by: Tony Lindgren 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: imx: Do not treat a PIN without MUX register as an error

2016-07-11T00:20:01+00:00

[ Upstream commit ba562d5e54fd3136bfea0457add3675850247774 ]

Some PINs do not have a MUX register, it is not an error.
It is necessary to allow the continuation of the PINs configuration,
otherwise the whole PIN-group will be configured incorrectly.

Cc: stable@vger.kernel.org
Signed-off-by: Alexander Shiyan 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: mediatek: fix dual-edge code defect

2016-06-17T13:11:50+00:00

[ Upstream commit 5edf673d07fdcb6498be24914f3f38f8d8843199 ]

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.

Cc: stable@vger.kernel.org
Signed-off-by: Hongkun Cao 
Reviewed-by: Matthias Brugger 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin