Re: spi: Regression with v7.0-rc1 on VisionFive 2

[Miquel Raynal <miquel.raynal@bootlin.com>]

On 28/02/2026 at 15:39:01 GMT, Conor Dooley <conor@kernel.org> wrote:

> On Sat, Feb 28, 2026 at 02:23:00PM +0000, Conor Dooley wrote:
>> On Sat, Feb 28, 2026 at 02:06:17PM +0000, Mark Brown wrote:
>> > On Sat, Feb 28, 2026 at 05:54:06AM -0800, Ron Economos wrote:
>> > 
>> > > I'm getting an SPI failure with Linux v7.0-rc1 on the VisionFive 2 RISC-V board.
>> > 
>> > > Feb 28 00:29:33 visionfive kernel: cadence-qspi 13010000.spi: QSPI is still busy after 500ms timeout.
>> > > Feb 28 00:29:33 visionfive kernel: cadence-qspi 13010000.spi: detected FIFO depth (1) different from config (256)
>> > > Feb 28 00:29:33 visionfive kernel: cadence-qspi 13010000.spi: QSPI is still busy after 500ms timeout.
>> > > Feb 28 00:29:33 visionfive kernel: cadence-qspi 13010000.spi: QSPI is still busy after 500ms timeout.
>> > > Feb 28 00:29:33 visionfive kernel: spi-nor spi1.0: operation failed with -110
>> > > Feb 28 00:29:33 visionfive kernel: spi-nor spi1.0: probe with driver spi-nor failed with error -110
>> > 
>> > FWIW confirmed on my system:
>> > 
>> >    https://lava.sirena.org.uk/scheduler/job/2504026#L715
>> > 
>> > (which I didn't notice as that was just buildroot and not running
>> > kselftest-dt...).
>> 
>> This probably constitutes random speculation, but I am curious if
>> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
>> index 6e56e9d20bb06..390fa87edbaf8 100644
>> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
>> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
>> @@ -873,9 +873,9 @@ qspi: spi@13010000 {
>>  			      <0x0 0x21000000 0x0 0x400000>;
>>  			interrupts = <25>;
>>  			clocks = <&syscrg JH7110_SYSCLK_QSPI_REF>,
>> -				 <&syscrg JH7110_SYSCLK_QSPI_AHB>,
>> -				 <&syscrg JH7110_SYSCLK_QSPI_APB>;
>> -			clock-names = "ref", "ahb", "apb";
>> +				 <&syscrg JH7110_SYSCLK_QSPI_APB>,
>> +				 <&syscrg JH7110_SYSCLK_QSPI_AHB>;
>> +			clock-names = "ref", "apb", "ahb";
>>  			resets = <&syscrg JH7110_SYSRST_QSPI_APB>,
>>  				 <&syscrg JH7110_SYSRST_QSPI_AHB>,
>>  				 <&syscrg JH7110_SYSRST_QSPI_REF>;
>> has any impact. Going from jh7110 specific code to bulk apis is an
>> ordering change, right?
>
> According to Ron, it had no impact.

The other change that could be "it" is the change of order between reset
handling and clock. That would be quite messy if that was the error but
I cannot find another explanation. Ron, can you please try to revert
this patch locally and then move the clk_prepare_enable() of the APB and
AHB clocks earlier, right after the ref clock is also enabled? If the
platform fails to boot, there is maybe a weird internal relationship
with the resets.

Otherwise can you compare the clk_get_rate() on all three clocks in both
cases?

Thank you,
Miquèl