linux-stable.git/drivers/gpio, branch v5.18.3

gpio: sim: Use correct order for the parameters of devm_kcalloc()

2022-06-09T08:30:33+00:00

[ Upstream commit c680c6a814a2269427fad9ac417ab16756bceae9 ]

We should have 'n', then 'size', not the opposite.
This is harmless because the 2 values are just multiplied, but having
the correct order silence a (unpublished yet) smatch warning.

Fixes: cb8c474e79be ("gpio: sim: new testing module")
Signed-off-by: Christophe JAILLET 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Sasha Levin

pinctrl/rockchip: support deferring other gpio params

2022-06-09T08:30:26+00:00

[ Upstream commit 8ce5ef64546850294b021497046588a7abcebe96 ]

Add support for deferring other params like PIN_CONFIG_INPUT_ENABLE.
This will be used to add support for PIN_CONFIG_INPUT_ENABLE to the
driver.

Fixes: e7165b1dff06 ("pinctrl/rockchip: add a queue for deferred pin output settings on probe")
Fixes: 59dd178e1d7c ("gpio/rockchip: fetch deferred output settings on probe")
Signed-off-by: Caleb Connolly 
Link: https://lore.kernel.org/r/20220328005005.72492-2-kc@postmarketos.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpiolib: of: Introduce hook for missing gpio-ranges

2022-06-09T08:30:25+00:00

[ Upstream commit 3550bba25d5587a701e6edf20e20984d2ee72c78 ]

Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
the device tree nodes of GPIO controller need the gpio-ranges property to
handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
kernel is shipped with an updated device tree binary.

In order to provide backward compatibility with those older DTB, we need a
callback within of_gpiochip_add_pin_range() so the relevant platform driver
can handle this case.

Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
Signed-off-by: Stefan Wahren 
Reviewed-by: Florian Fainelli 
Tested-by: Florian Fainelli 
Acked-by: Bartosz Golaszewski 
Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: mvebu/pwm: Refuse requests with inverted polarity

2022-05-20T14:46:56+00:00

The driver doesn't take struct pwm_state::polarity into account when
configuring the hardware, so refuse requests for inverted polarity.

Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Bartosz Golaszewski

gpio: gpio-vf610: do not touch other bits when set the target bit

2022-05-20T14:46:56+00:00

For gpio controller contain register PDDR, when set one target bit,
current logic will clear all other bits, this is wrong. Use operator
'|=' to fix it.

Fixes: 659d8a62311f ("gpio: vf610: add imx7ulp support")
Reviewed-by: Peng Fan 
Signed-off-by: Haibo Chen 
Signed-off-by: Bartosz Golaszewski

gpio: pca953x: fix irq_stat not updated when irq is disabled (irq_mask not set)

2022-05-06T14:59:29+00:00

When one port's input state get inverted (eg. from low to hight) after
pca953x_irq_setup but before setting irq_mask (by some other driver such as
"gpio-keys"), the next inversion of this port (eg. from hight to low) will not
be triggered any more (because irq_stat is not updated at the first time). Issue
should be fixed after this commit.

Fixes: 89ea8bbe9c3e ("gpio: pca953x.c: add interrupt handling capability")
Signed-off-by: Puyou Lu 
Signed-off-by: Bartosz Golaszewski

gpio: visconti: Fix fwnode of GPIO IRQ

2022-05-05T12:39:02+00:00

The fwnode of GPIO IRQ must be set to its own fwnode, not the fwnode of the
parent IRQ. Therefore, this sets own fwnode instead of the parent IRQ fwnode to
GPIO IRQ's.

Fixes: 2ad74f40dacc ("gpio: visconti: Add Toshiba Visconti GPIO support")
Signed-off-by: Nobuhiro Iwamatsu 
Reviewed-by: Linus Walleij 
Signed-off-by: Bartosz Golaszewski

gpio: mvebu: drop pwm base assignment

2022-05-02T09:27:57+00:00

pwmchip_add() unconditionally assigns the base ID dynamically. Commit
f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
dropped all base assignment from drivers under drivers/pwm/. It missed
this driver. Fix that.

Fixes: f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
Signed-off-by: Baruch Siach 
Reviewed-by: Uwe Kleine-König 
Acked-by: Linus Walleij 
Signed-off-by: Bartosz Golaszewski

gpiolib: of: fix bounds check for 'gpio-reserved-ranges'

2022-05-02T09:27:57+00:00

Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size"
because it clears "size" bits starting from the "start" bit in the according
bitmap. So it has to use "greater" instead of "greater or equal" when performs
bounds check to make sure that GPIOs are in the available range.
Previous implementation skipped ranges that include the last GPIO in
the range.

I wrote the mail to the maintainers
(https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u)
of the questioned DTSes (because I couldn't understand how the maintainers
interpreted this property), but I haven't received a response.
Since the questioned DTSes use "gpio-reserved-ranges = <0 4>"
(i.e., the beginning of the range), this patch doesn't affect these DTSes at all.
TBH this patch doesn't break any existing DTSes because none of them
reserve gpios at the end of range.

Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property")
Signed-off-by: Andrei Lalaev 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski

gpio: Request interrupts after IRQ is initialized

2022-04-22T20:59:19+00:00

Commit 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members
before initialization") attempted to fix a race condition that lead to a
NULL pointer, but in the process caused a regression for _AEI/_EVT
declared GPIOs.

This manifests in messages showing deferred probing while trying to
allocate IRQs like so:

  amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517
  amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517
  amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517
  [ .. more of the same .. ]

The code for walking _AEI doesn't handle deferred probing and so this
leads to non-functional GPIO interrupts.

Fix this issue by moving the call to `acpi_gpiochip_request_interrupts`
to occur after gc->irc.initialized is set.

Fixes: 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization")
Link: https://lore.kernel.org/linux-gpio/BL1PR12MB51577A77F000A008AA694675E2EF9@BL1PR12MB5157.namprd12.prod.outlook.com/
Link: https://bugzilla.suse.com/show_bug.cgi?id=1198697
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215850
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1979
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1976
Reported-by: Mario Limonciello 
Signed-off-by: Mario Limonciello 
Reviewed-by: Shreeya Patel 
Tested-By: Samuel Čavoj 
Tested-By: lukeluk498@gmail.com Link:
Reviewed-by: Andy Shevchenko 
Acked-by: Linus Walleij 
Reviewed-and-tested-by: Takashi Iwai 
Cc: Shreeya Patel 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds