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

[Ron Economos]

On 3/4/26 09:02, Miquel Raynal wrote:
> On 28/02/2026 at 15:39:01 GMT, Conor Dooley <conor@xxxxxxxxxx> 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

I'm happy to help you debug this, but you have to send me a patch to the reverted file. I have no idea where the ref clock is enabled.