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

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

[Ron Economos]

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

I've bisected it to commit "spi: cadence-qspi: Kill cqspi_jh7110_clk_init" 324ecc7788c2e21d0d9197a8c015ff75382122d9

Here's the bisect log.

git bisect start
# status: waiting for both good and bad commits
# bad: [e86dda7bde8801d32ffe7d1570fe173cab14d1ba] Merge tag 'spi-v6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
git bisect bad e86dda7bde8801d32ffe7d1570fe173cab14d1ba
# status: waiting for good commit(s), bad commit known
# good: [f6c42489fedfa42ba79bd17c49cf81c69ff39f8a] Merge tag 'regulator-v6.20' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect good f6c42489fedfa42ba79bd17c49cf81c69ff39f8a
# good: [19a4505a7a5d4eea70f1a42d601c25d730922fdf] spi: microchip-core: use XOR instead of ANDNOT to fix the logic
git bisect good 19a4505a7a5d4eea70f1a42d601c25d730922fdf
# good: [aac733a9663682387013350b4470a81344960f5d] spi: cadence-qspi: Fix style and improve readability
git bisect good aac733a9663682387013350b4470a81344960f5d
# good: [8ea39d960c9f890e9213cdcfcbe4b3f281acd12f] spi: add multi-lane support
git bisect good 8ea39d960c9f890e9213cdcfcbe4b3f281acd12f
# good: [6516169fa7f6110ce42a5958c921255f2d0968bc] spi: geni-qcom: Add target abort support
git bisect good 6516169fa7f6110ce42a5958c921255f2d0968bc
# bad: [a40236feb62ccbf2b36d288550a483122b3205e5] spi: cadence-qspi: Add support for the Renesas RZ/N1 controller
git bisect bad a40236feb62ccbf2b36d288550a483122b3205e5
# bad: [324ecc7788c2e21d0d9197a8c015ff75382122d9] spi: cadence-qspi: Kill cqspi_jh7110_clk_init
git bisect bad 324ecc7788c2e21d0d9197a8c015ff75382122d9
# good: [2b97f5cd1a956a9ac948ec57775600158988dadd] spi: dt-bindings: cdns,qspi-nor: Add Renesas RZ/N1D400 to the list
git bisect good 2b97f5cd1a956a9ac948ec57775600158988dadd
# first bad commit: [324ecc7788c2e21d0d9197a8c015ff75382122d9] spi: cadence-qspi: Kill cqspi_jh7110_clk_init

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

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...).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

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?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Miquel Raynal]

Hello,

>> > > 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.

Thanks for the report, and thanks for the try. Let me have a look.

Thanks,
Miquèl

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

[Miquel Raynal]

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

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@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

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.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

On Wed, Mar 04, 2026 at 01:52:08PM -0800, Ron Economos wrote:
> On 3/4/26 09:02, Miquel Raynal wrote:

> > 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?

> 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.

I think Miquel means

commit c9117602a87c441c4f05a2cc4d9be45c96140146
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Mar 6 20:16:33 2026 +0000

    test

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 2d287950d44c..d74446f6db5a 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1932,6 +1932,12 @@ static int cqspi_probe(struct platform_device *pdev)
 	reset_control_assert(rstc_ocp);
 	reset_control_deassert(rstc_ocp);
 
+	if (ddata->jh7110_clk_init) {
+		ret = cqspi_jh7110_clk_init(pdev, cqspi);
+		if (ret)
+			goto disable_clk;
+	}
+
 	cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
 	host->max_speed_hz = cqspi->master_ref_clk_hz;
 
@@ -1959,11 +1965,6 @@ static int cqspi_probe(struct platform_device *pdev)
 		if (ddata->quirks & CQSPI_NEEDS_APB_AHB_HAZARD_WAR)
 			cqspi->apb_ahb_hazard = true;
 
-		if (ddata->jh7110_clk_init) {
-			ret = cqspi_jh7110_clk_init(pdev, cqspi);
-			if (ret)
-				goto disable_clk;
-		}
 		if (ddata->quirks & CQSPI_DISABLE_STIG_MODE)
 			cqspi->disable_stig_mode = true;
 
which does the right thing:

   https://lava.sirena.org.uk/scheduler/job/2535610

but I'm fairly sure it's not an ordering thing.  The patch includes:

-       static struct clk_bulk_data qspiclk[] = {
-               { .id = "apb" },
-               { .id = "ahb" },
-       };

but never adds those names back, this means that while we do ask for
three clocks none of them have IDs specified so we just end up
requesting the same clock three times which might be what's needed on
most integrations but not here.  The below seems to do the trick for me,
I'll write a commit log and post - testing appreciated:

  https://lava.sirena.org.uk/scheduler/job/2535662

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 649ff55333f0..7a7f92e9c7a3 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -76,6 +76,11 @@ struct cqspi_flash_pdata {
 	u8		cs;
 };
 
+static struct clk_bulk_data cqspi_clks[CLK_QSPI_NUM] = {
+	[CLK_QSPI_APB] = { .id = "apb" },
+	[CLK_QSPI_AHB] = { .id = "ahb" },
+};
+
 struct cqspi_st {
 	struct platform_device	*pdev;
 	struct spi_controller	*host;
@@ -1823,6 +1828,7 @@ static int cqspi_probe(struct platform_device *pdev)
 	}
 
 	/* Obtain QSPI clocks. */
+	memcpy(&cqspi->clks, &cqspi_clks, sizeof(cqspi->clks));
 	ret = devm_clk_bulk_get_optional(dev, CLK_QSPI_NUM, cqspi->clks);
 	if (ret)
 		return dev_err_probe(dev, ret, "Failed to get clocks\n");

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Ron Economos]

On 3/6/26 13:35, Mark Brown wrote:
> On Wed, Mar 04, 2026 at 01:52:08PM -0800, Ron Economos wrote:
>> On 3/4/26 09:02, Miquel Raynal wrote:
>>> 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?
>> 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.
> I think Miquel means
>
> commit c9117602a87c441c4f05a2cc4d9be45c96140146
> Author: Mark Brown <broonie@kernel.org>
> Date:   Fri Mar 6 20:16:33 2026 +0000
>
>      test
>
> diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
> index 2d287950d44c..d74446f6db5a 100644
> --- a/drivers/spi/spi-cadence-quadspi.c
> +++ b/drivers/spi/spi-cadence-quadspi.c
> @@ -1932,6 +1932,12 @@ static int cqspi_probe(struct platform_device *pdev)
>   	reset_control_assert(rstc_ocp);
>   	reset_control_deassert(rstc_ocp);
>   
> +	if (ddata->jh7110_clk_init) {
> +		ret = cqspi_jh7110_clk_init(pdev, cqspi);
> +		if (ret)
> +			goto disable_clk;
> +	}
> +
>   	cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
>   	host->max_speed_hz = cqspi->master_ref_clk_hz;
>   
> @@ -1959,11 +1965,6 @@ static int cqspi_probe(struct platform_device *pdev)
>   		if (ddata->quirks & CQSPI_NEEDS_APB_AHB_HAZARD_WAR)
>   			cqspi->apb_ahb_hazard = true;
>   
> -		if (ddata->jh7110_clk_init) {
> -			ret = cqspi_jh7110_clk_init(pdev, cqspi);
> -			if (ret)
> -				goto disable_clk;
> -		}
>   		if (ddata->quirks & CQSPI_DISABLE_STIG_MODE)
>   			cqspi->disable_stig_mode = true;
>   
> which does the right thing:
>
>     https://lava.sirena.org.uk/scheduler/job/2535610
>
> but I'm fairly sure it's not an ordering thing.  The patch includes:
>
> -       static struct clk_bulk_data qspiclk[] = {
> -               { .id = "apb" },
> -               { .id = "ahb" },
> -       };
>
> but never adds those names back, this means that while we do ask for
> three clocks none of them have IDs specified so we just end up
> requesting the same clock three times which might be what's needed on
> most integrations but not here.  The below seems to do the trick for me,
> I'll write a commit log and post - testing appreciated:
>
>    https://lava.sirena.org.uk/scheduler/job/2535662
>
> diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
> index 649ff55333f0..7a7f92e9c7a3 100644
> --- a/drivers/spi/spi-cadence-quadspi.c
> +++ b/drivers/spi/spi-cadence-quadspi.c
> @@ -76,6 +76,11 @@ struct cqspi_flash_pdata {
>   	u8		cs;
>   };
>   
> +static struct clk_bulk_data cqspi_clks[CLK_QSPI_NUM] = {
> +	[CLK_QSPI_APB] = { .id = "apb" },
> +	[CLK_QSPI_AHB] = { .id = "ahb" },
> +};
> +
>   struct cqspi_st {
>   	struct platform_device	*pdev;
>   	struct spi_controller	*host;
> @@ -1823,6 +1828,7 @@ static int cqspi_probe(struct platform_device *pdev)
>   	}
>   
>   	/* Obtain QSPI clocks. */
> +	memcpy(&cqspi->clks, &cqspi_clks, sizeof(cqspi->clks));
>   	ret = devm_clk_bulk_get_optional(dev, CLK_QSPI_NUM, cqspi->clks);
>   	if (ret)
>   		return dev_err_probe(dev, ret, "Failed to get clocks\n");

Works good here. I'll send a tested-by: when you post the patch.

ubuntu@visionfive:~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mtdblock0     31:0    0    16M  0 disk     <-----
mmcblk1      179:0    0 119.3G  0 disk
└─mmcblk1p1  179:1    0 119.2G  0 part
nvme0n1      259:0    0 465.8G  0 disk
├─nvme0n1p1  259:1    0 465.6G  0 part /
├─nvme0n1p2  259:2    0    16M  0 part
├─nvme0n1p12 259:3    0     4M  0 part
├─nvme0n1p13 259:4    0     2M  0 part
└─nvme0n1p15 259:5    0   100M  0 part /boot/efi