Re: [PATCH v2 5/7] gpio: regmap: Add runtime PM and read_output_reg_set support

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Wed, Aug 12, 2026 at 08:43:20AM +0200, Michael Walle wrote:
> On Thu Aug 6, 2026 at 5:41 PM CEST, Janani Sunil wrote:
> > The new pm_dev field in gpio_regmap_config allows a driver to supply a
> > device for runtime PM. All operations call pm_runtime_resume_and_get()
> > before accessing the regmap and pm_runtime_put_autosuspend() on return.
> >
> > The new read_output_reg_set flag when set, gpio_regmap_get() checks the
> > pin direction first and reads from reg_set_base instead of reg_dat_base
> > for output pins. Requires both reg_dat_base and reg_set_base to be
> > configured.
> 
> As already mentioned. please split it into two patches. Also, could
> you add some context where/why this is used/useful?
> 
> So, if the direction is output, then you just read back the set
> value (instead of the actual line state). Is that correct? Why can't
> you read the input buffer in that case? Input buffer deactivated?
> (NB. you can never get the real line state in that case, which is
> sometimes useful for debugging.)

I understand the concern, but this is debugging of HW via SW, which I think is
sometimes not possible (not all HW supports it) nor good for production in case
some glitch happens and one reads back not what was written and hence come to
async state with the actual flow. Yes, SW might use GPIO output buffer as 1-bit
variable (it's another story to discuss if it's reliable / good design, but it
is possible and I have heard of a such usage IRL).

TL;DR: I am on the side to return the output state when direction is output.
Also note, some cases might specifically disable input buffers in GPIO (for
example to save a few dozens of µA per pin).

> Anyway, you should be able to achieve the same with the
> reg_mask_xlate(), no? Check if the pin is in output mode, then
> change the &reg.

-- 
With Best Regards,
Andy Shevchenko