How to reconfigure a line to OUTPUT without writing output_value to the hardware latch?

[mfide]

Environment

• libgpiod: 2.1.3
• Kernel: 6.12.90 (ARM, single-core Cortex-A5)
• SoC / GPIO driver: NXP Vybrid VF500 (Colibri VF50) — fsl,vf610-gpio (drivers/gpio/gpio-vf610.c)

Background

We have an embedded application that controls FPGA enable / reset signals via GPIO. On this SoC the data direction register (PDDR) and the output latch (PDOR) are physically separate registers, so our intuition is that flipping direction should not alter the output latch — when a pin is switched to output, it
should drive whatever value happens to be in the latch.

We use libgpiod v2 to manage the lines. Wrapper functions in our application follow this pattern:

/* gpio_open(pad, is_input=false) */
gpiod_line_settings_reset(settings);
gpiod_line_settings_set_direction(settings, GPIOD_LINE_DIRECTION_OUTPUT);
gpiod_line_config_add_line_settings(config, &offset, 1, settings);
req = gpiod_chip_request_lines(chip, req_cfg, config);

/* gpio_set_direction(pad, is_input=false) — caller re-asserts OUTPUT */
gpiod_line_settings_set_direction(settings, GPIOD_LINE_DIRECTION_OUTPUT);
gpiod_line_config_add_line_settings(config, &offset, 1, settings);
gpiod_line_request_reconfigure_lines(req, config);

/* gpio_set_output(pad) — caller wants HIGH */
gpiod_line_request_set_value(req, offset, GPIOD_LINE_VALUE_ACTIVE);

output_value is never explicitly set on settings, so it stays at the default GPIOD_LINE_VALUE_INACTIVE after gpiod_line_settings_reset().

What we observe

• After gpiod_chip_request_lines() with direction=OUTPUT and the default output_value, the line is driven LOW (consistent with the kernel applying output_value on request).
• After the subsequent gpiod_line_request_reconfigure_lines() (same direction, no change in our intent), the line stays LOW — the latch was rewritten with INACTIVE again because output_value is still the default in settings.
• The final gpiod_line_request_set_value(ACTIVE) on our setup does not appear to drive the line HIGH (raw register check via /dev/mem shows PDOR unchanged). We have not yet built an isolated reproducer for this last symptom, so we cannot say whether it is reproducible outside our application. We will
  file a separate issue with a minimal reproducer if it is.

Reading the source

Kernel (drivers/gpio/gpiolib-cdev.c, linereq_set_config()) unconditionally applies the output value whenever direction is OUTPUT:

if (lflags & GPIO_V2_LINE_FLAG_OUTPUT) {
    __set_bit(FLAG_IS_OUT, &desc->flags);
    ret = gpiod_direction_output_nonotify(desc, !!output_value);
}

The vf610-gpio driver in turn writes PSOR/PCOR before changing direction (direction itself is then applied via iomuxc OBE through pinctrl_gpio_direction_output()):

static int vf610_gpio_direction_output(struct gpio_chip *chip,
                                       unsigned int gpio, int value)
{
    vf610_gpio_set(chip, gpio, value);   /* unconditional PSOR/PCOR write */
    /* have_paddr is false for vf610, so PDDR is not touched here */
    return pinctrl_gpio_direction_output(chip, gpio);
}

So on this SoC, a libgpiod-driven reconfigure_lines(direction=OUTPUT) will always perform a PSOR or PCOR write based on output_value, even if the caller did not intend to change the line's logic level.

Minimal pseudocode reproducer

struct gpiod_chip *chip = gpiod_chip_open("/dev/gpiochip3");
unsigned int offset = 23;

struct gpiod_line_settings   *settings = gpiod_line_settings_new();
struct gpiod_line_config     *config   = gpiod_line_config_new();
struct gpiod_request_config  *req_cfg  = gpiod_request_config_new();

/* Step 1: request OUTPUT with value HIGH */
gpiod_line_settings_set_direction(settings, GPIOD_LINE_DIRECTION_OUTPUT);
gpiod_line_settings_set_output_value(settings, GPIOD_LINE_VALUE_ACTIVE);
gpiod_line_config_add_line_settings(config, &offset, 1, settings);
struct gpiod_line_request *req =
        gpiod_chip_request_lines(chip, req_cfg, config);
/* Expected and observed: line HIGH */

/* Step 2: reconfigure — same direction, no explicit output_value */
gpiod_line_settings_reset(settings);
gpiod_line_settings_set_direction(settings, GPIOD_LINE_DIRECTION_OUTPUT);
gpiod_line_config_add_line_settings(config, &offset, 1, settings);
gpiod_line_request_reconfigure_lines(req, config);
/* Observed: line driven LOW (because output_value defaults to INACTIVE) */

(We have not yet built and run this exact sequence as a standalone binary on the target — we plan to. If maintainers prefer, we will publish the standalone reproducer first.)

Questions

1. Is the current behavior intentional — that gpiod_line_request_reconfigure_lines() always writes output_value to the latch when direction is OUTPUT, even on a same-direction reconfigure?
2. If a caller wants to change unrelated settings (bias, drive, debounce) on an OUTPUT line without disturbing the latch, is the recommended pattern to call gpiod_line_request_get_value() first and then explicitly gpiod_line_settings_set_output_value() to that value before reconfigure?
3. Would a GPIOD_LINE_VALUE_AS_IS (or equivalent skip flag) be welcome — symmetric to GPIOD_LINE_DIRECTION_AS_IS — to mean "do not apply output_value on this reconfigure"? Happy to draft a PR if there is interest.
4. We may simply be misusing the v2 API. If there is an established idiom for "change direction-to-OUTPUT without touching the latch" that we have missed, a pointer would be very welcome.

Thanks for your time.

[brgl]

Questions

1. Is the current behavior intentional — that gpiod_line_request_reconfigure_lines() always writes output_value to the latch when direction is OUTPUT, even on a same-direction reconfigure?

I'm not sure this is a libgpiod problem. It looks more like the behavior of the linux kernel driver is the culprit? gpiod_line_request_reconfigure_lines() doesn't write anything to the latch - it just forwards a request to the GPIO core in the kernel which in turns asks the driver to do a bunch of things. The driver may end up writing to the given register but doesn't have to.

2. If a caller wants to change unrelated settings (bias, drive, debounce) on an OUTPUT line without disturbing the latch, is the recommended pattern to call gpiod_line_request_get_value() first and then explicitly gpiod_line_settings_set_output_value() to that value before reconfigure?

Yes, you have a set of settings in struct gpiod_line_config including the direction and possibly the output value. If you want to keep it you either have to store the settings, the line config object or read the value and update the config.

3. Would a GPIOD_LINE_VALUE_AS_IS (or equivalent skip flag) be welcome — symmetric to GPIOD_LINE_DIRECTION_AS_IS — to mean "do not apply output_value on this reconfigure"? Happy to draft a PR if there is interest.

Not really. When you drive a line, you better know what the value's got to be.

4. We may simply be misusing the v2 API. If there is an established idiom for "change direction-to-OUTPUT without touching the latch" that we have missed, a pointer would be very welcome.

Yes, either keep the value in some local context struct or read it before reconfiguring the line.