U-Boot sf probe: An Explicit Speed Changes the Device-Binding Path

An SPI flash probe fails when its speed argument is omitted but
succeeds when a speed is supplied. That difference does not, by itself,
prove an electrical timing problem. In U-Boot v2025.01’s driver-model
implementation, supplying the speed selects a different helper path, one
capable of binding a missing flash child dynamically.

This analysis covers ordinary devicetree-backed
DM_SPI_FLASH builds, including U-Boot packaged by
Buildroot. It excludes OF_PLATDATA, stacked or parallel
flash and non-driver-model probing. No erase, program or protection
operation is needed to understand this selection difference.

Start with the
command’s branch condition

do_spi_flash_probe() initializes use_dt to
true. Supplying only the bus and chip select leaves it true. Supplying
the speed changes it to false; an explicit mode does so as well,
although the command syntax places mode after speed. The true branch
calls spi_flash_probe_bus_cs(), while the other calls the
compatibility-style spi_flash_probe(). Tagged
command implementation.

Both are driver-model paths in this configuration. The distinction is
not “devicetree versus no driver model.” It is whether selection
requires an existing child at that chip select or supplies a driver name
that permits dynamic creation. SPI-flash
helper implementations.

The command first attempts to remove a previously found device so
probing will not merely reuse its active state. Therefore repeated
probes are lifecycle operations, not passive prints of a permanently
cached identification. Use a recoverable qualification context when
testing this behavior.

Follow the existing-child
path

spi_flash_probe_bus_cs() calls
spi_get_bus_and_cs(). That helper resolves the SPI bus by
its driver-model sequence number, searches for the requested chip select
and returns an error if no child is found. It probes an inactive child
and obtains its SPI state. It does not create a flash child simply
because a bus and chip-select number were entered. SPI
uclass implementation.

For a devicetree-defined child, the SPI platform conversion reads the
chip select, spi-max-frequency and mode-related properties.
An investigation should therefore inspect the actual control devicetree
and bound-device topology before deciding that the silicon rejected a
particular clock rate.

Follow the explicit-argument
path

The compatibility helper calls _spi_get_bus_and_cs()
with the jedec_spi_nor driver name. If chip-select lookup
reports no device, that helper can bind a new child to the already
available SPI bus, populate its chip select and SPI parameters, then
probe it. It does not conjure a missing controller or prove the selected
physical chip is the intended component. Flash
binding request, conditional
dynamic binding.

Consequently, an omitted-speed failure followed by explicit-speed
success may reflect missing child configuration rather than a slower bus
solving marginal signal integrity. Preserve the original error and
compare whether the device appeared in the bound topology during the
second attempt.

Do not turn
the argument into a measured frequency

The explicit helper can also request a speed or mode update after
probing. Existing-child probing and bus claims still have their own
sequence. dm_spi_claim_bus() derives parameters from the
slave state and applies the bus’s maximum-frequency constraint. A
command-line number alone is not proof of the frequency used for every
transaction, nor does it rewrite the devicetree. Bus
claim and speed handling.

A focused qualification compares omitted and explicit arguments on
the same build while recording bus identity, child presence before and
after, the first returned error and the selected helper path. Only after
resolving that software difference should a timing investigation
attribute the change to actual wire behavior.

Then independently check that the detected flash identity and
geometry fit the board’s intended storage role before approving any
destructive operation. No probe, waveform capture or flash modification
was performed for this article. The diagnostic result is a narrower
inference: changing a speed argument can change binding behavior, so
success is not an electrical explanation by itself.