linux-toradex.git/drivers/pinctrl, branch v4.4.73

pinctrl: berlin-bg4ct: fix the value for "sd1a" of pin SCRD0_CRD_PRES

2017-06-17T04:39:37+00:00

[ Upstream commit e82d02580af45663fad6d3596e4344c606e81e10 ]

This should be a typo.

Signed-off-by: Jisheng Zhang 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

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

2017-03-31T07:49:53+00:00

commit a6566710adaa4a7dd5e0d99820ff9c9c30ee5951 upstream.

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: Stephen Boyd 
Reported-by: Timur Tabi 
Signed-off-by: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Do not mask all interrupts in probe

2017-03-26T10:13:17+00:00

commit bcb48cca23ec9852739e4a464307fa29515bbe48 upstream.

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 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

pinctrl: broxton: Use correct PADCFGLOCK offset

2017-02-01T07:30:54+00:00

commit ecc8995363ee6231b32dad61c955b371b79cc4cf upstream.

PADCFGLOCK (and PADCFGLOCK_TX) offset in Broxton actually starts at 0x060
and not 0x090 as used in the driver. Fix it to use the correct offset.

Signed-off-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: sh-pfc: Do not unconditionally support PIN_CONFIG_BIAS_DISABLE

2017-01-19T19:17:23+00:00

commit 5d7400c4acbf7fe633a976a89ee845f7333de3e4 upstream.

Always stating PIN_CONFIG_BIAS_DISABLE is supported gives untrue output
when examining /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins if
the operation get_bias() is implemented but the pin is not handled by
the get_bias() implementation. In that case the output will state that
"input bias disabled" indicating that this pin has bias control
support.

Make support for PIN_CONFIG_BIAS_DISABLE depend on that the pin either
supports SH_PFC_PIN_CFG_PULL_UP or SH_PFC_PIN_CFG_PULL_DOWN. This also
solves the issue where SoC specific implementations print error messages
if their particular implementation of {set,get}_bias() is called with a
pin it does not know about.

Signed-off-by: Niklas Söderlund 
Acked-by: Laurent Pinchart 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman

pinctrl: meson: fix gpio request disabling other modes

2017-01-19T19:17:22+00:00

commit f24d311f92b516a8aadef5056424ccabb4068e7b upstream.

The pinctrl_gpio_request is called with the "full" gpio number, already
containing the base, then meson_pmx_request_gpio is then called with the
final pin number.
Remove the base addition when calling meson_pmx_disable_other_groups.

Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
CC: Beniamino Galvani 
Signed-off-by: Neil Armstrong 
Acked-by: Kevin Hilman 
Acked-by: Beniamino Galvani 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Prevent possible interrupt storm on resume

2016-11-18T09:48:34+00:00

commit d2cdf5dc58f6970e9d9d26e47974c21fe87983f3 upstream.

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.

Reported-by: Christian Steiner 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Serialize register access in suspend/resume

2016-11-18T09:48:34+00:00

commit 56211121c0825cd188caad05574fdc518d5cac6f upstream.

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.

Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: uniphier: fix .pin_dbg_show() callback

2016-10-07T13:23:41+00:00

commit 10ef8277ec658bf6619da9b3fd65c2db7353c2a4 upstream.

Without this, reading the "pins" in the debugfs causes kernel BUG.

Fixes: 6e9088920258 ("pinctrl: UniPhier: add UniPhier pinctrl core support")
Signed-off-by: Masahiro Yamada 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: at91-pio4: use %pr format string for resource

2016-09-24T08:07:42+00:00

commit 32844138e31347fc0f61d3bf2d7b9c4583f189e3 upstream.

resource_size_t may be defined as 32 or 64 bit depending on configuration,
so it cannot be printed using the normal format strings, as gcc correctly
warns:

pinctrl-at91-pio4.c: In function 'atmel_pinctrl_probe':
pinctrl-at91-pio4.c:1003:41: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
   dev_dbg(dev, "bank %i: hwirq=%u\n", i, res->start);

This changes the format string to use the special "%pr" format
string that prints a resource, and changes the arguments so we
the resource structure directly.

Signed-off-by: Arnd Bergmann 
Acked-by: Ludovic Desroches 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman