linux.git/drivers/pinctrl/sunxi, branch v5.19

pinctrl: sunxi: sunxi_pconf_set: use correct offset

2022-06-27T09:27:10+00:00

Some Allwinner SoCs have 2 pinctrls (PIO and R_PIO).
Previous implementation used absolute pin numbering and it was incorrect
for R_PIO pinctrl.
It's necessary to take into account the base pin number.

Fixes: 90be64e27621 ("pinctrl: sunxi: implement pin_config_set")
Signed-off-by: Andrei Lalaev 
Reviewed-by: Samuel Holland 
Link: https://lore.kernel.org/r/20220525190423.410609-1-andrey.lalaev@gmail.com
Signed-off-by: Linus Walleij

pinctrl: sunxi: a83t: Fix NAND function name for some pins

2022-06-15T13:19:57+00:00

The other NAND pins on Port C use the "nand0" function name.
"nand0" also matches all of the other Allwinner SoCs.

Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller support")
Signed-off-by: Samuel Holland 
Acked-by: Jernej Skrabec 
Link: https://lore.kernel.org/r/20220526024956.49500-1-samuel@sholland.org
Signed-off-by: Linus Walleij

pinctrl: sunxi: f1c100s: Fix signal name comment for PA2 SPI pin

2022-05-13T23:07:08+00:00

The manual describes function 0x6 of pin PA2 as "SPI1_CLK", so change
the comment to reflect that.

Signed-off-by: Andre Przywara 
Acked-by: Jernej Skrabec 
Link: https://lore.kernel.org/r/20220504170736.2669595-1-andre.przywara@arm.com
Signed-off-by: Linus Walleij

pinctrl: sunxi: fix f1c100s uart2 function

2022-05-13T23:06:07+00:00

Change suniv f1c100s pinctrl,PD14 multiplexing function lvds1 to uart2

When the pin PD13 and PD14 is setting up to uart2 function in dts,
there's an error occurred:
1c20800.pinctrl: unsupported function uart2 on pin PD14

Because 'uart2' is not any one multiplexing option of PD14,
and pinctrl don't know how to configure it.

So change the pin PD14 lvds1 function to uart2.

Signed-off-by: IotaHydrae 
Reviewed-by: Andre Przywara 
Link: https://lore.kernel.org/r/tencent_70C1308DDA794C81CAEF389049055BACEC09@qq.com
Signed-off-by: Linus Walleij

Merge tag 'pinctrl-v5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2022-03-28T18:52:53+00:00

Pull pin control updates from Linus Walleij:
 "No core changes this time. Just new driver code and improvements!

  New drivers:

   - New driver for the Broadcom BCM4908 SoC.

   - New subdriver for Tesla FSD (Full Self Driving) SoC, a derivative
     of the Samsung Exynos pin control driver.

   - New driver for the Amlogic Meson S4 SoC.

   - New driver for the Sunplus SP7021 SoC.

   - New driver for the Microsemi Ocelot family ServalT SoC.

   - New subdriver for Intel Alder Lake-M SoC.

   - New subdriver for Intel Ice Lake-N SoC, including PCH support.

   - New subdriver for Renesas R8A779F0 SoC.

   - New subdriver for Mediatek MT8186 SoC.

   - New subdriver for NXP Freescale i.MX93 SoC.

   - New driver for Nuvoton WPCM450 SoC.

   - New driver for Qualcomm SC8280XP SoC.

  Improvements:

   - Wakeup support on Samsung Exynos850 and ExynosAutov9.

   - Serious and voluminous maintenance cleanup and refactoring in the
     Renesas drivers. Mainly sharing similar data between the different
     SoC subdrivers.

   - Qualcomm SM8450 EGPIO support.

   - Drive strength support on the Mediatek MT8195.

   - Add some missing groups and functions to the Ralink RT2880"

* tag 'pinctrl-v5.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (188 commits)
  pinctrl: mediatek: common-v1: fix semicolon.cocci warnings
  pinctrl: nuvoton: wpcm450: Fix build error without OF
  pinctrl: qcom-pmic-gpio: Add support for pm8450
  dt-bindings: pinctrl: aspeed: Update gfx node in example
  dt-bindings: pinctrl: rt2880: add missing pin groups and functions
  pinctrl: ingenic: Fix regmap on X series SoCs
  pinctrl: nuvoton: Fix return value check in wpcm450_gpio_register()
  pinctrl: nuvoton: wpcm450: off by one in wpcm450_gpio_register()
  pinctrl: nuvoton: wpcm450: select GENERIC_PINCTRL_GROUPS
  pinctrl: nuvoton: Fix sparse warning
  pinctrl: mediatek: mt8186: Account for probe refactoring
  pinctrl: mediatek: common-v1: Commonize spec_ies_smt_set callback
  pinctrl: mediatek: common-v1: Commonize spec_pupd callback
  pinctrl: mediatek: common-v1: Use common probe function
  pinctrl: mediatek: common-v1: Add common probe function
  pinctrl: mediatek: paris: Unify probe function by using OF match data
  pinctrl/rockchip: Add missing of_node_put() in rockchip_pinctrl_probe
  pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe
  pinctrl: berlin: fix error return code of berlin_pinctrl_build_state()
  pinctrl: qcom: Introduce sc8280xp TLMM driver
  ...

pinctrl: sunxi: Use unique lockdep classes for IRQs

2022-02-28T22:53:19+00:00

This driver, like several others, uses a chained IRQ for each GPIO bank,
and forwards .irq_set_wake to the GPIO bank's upstream IRQ. As a result,
a call to irq_set_irq_wake() needs to lock both the upstream and
downstream irq_desc's. Lockdep considers this to be a possible deadlock
when the irq_desc's share lockdep classes, which they do by default:

 ============================================
 WARNING: possible recursive locking detected
 5.17.0-rc3-00394-gc849047c2473 #1 Not tainted
 --------------------------------------------
 init/307 is trying to acquire lock:
 c2dfe27c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

 but task is already holding lock:
 c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&irq_desc_lock_class);
   lock(&irq_desc_lock_class);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 4 locks held by init/307:
  #0: c1f29f18 (system_transition_mutex){+.+.}-{3:3}, at: __do_sys_reboot+0x90/0x23c
  #1: c20f7760 (&dev->mutex){....}-{3:3}, at: device_shutdown+0xf4/0x224
  #2: c2e804d8 (&dev->mutex){....}-{3:3}, at: device_shutdown+0x104/0x224
  #3: c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

 stack backtrace:
 CPU: 0 PID: 307 Comm: init Not tainted 5.17.0-rc3-00394-gc849047c2473 #1
 Hardware name: Allwinner sun8i Family
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from dump_stack_lvl+0x68/0x90
  dump_stack_lvl from __lock_acquire+0x1680/0x31a0
  __lock_acquire from lock_acquire+0x148/0x3dc
  lock_acquire from _raw_spin_lock_irqsave+0x50/0x6c
  _raw_spin_lock_irqsave from __irq_get_desc_lock+0x58/0xa0
  __irq_get_desc_lock from irq_set_irq_wake+0x2c/0x19c
  irq_set_irq_wake from irq_set_irq_wake+0x13c/0x19c
    [tail call from sunxi_pinctrl_irq_set_wake]
  irq_set_irq_wake from gpio_keys_suspend+0x80/0x1a4
  gpio_keys_suspend from gpio_keys_shutdown+0x10/0x2c
  gpio_keys_shutdown from device_shutdown+0x180/0x224
  device_shutdown from __do_sys_reboot+0x134/0x23c
  __do_sys_reboot from ret_fast_syscall+0x0/0x1c

However, this can never deadlock because the upstream and downstream
IRQs are never the same (nor do they even involve the same irqchip).

Silence this erroneous lockdep splat by applying what appears to be the
usual fix of moving the GPIO IRQs to separate lockdep classes.

Fixes: a59c99d9eaf9 ("pinctrl: sunxi: Forward calls to irq_set_irq_wake")
Reported-by: Guenter Roeck 
Signed-off-by: Samuel Holland 
Reviewed-by: Jernej Skrabec 
Tested-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20220216040037.22730-1-samuel@sholland.org
Signed-off-by: Linus Walleij

pinctrl-sunxi: sunxi_pinctrl_gpio_direction_in/output: use correct offset

2022-02-28T22:52:20+00:00

The commit that sets the direction directly without calling
pinctrl_gpio_direction(), forgot to add chip->base to the offset when
calling sunxi_pmx_gpio_set_direction().

This caused failures for various Allwinner boards which have two
GPIO blocks.

Signed-off-by: Hans Verkuil 
Reported-by: 5kft <5kft@5kft.org>
Suggested-by: 5kft <5kft@5kft.org>
Reported-by: Corentin Labbe 
Fixes: 8df89a7cbc63 (pinctrl-sunxi: don't call pinctrl_gpio_direction())
Tested-by: Corentin Labbe 
Tested-by: Jernej Skrabec 
Acked-by: Jernej Skrabec 
Link: https://lore.kernel.org/r/0f536cd8-01db-5d16-2cec-ec6d19409a49@xs4all.nl
Signed-off-by: Guenter Roeck 
[Picked from linux-next to pinctrl fixes]
Signed-off-by: Linus Walleij

pinctrl: sunxi: Use unique lockdep classes for IRQs

2022-02-19T01:12:37+00:00

This driver, like several others, uses a chained IRQ for each GPIO bank,
and forwards .irq_set_wake to the GPIO bank's upstream IRQ. As a result,
a call to irq_set_irq_wake() needs to lock both the upstream and
downstream irq_desc's. Lockdep considers this to be a possible deadlock
when the irq_desc's share lockdep classes, which they do by default:

 ============================================
 WARNING: possible recursive locking detected
 5.17.0-rc3-00394-gc849047c2473 #1 Not tainted
 --------------------------------------------
 init/307 is trying to acquire lock:
 c2dfe27c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

 but task is already holding lock:
 c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&irq_desc_lock_class);
   lock(&irq_desc_lock_class);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 4 locks held by init/307:
  #0: c1f29f18 (system_transition_mutex){+.+.}-{3:3}, at: __do_sys_reboot+0x90/0x23c
  #1: c20f7760 (&dev->mutex){....}-{3:3}, at: device_shutdown+0xf4/0x224
  #2: c2e804d8 (&dev->mutex){....}-{3:3}, at: device_shutdown+0x104/0x224
  #3: c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

 stack backtrace:
 CPU: 0 PID: 307 Comm: init Not tainted 5.17.0-rc3-00394-gc849047c2473 #1
 Hardware name: Allwinner sun8i Family
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from dump_stack_lvl+0x68/0x90
  dump_stack_lvl from __lock_acquire+0x1680/0x31a0
  __lock_acquire from lock_acquire+0x148/0x3dc
  lock_acquire from _raw_spin_lock_irqsave+0x50/0x6c
  _raw_spin_lock_irqsave from __irq_get_desc_lock+0x58/0xa0
  __irq_get_desc_lock from irq_set_irq_wake+0x2c/0x19c
  irq_set_irq_wake from irq_set_irq_wake+0x13c/0x19c
    [tail call from sunxi_pinctrl_irq_set_wake]
  irq_set_irq_wake from gpio_keys_suspend+0x80/0x1a4
  gpio_keys_suspend from gpio_keys_shutdown+0x10/0x2c
  gpio_keys_shutdown from device_shutdown+0x180/0x224
  device_shutdown from __do_sys_reboot+0x134/0x23c
  __do_sys_reboot from ret_fast_syscall+0x0/0x1c

However, this can never deadlock because the upstream and downstream
IRQs are never the same (nor do they even involve the same irqchip).

Silence this erroneous lockdep splat by applying what appears to be the
usual fix of moving the GPIO IRQs to separate lockdep classes.

Fixes: a59c99d9eaf9 ("pinctrl: sunxi: Forward calls to irq_set_irq_wake")
Reported-by: Guenter Roeck 
Signed-off-by: Samuel Holland 
Reviewed-by: Jernej Skrabec 
Tested-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20220216040037.22730-1-samuel@sholland.org
Signed-off-by: Linus Walleij

pinctrl: sunxi: do not print error message for EPROBE_DEFER

2022-02-19T01:09:07+00:00

Avoid printing an error message if getting a regulator fails with
EPROBE_DEFER.  This can happen if, for example, a regulator supplying
one of the main banks is controlled by a PL pin.

Signed-off-by: Mans Rullgard 
Acked-by: Chen-Yu Tsai 
Link: https://lore.kernel.org/r/20220217131737.10931-1-mans@mansr.com
Signed-off-by: Linus Walleij

pinctrl: sunxi: Fix H616 I2S3 pin data

2022-01-24T00:12:46+00:00

Two bugs have sneaked in the H616 pinctrl data:
- PH9 uses the mux value of 0x3 twice (one should be 0x5 instead)
- PH8 and PH9 use the "i2s3" function name twice in each pin

For the double pin name we use the same trick we pulled for i2s0: append
the pin function to the group name to designate the special function.

Fixes: 25adc29407fb ("pinctrl: sunxi: Add support for the Allwinner H616 pin controller")
Reported-by: SASANO Takayoshi 
Signed-off-by: Andre Przywara 
Reviewed-by: Jernej Skrabec 
Reviewed-by: Samuel Holland 
Link: https://lore.kernel.org/r/20220105172952.23347-1-andre.przywara@arm.com
Signed-off-by: Linus Walleij