diff options
| author | Conor Dooley <conor.dooley@microchip.com> | 2025-08-25 12:53:28 +0100 |
|---|---|---|
| committer | Mark Brown <broonie@kernel.org> | 2025-08-29 13:39:11 +0200 |
| commit | 89e7353f522f5cf70cb48c01ce2dcdcb275b8022 (patch) | |
| tree | 47498119e022c80b02f8f1c7ae42ba10efa5705b /scripts/generate_rust_target.rs | |
| parent | 1b237f190eb3d36f52dffe07a40b5eb210280e00 (diff) | |
spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback
In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem
operation frequency switches") the logic for checking the viability of
op->max_freq in mchp_coreqspi_setup_clock() was copied into
mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid
when this function is called during probe but is instead zero.
Accordingly, baud_rate_val is calculated to be INT_MAX due to division
by zero, causing probe of the attached memory device to fail.
Seemingly spi-microchip-core-qspi was the only driver that had such a
modification made to its supports_op callback when the per_op_freq
capability was added, so just remove it to restore prior functionality.
CC: stable@vger.kernel.org
Reported-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
Fixes: 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Message-ID: <20250825-during-ploy-939bdd068593@spud>
Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'scripts/generate_rust_target.rs')
0 files changed, 0 insertions, 0 deletions