Hi Igor, On Sun, 4 Oct 2026 at 18:34, Igor Velkov <[email protected]> wrote: > > Hi Simon, > > On Sat, 3 Oct 2026 at 06:41, Simon Glass <[email protected]> wrote: > > Please can you override just max_hz here? > > Yes, v2 will override only max_hz and keep the mode from the DT. > > > Their flashes are now probed at that speed and stay there, since > > slave->max_hz keeps it, rather than running at spi-max-frequency as > > they do today. > > Checking this led me through the history: > > - 96907c0fe50a and b0cc1b846fcb ("dm: spi: Read default speed and mode > values from DT", 2016 and 2019): a device with a DT node gets the DT > values; the second says "even if speed and mode are requested" and > names SPL boot and the splash screen. The SF_DEFAULT_SPEED help says > the same. > - e2e95e5e2542 ("spi: Update speed/mode on change", 2021): after the > probe, _spi_get_bus_and_cs() calls spi_set_speed_mode() with the > requested speed but does not update bus_data->speed. > - 3feea0ba196a ("spi: spi_flash_probe_bus_cs() rely on DT for spi speed > and mode", 2022): callers that want the DT values use > spi_flash_probe_bus_cs(); sf probe uses spi_flash_probe() only when a > speed or mode is given. > > On sandbox at a6ab6a66146, spi_flash_probe(0, 0, 1000000, 0) on > spi.bin@0 (40 MHz in the DT) leaves the controller at 1 MHz after the > probe, after spi_claim_bus() and after spi_flash_read(), while > slave->max_hz and bus_data->speed stay at 40 MHz: the claim compares > against the stale cache and does not reprogram the bus. rk_spi behaves > the same, as its set_speed() takes effect on the next transfer. So > these callers already run at the requested speed after the probe; only > the ID read happens at spi-max-frequency. It also makes a sentence in > my v1 commit message wrong ("the next claim of the bus goes back to > that frequency"). > > > Just to check: should a requested speed above spi-max-frequency be > > honoured here, rather than capped at it? > > I don't think this choice is mine to make; it is about what the SPI > uclass should promise. The options I see: > > A. Keep the v1 scope and override only max_hz for the probe, so the > probe runs at the speed the callers already get after it, uncapped > as today. > B. Honour the speed only for an explicit request from the shell > (sf probe with a speed), where whoever is debugging answers for the > value, and keep the DT speed for everyone else. That also needs the > path from e2e95e5e2542 to stop overriding the DT speed for them, > which is a separate fix. > > Which would you prefer? I will also add the checks you suggested to > the test, on spi.bin@1, whose DT node sets spi-cpol and spi-cpha, so > lost mode bits show up.
This sounds like a decision for the maintainer - maybe B would be better? Marek do you have any thoughts on this. Regards, Simon
