linux-stable.git/drivers/pinctrl, branch v3.18.136

pinctrl: msm: fix gpio-hog related boot issues

2019-02-20T09:09:12+00:00

commit a86caa9ba5d70696ceb35d1d39caa20d8b641387 upstream.

Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
Setting up any gpio-hog in the device-tree for his device would
"kill the bootup completely":

| [    0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
| [    0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe
| [    1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517
| [    1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register
| [    1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip
| [    1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
| [    1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri

This was also verified on a RT-AC58U (IPQ4018) which would
no longer boot, if a gpio-hog was specified. (Tried forcing
the USB LED PIN (GPIO0) to high.).

The problem is that Pinctrl+GPIO registration is currently
peformed in the following order in pinctrl-msm.c:
	1. pinctrl_register()
	2. gpiochip_add()
	3. gpiochip_add_pin_range()

The actual error code -517 == -EPROBE_DEFER is coming from
pinctrl_get_device_gpio_range(), which is called through:
        gpiochip_add
            of_gpiochip_add
                of_gpiochip_scan_gpios
                    gpiod_hog
                        gpiochip_request_own_desc
                            __gpiod_request
                                chip->request
                                    gpiochip_generic_request
                                       pinctrl_gpio_request
                                          pinctrl_get_device_gpio_range

pinctrl_get_device_gpio_range() is unable to find any valid
pin ranges, since nothing has been added to the pinctrldev_list yet.
so the range can't be found, and the operation fails with -EPROBE_DEFER.

This patch fixes the issue by adding the "gpio-ranges" property to
the pinctrl device node of all upstream Qcom SoC. The pin ranges are
then added by the gpio core.

In order to remain compatible with older, existing DTs (and ACPI)
a check for the "gpio-ranges" property has been added to
msm_gpio_init(). This prevents the driver of adding the same entry
to the pinctrldev_list twice.

Reported-by: Sven Eckelmann 
Tested-by: Sven Eckelmann  [ipq4019]
Reviewed-by: Bjorn Andersson 
Signed-off-by: Christian Lamparter 
Signed-off-by: Linus Walleij 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

pinctrl: imx25: ensure that a pin with id i is at position i in the info array

2018-11-10T15:39:18+00:00

[ Upstream commit 9911a2d5e9d14e39692b751929a92cb5a1d9d0e0 ]

The code in pinctrl-imx.c only works correctly if in the
imx_pinctrl_soc_info passed to imx_pinctrl_probe we have:

	info->pins[i].number = i
	conf_reg(info->pins[i]) = 4 * i

(which conf_reg(pin) being the offset of the pin's configuration
register).

When the imx25 specific part was introduced in b4a87c9b966f ("pinctrl:
pinctrl-imx: add imx25 pinctrl driver") we had:

	info->pins[i].number = i + 1
	conf_reg(info->pins[i]) = 4 * i

. Commit 34027ca2bbc6 ("pinctrl: imx25: fix numbering for pins") tried
to fix that but made the situation:

	info->pins[i-1].number = i
	conf_reg(info->pins[i-1]) = 4 * i

which is hardly better but fixed the error seen back then.

So insert another reserved entry in the array to finally yield:

	info->pins[i].number = i
	conf_reg(info->pins[i]) = 4 * i

Fixes: 34027ca2bbc6 ("pinctrl: imx25: fix numbering for pins")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: at91: fix null pointer dereference

2018-11-10T15:39:14+00:00

[ Upstream commit 1ab36387ea4face01aac3560b396b1e2ce07c4ff ]

Not all gpio banks are necessarily enabled, in the current code this can
lead to null pointer dereferences.

[   51.130000] Unable to handle kernel NULL pointer dereference at virtual address 00000058
[   51.130000] pgd = dee04000
[   51.130000] [00000058] *pgd=3f66d831, *pte=00000000, *ppte=00000000
[   51.140000] Internal error: Oops: 17 [#1] ARM
[   51.140000] Modules linked in:
[   51.140000] CPU: 0 PID: 1664 Comm: cat Not tainted 4.1.1+ #6
[   51.140000] Hardware name: Atmel SAMA5
[   51.140000] task: df6dd880 ti: dec60000 task.ti: dec60000
[   51.140000] PC is at at91_pinconf_get+0xb4/0x200
[   51.140000] LR is at at91_pinconf_get+0xb4/0x200
[   51.140000] pc : []    lr : []    psr: 600f0013
sp : dec61e48  ip : 600f0013  fp : df522538
[   51.140000] r10: df52250c  r9 : 00000058  r8 : 00000068
[   51.140000] r7 : 00000000  r6 : df53c910  r5 : 00000000  r4 : dec61e7c
[   51.140000] r3 : 00000000  r2 : c06746d4  r1 : 00000000  r0 : 00000003
[   51.140000] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   51.140000] Control: 10c53c7d  Table: 3ee04059  DAC: 00000015
[   51.140000] Process cat (pid: 1664, stack limit = 0xdec60208)
[   51.140000] Stack: (0xdec61e48 to 0xdec62000)
[   51.140000] 1e40:                   00000358 00000000 df522500 ded15f80 c05a9d08 ded15f80
[   51.140000] 1e60: 0000048c 00000061 df522500 ded15f80 c05a9d08 c01e7304 ded15f80 00000000
[   51.140000] 1e80: c01e6008 00000060 0000048c c01e6034 c01e5f6c ded15f80 dec61ec0 00000000
[   51.140000] 1ea0: 00020000 ded6f280 dec61f80 00000001 00000001 c00ae0b8 b6e80000 ded15fb0
[   51.140000] 1ec0: 00000000 00000000 df4bc974 00000055 00000800 ded6f280 b6e80000 ded6f280
[   51.140000] 1ee0: ded6f280 00020000 b6e80000 00000000 00020000 c0090dec c0671e1c dec61fb0
[   51.140000] 1f00: b6f8b510 00000001 00004201 c000924c 00000000 00000003 00000003 00000000
[   51.140000] 1f20: df4bc940 00022000 00000022 c066e188 b6e7f000 c00836f4 000b6e7f ded6f280
[   51.140000] 1f40: ded6f280 b6e80000 dec61f80 ded6f280 00020000 c0091508 00000000 00000003
[   51.140000] 1f60: 00022000 00000000 00000000 ded6f280 ded6f280 00020000 b6e80000 c0091d9c
[   51.140000] 1f80: 00000000 00000000 ffffffff 00020000 00020000 b6e80000 00000003 c000f124
[   51.140000] 1fa0: dec60000 c000efa0 00020000 00020000 00000003 b6e80000 00020000 000271c4
[   51.140000] 1fc0: 00020000 00020000 b6e80000 00000003 7fffe000 00000000 00000000 00020000
[   51.140000] 1fe0: 00000000 bef50b64 00013835 b6f29c76 400f0030 00000003 00000000 00000000
[   51.140000] [] (at91_pinconf_get) from [] (at91_pinconf_dbg_show+0x18/0x2c0)
[   51.140000] [] (at91_pinconf_dbg_show) from [] (pinconf_pins_show+0xc8/0xf8)
[   51.140000] [] (pinconf_pins_show) from [] (seq_read+0x1a0/0x464)
[   51.140000] [] (seq_read) from [] (__vfs_read+0x20/0xd0)
[   51.140000] [] (__vfs_read) from [] (vfs_read+0x7c/0x108)
[   51.140000] [] (vfs_read) from [] (SyS_read+0x40/0x94)
[   51.140000] [] (SyS_read) from [] (ret_fast_syscall+0x0/0x3c)
[   51.140000] Code: eb010ec2 e30a0d08 e34c005a eb0ae5a7 (e5993000)
[   51.150000] ---[ end trace fb3c370da3ea4794 ]---

Fixes: a0b957f306fa ("pinctrl: at91: allow to have disabled gpio bank")
Cc: stable@vger.kernel.org # 3.18
Signed-off-by: David Dueck 
Acked-by: Ludovic Desroches 
Acked-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
Cc: Boris Brezillon 
Cc: Jean-Christophe PLAGNIOL-VILLARD 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()

2018-09-05T07:16:23+00:00

commit 19da44cd33a3a6ff7c97fff0189999ff15b241e4 upstream.

The info->groups[] array is allocated in imx1_pinctrl_parse_dt().  It
has info->ngroups elements.  Thus the > here should be >= to prevent
reading one element beyond the end of the array.

Cc: stable@vger.kernel.org
Fixes: 30612cd90005 ("pinctrl: imx1 core driver")
Signed-off-by: Dan Carpenter 
Reviewed-by: Uwe Kleine-König 
Acked-by: Dong Aisheng 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: Really force states during suspend/resume

2018-03-24T09:57:35+00:00

[ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ]

In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and resumes
in a way that the pin states are not preserved by the hardware, when we
resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
-> pinctrl_select_state() and the first thing we do is check that the
pins state is the same as before, and do nothing.

In order to fix this, decouple the actual state change from
pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
the p->state == state check in pinctrl_select_state() not to change the
caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
are updated to bypass the state check by calling pinctrl_commit_state().

[Linus Walleij]
The forced pin control states are currently only used in some pin
controller drivers that grab their own reference to their own pins.
This is equal to the pin control hogs: pins taken by pin control
devices since there are no corresponding device in the Linux device
hierarchy, such as memory controller lines or unused GPIO lines,
or GPIO lines that are used orthogonally from the GPIO subsystem
but pincontrol-wise managed as hogs (non-strict mode, allowing
simultaneous use by GPIO and pin control). For this case forcing
the state from the drivers' suspend()/resume() callbacks makes
sense and should semantically match the name of the function.

Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
Signed-off-by: Florian Fainelli 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

pinctrl: adi2: Fix Kconfig build problem

2017-12-20T09:01:33+00:00

[ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ]

The build robot is complaining on Blackfin:

drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
   pointer to incomplete type 'struct gpio_port_t'
      writew(readw(®s->port_fer) & ~BIT(offset),
                        ^~
drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
pointer to incomplete type 'struct bfin_pint_regs'
      if (readl(®s->invert_set) & pintbit)
                     ^~
It seems the driver need to include  and 
to compile.

The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.

Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local  header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.

Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.

This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.

Cc: Steven Miao 
Cc: Huanhuan Feng 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

pinctrl: samsung: Remove bogus irq_[un]mask from resource management

2017-08-16T20:35:32+00:00

commit 3fa53ec2ed885b0aec3f0472e3b4a8a6f1cd748c upstream.

The irq chip callbacks irq_request/release_resources() have absolutely no
business with masking and unmasking the irq.

The core code unmasks the interrupt after complete setup and masks it
before invoking irq_release_resources().

The unmask is actually harmful as it happens before the interrupt is
completely initialized in __setup_irq().

Remove it.

Fixes: f6a8249f9e55 ("pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs")
Signed-off-by: Thomas Gleixner 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: Linus Walleij 
Cc: Kukjin Kim 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Acked-by: Tomasz Figa 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver

2017-08-16T20:35:32+00:00

commit d81ece747d8727bb8b1cfc9a20dbe62f09a4e35a upstream.

The PH16 pin has a function with mux id 0x5, which is the DET pin of the
"sim" (smart card reader) IP block.

This function is missing in old versions of A10/A20 SoCs' datasheets and
user manuals, so it's also missing in the old drivers. The newest A10
Datasheet V1.70 and A20 Datasheet V1.41 contain this pin function, and
it's discovered during implementing R40 pinctrl driver.

Add it to the driver. As we now merged A20 pinctrl driver to the A10
one, we need to only fix the A10 driver now.

Fixes: f2821b1ca3a2 ("pinctrl: sunxi: Move Allwinner A10 pinctrl
driver to a driver of its own")

Signed-off-by: Icenowy Zheng 
Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: sh-pfc: Update info pointer after SoC-specific init

2017-07-15T08:14:40+00:00

commit 3091ae775fae17084013021d01513bc1ad274e6a upstream.

Update the sh_pfc_soc_info pointer after calling the SoC-specific
initialization function, as it may have been updated to e.g. handle
different SoC revisions.  This makes sure the correct subdriver name is
printed later.

Fixes: 0c151062f32c9db8 ("sh-pfc: Add support for SoC-specific initialization")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman

pinctrl: mxs: atomically switch mux and drive strength config

2017-07-15T08:14:40+00:00

commit da6c2addf66d7ff7d0b090d6267d4292f951e4e6 upstream.

To set the mux mode of a pin two bits must be set. Up to now this is
implemented using the following idiom:

	writel(mask, reg + CLR);
	writel(value, reg + SET);

. This however results in the mux mode being 0 between the two writes.

On my machine there is an IC's reset pin connected to LCD_D20. The
bootloader configures this pin as GPIO output-high (i.e. not holding the
IC in reset). When Linux reconfigures the pin to GPIO the short time
LCD_D20 is muxed as LCD_D20 instead of GPIO_1_20 is enough to confuse
the connected IC.

The same problem is present for the pin's drive strength setting which is
reset to low drive strength before using the right value.

So instead of relying on the hardware to modify the register setting
using two writes implement the bit toggling using read-modify-write.

Fixes: 17723111e64f ("pinctrl: add pinctrl-mxs support")
Signed-off-by: Uwe Kleine-König 
Acked-by: Shawn Guo 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman