[PATCH 0/3] gpio: tps65219: Fix TPS6521x GPIO handling

[PATCH 0/3] gpio: tps65219: Fix TPS6521x GPIO handling

[Karl Mehltretter]

I found patch 1 while looking through the tree for code that mixes up
bit numbers and bit masks. Patches 2 and 3 turned up while checking the
nearby TPS65214 code.

Patch 1 fixes TPS65219 input reads. Patches 2 and 3 fix TPS65214
direction handling.

I tested the series under x86_64 QEMU 10.2.1 with a temporary KUnit
suite and a RAM-backed regmap. Both tests failed on the base commit.
The TPS65219 input-high test returned low, and the TPS65214
direction-output test left GPIO_CONFIG clear. Both tests pass with this
series. A W=1 build of drivers/gpio/gpio-tps65219.o also passes.

The KUnit suite is not included. It tests the driver logic, not real
PMIC hardware. I have not tested this on real hardware. Testing on
affected hardware is welcome.

Karl Mehltretter (3):
  gpio: tps65219: Fix GPIO input value reads
  gpio: tps65219: Use the variant-specific direction callback
  gpio: tps65219: Fix TPS65214 GPIO direction programming

 drivers/gpio/gpio-tps65219.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)


base-commit: 40288c9206c17eb66a603262e06a58d300d0f279
-- 
2.53.0

[PATCH 1/3] gpio: tps65219: Fix GPIO input value reads

[Karl Mehltretter]

TPS65219_MFP_GPIO_STATUS_MASK is already BIT(4). Passing it to BIT()
again tests bit 16, which cannot be set in the 8-bit MFP_CTRL register,
so GPIO0 is always reported low when configured as an input.

Test the register value with the mask directly.

Fixes: 57e30e00bd5b ("gpio: tps65219: add GPIO support for TPS65219 PMIC")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Testing:

  - A temporary KUnit test instantiated the driver with a RAM-backed
    regmap under x86_64 QEMU 10.2.1.  The TPS65219 input-high test
    failed on the base commit and passes with this series.
  - This has not been tested on real hardware; testing on affected
    hardware is welcome.

 drivers/gpio/gpio-tps65219.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-tps65219.c b/drivers/gpio/gpio-tps65219.c
index 457fd8a589e89..b25c6f7277680 100644
--- a/drivers/gpio/gpio-tps65219.c
+++ b/drivers/gpio/gpio-tps65219.c
@@ -79,7 +79,7 @@ static int tps65219_gpio_get(struct gpio_chip *gc, unsigned int offset)
 	if (ret)
 		return ret;
 
-	ret = !!(val & BIT(TPS65219_MFP_GPIO_STATUS_MASK));
+	ret = !!(val & TPS65219_MFP_GPIO_STATUS_MASK);
 	dev_warn(dev, "GPIO%d = %d, MULTI_DEVICE_ENABLE, not a standard GPIO\n", offset, ret);
 
 	/*
-- 
2.53.0

[PATCH 2/3] gpio: tps65219: Use the variant-specific direction callback

[Karl Mehltretter]

The TPS65214 template installs its own get_direction callback because
its direction bit is in GENERAL_CONFIG. The shared get and direction
callbacks nevertheless call tps65219_gpio_get_direction() directly and
interpret the unrelated TPS65219 MFP bit.

On TPS65214 this can reject reads from an input and skip the change from
input to output. Call the callback selected by the gpio_chip template
instead.

Fixes: 1b6ab07c0c80 ("gpio: tps65219: Add support for TI TPS65214 PMIC")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Testing:

  - This callback path was exercised together with patch 3 by a
    temporary KUnit test using a RAM-backed regmap under x86_64 QEMU
    10.2.1.  The TPS65214 direction-output test failed on the base
    commit and passes with this series.
  - This has not been tested on real hardware; testing on affected
    hardware is welcome.

 drivers/gpio/gpio-tps65219.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-tps65219.c b/drivers/gpio/gpio-tps65219.c
index b25c6f7277680..479a80ef76543 100644
--- a/drivers/gpio/gpio-tps65219.c
+++ b/drivers/gpio/gpio-tps65219.c
@@ -87,7 +87,7 @@ static int tps65219_gpio_get(struct gpio_chip *gc, unsigned int offset)
 	 * status bit.
 	 */
 
-	if (tps65219_gpio_get_direction(gc, offset) == GPIO_LINE_DIRECTION_OUT)
+	if (gc->get_direction(gc, offset) == GPIO_LINE_DIRECTION_OUT)
 		return -ENOTSUPP;
 
 	return ret;
@@ -176,7 +176,7 @@ static int tps65219_gpio_direction_input(struct gpio_chip *gc, unsigned int offs
 		return -ENOTSUPP;
 	}
 
-	if (tps65219_gpio_get_direction(gc, offset) == GPIO_LINE_DIRECTION_IN)
+	if (gc->get_direction(gc, offset) == GPIO_LINE_DIRECTION_IN)
 		return 0;
 
 	return gpio->change_dir(gc, offset, GPIO_LINE_DIRECTION_IN);
@@ -190,7 +190,7 @@ static int tps65219_gpio_direction_output(struct gpio_chip *gc, unsigned int off
 	if (offset != TPS6521X_GPIO0_IDX)
 		return 0;
 
-	if (tps65219_gpio_get_direction(gc, offset) == GPIO_LINE_DIRECTION_OUT)
+	if (gc->get_direction(gc, offset) == GPIO_LINE_DIRECTION_OUT)
 		return 0;
 
 	return gpio->change_dir(gc, offset, GPIO_LINE_DIRECTION_OUT);
-- 
2.53.0

[PATCH 3/3] gpio: tps65219: Fix TPS65214 GPIO direction programming

[Karl Mehltretter]

GPIO_LINE_DIRECTION_OUT and GPIO_LINE_DIRECTION_IN have the values 0
and 1, respectively, while the TPS65214 GPIO_CONFIG field is BIT(1).
regmap_update_bits() masks the supplied value, so passing either
direction value clears the field and selects input mode.

Translate the GPIO direction to the register encoding used by
tps65214_gpio_get_direction(), setting GPIO_CONFIG for output and
clearing it for input.

Fixes: 1b6ab07c0c80 ("gpio: tps65219: Add support for TI TPS65214 PMIC")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Testing:

  - This register programming was exercised together with patch 2 by a
    temporary KUnit test using a RAM-backed regmap under x86_64 QEMU
    10.2.1.  The TPS65214 direction-output test failed on the base
    commit and passes with this series.
  - This has not been tested on real hardware; testing on affected
    hardware is welcome.

 drivers/gpio/gpio-tps65219.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-tps65219.c b/drivers/gpio/gpio-tps65219.c
index 479a80ef76543..6958466455d04 100644
--- a/drivers/gpio/gpio-tps65219.c
+++ b/drivers/gpio/gpio-tps65219.c
@@ -158,8 +158,10 @@ static int tps65214_gpio_change_direction(struct gpio_chip *gc, unsigned int off
 	if (ret)
 		dev_err(dev, "GPIO%d configured as VSEL, not GPIO\n", offset);
 
+	val = direction == GPIO_LINE_DIRECTION_OUT ?
+		TPS65214_GPIO0_DIR_MASK : 0;
 	ret = regmap_update_bits(gpio->tps->regmap, TPS65219_REG_GENERAL_CONFIG,
-				 TPS65214_GPIO0_DIR_MASK, direction);
+				 TPS65214_GPIO0_DIR_MASK, val);
 	if (ret)
 		dev_err(dev, "Fail to change direction to %u for GPIO%d.\n", direction, offset);
 
-- 
2.53.0

Re: [PATCH 1/3] gpio: tps65219: Fix GPIO input value reads

[Jon Cormier]

On Sat, Sep 19, 2026 at 1:11 PM Karl Mehltretter <kmehltretter@gmail.com> wrote:
>
> TPS65219_MFP_GPIO_STATUS_MASK is already BIT(4). Passing it to BIT()
> again tests bit 16, which cannot be set in the 8-bit MFP_CTRL register,
> so GPIO0 is always reported low when configured as an input.
>
> Test the register value with the mask directly.
>
> Fixes: 57e30e00bd5b ("gpio: tps65219: add GPIO support for TPS65219 PMIC")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
> Testing:
>
>   - A temporary KUnit test instantiated the driver with a RAM-backed
>     regmap under x86_64 QEMU 10.2.1.  The TPS65219 input-high test
>     failed on the base commit and passes with this series.
>   - This has not been tested on real hardware; testing on affected
>     hardware is welcome.
>
>  drivers/gpio/gpio-tps65219.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-tps65219.c b/drivers/gpio/gpio-tps65219.c
> index 457fd8a589e89..b25c6f7277680 100644
> --- a/drivers/gpio/gpio-tps65219.c
> +++ b/drivers/gpio/gpio-tps65219.c
> @@ -79,7 +79,7 @@ static int tps65219_gpio_get(struct gpio_chip *gc, unsigned int offset)
>         if (ret)
>                 return ret;
>
> -       ret = !!(val & BIT(TPS65219_MFP_GPIO_STATUS_MASK));
> +       ret = !!(val & TPS65219_MFP_GPIO_STATUS_MASK);
>         dev_warn(dev, "GPIO%d = %d, MULTI_DEVICE_ENABLE, not a standard GPIO\n", offset, ret);
>
>         /*
> --
> 2.53.0

Makes sense to me, our hardware has this pin connected as an input so
I must not have tested this case.
Reviewed-by: Jonathan Cormier <jcormier@criticallink.com>


-- 
Jonathan Cormier
Senior Software Engineer

Office:  315.425.4045 x222

http://www.CriticalLink.com
6712 Brooklawn Parkway, Syracuse, NY 13211

Re: [PATCH 0/3] gpio: tps65219: Fix TPS6521x GPIO handling

[Bartosz Golaszewski]

On Sat, 19 Sep 2026 19:10:57 +0200, Karl Mehltretter wrote:
> I found patch 1 while looking through the tree for code that mixes up
> bit numbers and bit masks. Patches 2 and 3 turned up while checking the
> nearby TPS65214 code.
> 
> Patch 1 fixes TPS65219 input reads. Patches 2 and 3 fix TPS65214
> direction handling.
> 
> [...]

Applied, thanks!

[1/3] gpio: tps65219: Fix GPIO input value reads
      https://git.kernel.org/brgl/c/4cbe530c0233c7413aaaeb029a4f32dd6aadacbb
[2/3] gpio: tps65219: Use the variant-specific direction callback
      https://git.kernel.org/brgl/c/93cf8cedeaaa05714f709b539cfb976e0b80c830
[3/3] gpio: tps65219: Fix TPS65214 GPIO direction programming
      https://git.kernel.org/brgl/c/270437f3fe62516f16482742a7762a075e7a9457

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH 3/3] gpio: tps65219: Fix TPS65214 GPIO direction programming

[Andy Shevchenko]

On Sat, Sep 19, 2026 at 8:11 PM Karl Mehltretter <kmehltretter@gmail.com> wrote:
>
> GPIO_LINE_DIRECTION_OUT and GPIO_LINE_DIRECTION_IN have the values 0
> and 1, respectively, while the TPS65214 GPIO_CONFIG field is BIT(1).
> regmap_update_bits() masks the supplied value, so passing either
> direction value clears the field and selects input mode.
>
> Translate the GPIO direction to the register encoding used by
> tps65214_gpio_get_direction(), setting GPIO_CONFIG for output and
> clearing it for input.

...

> +       val = direction == GPIO_LINE_DIRECTION_OUT ?
> +               TPS65214_GPIO0_DIR_MASK : 0;
>         ret = regmap_update_bits(gpio->tps->regmap, TPS65219_REG_GENERAL_CONFIG,
> -                                TPS65214_GPIO0_DIR_MASK, direction);
> +                                TPS65214_GPIO0_DIR_MASK, val);

regmap_assign_bits()

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/3] gpio: tps65219: Fix TPS65214 GPIO direction programming

[Jon Cormier]

On Thu, Sep 24, 2026 at 11:47 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Sat, Sep 19, 2026 at 8:11 PM Karl Mehltretter <kmehltretter@gmail.com> wrote:
> >
> > GPIO_LINE_DIRECTION_OUT and GPIO_LINE_DIRECTION_IN have the values 0
> > and 1, respectively, while the TPS65214 GPIO_CONFIG field is BIT(1).
> > regmap_update_bits() masks the supplied value, so passing either
> > direction value clears the field and selects input mode.
> >
> > Translate the GPIO direction to the register encoding used by
> > tps65214_gpio_get_direction(), setting GPIO_CONFIG for output and
> > clearing it for input.
>
> ...
>
> > +       val = direction == GPIO_LINE_DIRECTION_OUT ?
> > +               TPS65214_GPIO0_DIR_MASK : 0;
> >         ret = regmap_update_bits(gpio->tps->regmap, TPS65219_REG_GENERAL_CONFIG,
> > -                                TPS65214_GPIO0_DIR_MASK, direction);
> > +                                TPS65214_GPIO0_DIR_MASK, val);
>
> regmap_assign_bits()
That would make sense, it would simplify the diff.  I think something
like this, right.

-        ret = regmap_update_bits(gpio->tps->regmap,
TPS65219_REG_GENERAL_CONFIG,
 -                                TPS65214_GPIO0_DIR_MASK, direction);
+        ret = regmap_assign_bits(gpio->tps->regmap,
TPS65219_REG_GENERAL_CONFIG,
 +                                TPS65214_GPIO0_DIR_MASK, direction
== GPIO_LINE_DIRECTION_OUT);


-- 
Jonathan Cormier
Senior Software Engineer

Office:  315.425.4045 x222

http://www.CriticalLink.com
6712 Brooklawn Parkway, Syracuse, NY 13211