U-Boot GPIO Input Status: A High Pin and a Failed Read Can Share the Same Return

A shell condition around gpio input can take its failure
branch when the GPIO was read successfully. In U-Boot v2025.01, this
legacy subcommand returns the sampled pin value. A valid high input
therefore shares the usual failure return value with a command
error.

This is a command-result problem, separate from active-low signal
interpretation. Before using a service strap or presence input to
control boot policy, define how the script distinguishes a low sample, a
high sample and an unavailable sample. A two-way shell status test
cannot recover three states that the command has already collapsed.

Read the legacy
exception in the implementation

The tagged
GPIO command guide gives a general success/failure description. The
actual
command implementation contains a specific exception: after a
successful input operation it returns the pin value instead
of the common success constant.

Consequently, a low input supplies zero and a high input supplies
one. Error paths also use failure returns. The source explicitly
identifies the ambiguity. Pinning the version matters here; applying
only the guide’s general return-value paragraph would produce the wrong
script interpretation.

A success branch taken for a low level is not proof that low means
the application’s logical assertion. Board polarity and electrical
meaning remain separate. Likewise, treating every nonzero return as
“strap asserted” would silently classify some failures as a real high
sample.

Separate a sampled
value from command status

When CONFIG_CMD_GPIO_READ is enabled,
gpio read places the sample in a named environment variable
and normally returns command success independently of whether the value
is zero or one. That gives a script a separate value channel instead of
overloading shell status.

It is still necessary to qualify that channel. The implementation
calls env_set_ulong without checking its return. A
successful GPIO command therefore does not prove that a constrained or
otherwise failing environment-variable update succeeded.

Use an application-owned scratch variable whose creation and
replacement behavior has been established. Do not reuse a protected
product setting or accept a previous sample left in the variable. A
qualification fixture can initialize a recognizable nonbinary sentinel,
run the sample operation, then require both an acceptable command result
and a new valid binary value. If the variable cannot be initialized or
updated reliably, the fixture must remain invalid rather than infer a
pin level.

Sampling also changes
direction

Both gpio input and gpio read call the
direction-input operation before reading. Neither is a promise to
observe the existing output without changing its configuration. That
matters for a pin connected to a reset line, power control, shared bus
or other function that should not be switched experimentally.

The command also tolerates an already-busy GPIO request and
continues. A claimed pin is not automatically protected from this
diagnostic command merely because another U-Boot consumer owns it. The
direction-operation return is not checked in this path, so successful
value retrieval is not a complete report that every preceding
configuration operation succeeded.

Choose a dedicated, approved input for target qualification.
Establish its pinmux, ownership and safe electrical behavior before
invoking a command that can change direction. Do not discover signal
ownership by manipulating pins on a deployed unit.

Exercise all three
outcomes deliberately

A useful controlled regression has a known low input, a known high
input and an injected lookup or read error. Check the legacy
subcommand’s return separately from its printed sample, then check the
value-carrying form with a fresh scratch-variable sentinel.

Include an environment-update failure fixture if the production
script depends on that output variable. The expected result is an
explicit invalid sample, not retention of yesterday’s level.

No GPIO or environment operation was executed here. The source-level
correction is to keep the sampled level and operation validity separate,
while recognizing that the convenience command does not validate every
ownership, direction or environment-update boundary for the caller.