linux-stable.git/drivers/pinctrl, branch linux-3.19.y Linux kernel stable tree pinctrl: imx25: fix numbering for pins 2015-03-18T13:11:12+00:00 Uwe Kleine-König u.kleine-koenig@pengutronix.de 2015-01-27T23:45:56+00:00 97df643ce1f1aa7e237bc7c51b6d6fcd848e88fa commit 34027ca2bbc6043fea8fc5c4a82670518b6be7df upstream. The pin id for a given tuple listed in a fsl,pins property is calculated by dividing the first entry (which is also a register offset) by 4. As the first available register is at offset 0x8 and configures the pad MX25_PAD_A10 the right id for this pin is 2. All other pins are off by one, too. This patch drops the definition MX25_PAD_RESERVE1 (together with its only use) and decrements all following values by 1. Fixes: b4a87c9b966f ("pinctrl: pinctrl-imx: add imx25 pinctrl driver") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 34027ca2bbc6043fea8fc5c4a82670518b6be7df upstream.

The pin id for a given tuple listed in a fsl,pins property is calculated
by dividing the first entry (which is also a register offset) by 4.
As the first available register is at offset 0x8 and configures the pad
MX25_PAD_A10 the right id for this pin is 2. All other pins are off by
one, too.

This patch drops the definition MX25_PAD_RESERVE1 (together with its
only use) and decrements all following values by 1.

Fixes: b4a87c9b966f ("pinctrl: pinctrl-imx: add imx25 pinctrl driver")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pinctrl: pinctrl-imx: don't use invalid value of conf_reg 2015-03-18T13:11:12+00:00 Uwe Kleine-König u.kleine-koenig@pengutronix.de 2015-01-27T22:50:25+00:00 b8a2454e51c75fff6a621bdb5a399aab062d956e commit 4ff0f034e95d65f8f063a362dfcf86e986377a82 upstream. The right check for conf_reg to be invalid it testing against -1 not 0 as is done in the rest of the driver. This fixes an oops that can be triggered by: cat /sys/kernel/debug/pinctrl/43fac000.iomuxc/* Fixes: ae75ff814538 ("pinctrl: pinctrl-imx: add imx pinctrl core driver") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4ff0f034e95d65f8f063a362dfcf86e986377a82 upstream.

The right check for conf_reg to be invalid it testing against -1 not 0
as is done in the rest of the driver.

This fixes an oops that can be triggered by:

	cat /sys/kernel/debug/pinctrl/43fac000.iomuxc/*

Fixes: ae75ff814538 ("pinctrl: pinctrl-imx: add imx pinctrl core driver")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pinctrl: at91: allow to have disabled gpio bank 2015-01-26T08:13:36+00:00 Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com 2015-01-16T15:31:05+00:00 a0b957f306fa4d0a39f4ffe5e5e25e856e6be46e Today we expect that all the bank are enabled, and count the number of banks used by the pinctrl based on it instead of using the last bank id enabled. So switch to it, set the chained IRQ at runtime based on enabled banks and wait only the number of enabled gpio controllers at probe time. Cc: <stable@vger.kernel.org> # 3.18 Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Today we expect that all the bank are enabled, and count the number of banks
used by the pinctrl based on it instead of using the last bank id enabled.

So switch to it, set the chained IRQ at runtime based on enabled banks
and wait only the number of enabled gpio controllers at probe time.

Cc: <stable@vger.kernel.org> # 3.18
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: qcom: Don't iterate past end of function array 2015-01-19T10:17:45+00:00 Stephen Boyd sboyd@codeaurora.org 2015-01-19T10:17:45+00:00 bcd53f858d87f52843cc87764b283999126a50d6 Timur reports that this code crashes if nfunctions is 0. Fix the loop iteration to only consider valid elements of the functions array. Reported-by: Timur Tabi <timur@codeaurora.org> Cc: Pramod Gurav <pramod.gurav@smartplayin.com> Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com> Cc: Ivan T. Ivanov <iivanov@mm-sol.com> Cc: Andy Gross <agross@codeaurora.org> Fixes: 327455817a92 "pinctrl: qcom: Add support for reset for apq8064" Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Timur reports that this code crashes if nfunctions is 0. Fix the
loop iteration to only consider valid elements of the functions
array.

Reported-by: Timur Tabi <timur@codeaurora.org>
Cc: Pramod Gurav <pramod.gurav@smartplayin.com>
Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
Cc: Andy Gross <agross@codeaurora.org>
Fixes: 327455817a92 "pinctrl: qcom: Add support for reset for apq8064"
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: lantiq: remove bogus of_gpio_chip_add 2015-01-14T13:20:46+00:00 Johan Hovold johan@kernel.org 2015-01-12T16:20:51+00:00 41f632fe177bc4822c2e8236fe7c291e6e9eb6f8 Remove bogus call to of_gpiochip_add (and of_gpio_chip remove in error path) which is also called when adding the gpio chip. This prevents adding the same pinctrl range twice. Fixes: 3f8c50c9b110 ("OF: pinctrl: MIPS: lantiq: implement lantiq/xway pinctrl support") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Remove bogus call to of_gpiochip_add (and of_gpio_chip remove in error
path) which is also called when adding the gpio chip.

This prevents adding the same pinctrl range twice.

Fixes: 3f8c50c9b110 ("OF: pinctrl: MIPS: lantiq: implement lantiq/xway
pinctrl support")

Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: Fix two deadlocks 2015-01-14T13:20:33+00:00 Jim Lin jilin@nvidia.com 2015-01-08T12:25:05+00:00 db93facfb0ef542aa5d8079e47580b3e669a4d82 This patch is to fix two deadlock cases. Deadlock 1: CPU #1 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #0 pinctrl_unregister (Holding lock pinctrldev_list_mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) Simply to say CPU#1 is holding lock A and trying to acquire lock B, CPU#0 is holding lock B and trying to acquire lock A. Deadlock 2: CPU #3 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #2 pinctrl_unregister (Holding lock pctldev->mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) CPU #0 tegra_gpio_request (Holding lock pinctrldev_list_mutex) -> pinctrl_get_device_gpio_range (Trying to acquire lock pctldev->mutex) Simply to say CPU#3 is holding lock A and trying to acquire lock D, CPU#2 is holding lock B and trying to acquire lock A, CPU#0 is holding lock D and trying to acquire lock B. Cc: Stable <stable@vger.kernel.org> Signed-off-by: Jim Lin <jilin@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
This patch is to fix two deadlock cases.
Deadlock 1:
CPU #1
 pinctrl_register-> pinctrl_get ->
 create_pinctrl
 (Holding lock pinctrl_maps_mutex)
 -> get_pinctrl_dev_from_devname
 (Trying to acquire lock pinctrldev_list_mutex)
CPU #0
 pinctrl_unregister
 (Holding lock pinctrldev_list_mutex)
 -> pinctrl_put ->> pinctrl_free ->
 pinctrl_dt_free_maps -> pinctrl_unregister_map
 (Trying to acquire lock pinctrl_maps_mutex)

Simply to say
CPU#1 is holding lock A and trying to acquire lock B,
CPU#0 is holding lock B and trying to acquire lock A.

Deadlock 2:
CPU #3
 pinctrl_register-> pinctrl_get ->
 create_pinctrl
 (Holding lock pinctrl_maps_mutex)
 -> get_pinctrl_dev_from_devname
 (Trying to acquire lock pinctrldev_list_mutex)
CPU #2
 pinctrl_unregister
 (Holding lock pctldev->mutex)
 -> pinctrl_put ->> pinctrl_free ->
 pinctrl_dt_free_maps -> pinctrl_unregister_map
 (Trying to acquire lock pinctrl_maps_mutex)
CPU #0
 tegra_gpio_request
 (Holding lock pinctrldev_list_mutex)
 -> pinctrl_get_device_gpio_range
 (Trying to acquire lock pctldev->mutex)

Simply to say
CPU#3 is holding lock A and trying to acquire lock D,
CPU#2 is holding lock B and trying to acquire lock A,
CPU#0 is holding lock D and trying to acquire lock B.

Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Jim Lin <jilin@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: rockchip: Avoid losing interrupts when supporting both edges 2015-01-14T13:20:32+00:00 Doug Anderson dianders@chromium.org 2014-12-22T18:47:29+00:00 53b1bfc76df23230bbe32fd5879ff4927f04c53a I was seeing cases where I was losing interrupts when inserting and removing SD cards. Sometimes the card would get "stuck" in the inserted state. I believe that the problem was related to the code to handle the case where we needed both rising and falling edges. This code would disable the interrupt as the polarity was switched. If an interrupt came at the wrong time it could be lost. We'll match what the gpio-dwapb.c driver does upstream and change the interrupt polarity without disabling things. Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
I was seeing cases where I was losing interrupts when inserting and
removing SD cards.  Sometimes the card would get "stuck" in the
inserted state.

I believe that the problem was related to the code to handle the case
where we needed both rising and falling edges.  This code would
disable the interrupt as the polarity was switched.  If an interrupt
came at the wrong time it could be lost.

We'll match what the gpio-dwapb.c driver does upstream and change the
interrupt polarity without disabling things.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: st: Add irq_disable hook to st_gpio_irqchip 2015-01-07T09:44:39+00:00 Patrice CHOTARD patrice.chotard@st.com 2015-01-05T10:04:14+00:00 fce7fcc785998d91a4e2293ec6c0fa7a4677999b Currently disable_irq() doesn't work for pinctrl-st driver, due to missing irq_disable hook in the driver. disable_irq() is required only for level-triggered interrupts, which is not the case normally. Signed-off-by: Pankaj Dev <pankaj.dev@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Currently disable_irq() doesn't work for pinctrl-st driver, due to
missing irq_disable hook in the driver.
disable_irq() is required only for level-triggered interrupts, which
is not the case normally.

Signed-off-by: Pankaj Dev <pankaj.dev@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: st: avoid multiple mutex lock 2015-01-07T09:43:41+00:00 Francesco VIRLINZI francesco.virlinzi@st.com 2015-01-05T10:04:13+00:00 96d16c3088a924a44175d2923cc0eafa0d8bbecc Using the sysfs inteface to inspect the pins configuration the system can walk around a path which acquires the same mutex twice. On STiH407 platform, for example : cat /sys/kernel/debug/pinctrl/920f080.pin-controller-front0/pinconf-pins hangs the kernel and never returns. With this patch the mutex is temporary freed. Signed-off-by: Francesco Virlinzi <francesco.virlinzi@st.com> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Using the sysfs inteface to inspect the pins configuration
the system can walk around a path which acquires the same
mutex twice.

On STiH407 platform, for example :
cat /sys/kernel/debug/pinctrl/920f080.pin-controller-front0/pinconf-pins
hangs the kernel and never returns.

With this patch the mutex is temporary freed.

Signed-off-by: Francesco Virlinzi <francesco.virlinzi@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: rockchip: Fix enable/disable/mask/unmask 2014-12-30T12:17:27+00:00 Doug Anderson dianders@chromium.org 2014-11-19T22:51:33+00:00 f2dd028c2632d107c26b1daed543d9efd4f0decd The Rockchip pinctrl driver was only implementing the "mask" and "unmask" operations though the hardware actually has two distinct things: enable/disable and mask/unmask. It was implementing the "mask" operations as a hardware enable/disable and always leaving all interrupts unmasked. I believe that the old system had some downsides, specifically: - (Untested) if an interrupt went off while interrupts were "masked" it would be lost. Now it will be kept track of. - If someone wanted to change an interrupt back into a GPIO (is such a thing sensible?) by calling irq_disable() it wouldn't actually take effect. That's because Linux does some extra optimizations when there's no true "disable" function: it does a lazy mask. Let's actually implement enable/disable/mask/unmask properly. Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
The Rockchip pinctrl driver was only implementing the "mask" and
"unmask" operations though the hardware actually has two distinct
things: enable/disable and mask/unmask.  It was implementing the
"mask" operations as a hardware enable/disable and always leaving all
interrupts unmasked.

I believe that the old system had some downsides, specifically:
- (Untested) if an interrupt went off while interrupts were "masked"
  it would be lost.  Now it will be kept track of.
- If someone wanted to change an interrupt back into a GPIO (is such a
  thing sensible?) by calling irq_disable() it wouldn't actually take
  effect.  That's because Linux does some extra optimizations when
  there's no true "disable" function: it does a lazy mask.

Let's actually implement enable/disable/mask/unmask properly.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>